In the ASP.NET/OWIN world, I was missing the right mental model when distinguishing what was so special about converting an auth code (and appid and appkey (to a token with GraphAPI permissions (on the directory just used for SSO authn) and doing oauth2 client_credentials grant citing the same appid and appkey to get a token dtargeting ones own webAPI guarded resources.
A video helped – with the mental model. It puts together the whole:
One should think of the process of converting an auth_code to an graph-capable access token as something that is “pipeline-time” . Its put there because its really pre-caching the TGT that WILL get the latest token suitable for graph API, for your API, of office API, or whatever API. In oauth2 world, the TGT is the refresh token obtained by swapping the auth code.
Evidently, only auth code grants get the refresh token (and TGT). Or at least, only the auth code grant gets a TGT that is multi-API capable.
This really puts the graphAPI, and its TGT and its cache0-side proxy, in the role of a API meta-guard – allowing the graph to really decide which API tokens are issued PER USER. Some users may get more API tokens than others, gated on what the “app-tuned” graph service (not the baseline resource security model) indicates.
Hmm. I bet this doesn’t sound right to folks who don’t have a well developed understanding of security models, when evaluating security software. It makes good sense, if you do!
The disclosure is not new (see http://www.cloudidentity.com/blog/2013/10/14/adal-windows-azure-ad-and-multi-resource-refresh-tokens/). What is new is the placement of the TGT obtaining process in the owin pipeline itself – before app code fires.