Yesterday, we built out a model store app that embedded the dotnet library for mobile apps. This in turn uses an app secret to first talk to a service, that downloads to the store client oauth parameters that the client then applies, talking oauth2 to an authorization servers endpoints. We got to see that the mobile access tokens are very different to the kind of JWTs one might expect.
Today, we build an alternative store app, from here. This latter source directly uses the so-called adal SDK. This one gives us, as programmer, more direct access to the JWTs – whose attribute content more directly corresponds to the office 365 directory account supporting the OAUTH endpoints of our AAD tenant.
The experience at the configuration requires one to configure 2 apps: one for the webapi that will be the subject of audience fields in access tokens, and one for the client app that must prove that it is entitled to assert the access token (and an id token)..
At the store front, we clearly logon using websso using our Realty IDP, and we can relaunch the app and no second sign is required.
using the realty IDP
API UA, with ability to remove cached tokens.
ON the wire we see what is getting exchanged between client and API, since we get to have a look at the JSON response the client gets from the token endpoint:
Unlike yesterday’s spying on the wire at the tokens exchanged in the “mobile app concept”, we see that the tokens have lots of IDP-centric claims – albeit those from the synced-Office record of our IDPs account.
Perhaps we can guess that the coming version of the mobile dll for store apps fully able to to talk to dotnet based backend services, via the dot NET lib for mobile apps, will merge somewhat with the above.
in terms of scopes, probably due to ADAL, we see the app has the following privileges: