what role is AAD and its opened-connect AD playing in ENFORCING
addkey="todo:TrustedCallerClientId"value="db933c15-1ba1-4fca-89dc-c787b8e88fbb"/>
should that be found in a webapi project?
(the above seems "all new" - in the latest ideas for PKI/securitytoken national infrastructure - now in its 19th iteration, since 1995.)
we didn't have that before.
Clients gained access to resources based on the perceived validity of a token, and that's all. That api guard knew nothing about the identity of the bearers on the bearer channel.
Need to know if AAD_based apps are tying a user's projection of user-identity to some device tracking number - where a "device" is a openid client app (or a "UA", as it was called in the 80/90s) that mints the token or acts as one of the agents in a bearer channel.
its kinda worrying to see Microsoft "breaking" architectural lemmas, such as putting use-once nonces into re-usable identity tokens witgh multuipl API audiences, or signaling UA identifiers for use in (poroly architected) trust model bearer-enforcement modules. The ABSOLUTE rule on NOT infusing crypto-compromising tracing signals into key management protocols seems to be going out the door...
Remember you didnt break the Nazi enigma by using bombes to break the key space. First use compromises of the key management channels (to reduce the problem attacked by bombes doing key search). That generally meant exploiting human weaknesses, which provided the per-operator signals) These days it means putting damaging signals into layered stacks (for the same ultimate purpose, where the UA plays the "operator" role to be traced).