Quite what the ADAL library does on the various platforms is ambiguous. Furthermore, which oauth (or openid connect flow) is used, per platform or even within a given platform, is confusing.
Fortunately, we get to understand what the core platforms (windows 8 say) do, versus ADAL, by studying the mobile client SDK (for windows 8, say)
we run the “login” unit tests for the win8 platform.
this test invokes the loginaync method of the mobileclient library.
Note the comments. This is a “server side flow” (meaning the AS sends its one time code to a mobile site endpoint that picks up the token-set and redirects to a URI that the authentication broker is looking for). In the case of azure authentication, leveraging microsoftonline FP, we WANT the cookies set by microsoftonline FP to be stored (by the authentication broker).
if we therefore set the unit tests SSO flag , we see on screen and in fiddler
The client is connected up with the authentication block – with net result that the OAUTH URI issued bears the APP “package” ID of the app. Though some instructions do note HOW to configure azure mobile site to know the appid package they characterize the need to do so in terms ONLY of microsoftaccount handling (not WAAD).
if we don’t set SSO flag, we see:
Since the WAB running under the NO SSO rule, we assume that our setting the cookie-flag in the UI will have NO effect. However, we do note an openid connect OAUTH URI (requesting an id-token).
The net result of the flow is as passthrough of the AS-minted idtoken to the mobile site “login/aad” endpoint. This turns around, having consumed the idtoken (and maybe having consume an refresh token etc using the AS’ token endpoint) and mints its own “mini token” given back to the WAB on a URI that the client setup WAB to look for..
Looking back at the chain of handoffs, we do we the microsoftonline sending a SAML assertion to the AAD AD, bearing two sets of claims: those from our IDP and those from the office account.
The IDP asserts to Microsoft Online FP
and the FP reasserts (to AAD AS logically, acting as WS-FEDP SP).
So what mobile client gets back is some kind of “server session” – a session token if you will.
Registering all the windows store stuff involves:
<Identity Name=”14463PeterWilliams.ToDoListTestApp” Publisher=”CN=E87DF924-C067-48F9-A30D-2FDD4F4436AD” />
Client ID: 000000004012130A
This is a unique identifier for your application.
Client secret: cVyeQ99HHSLiHZlbqAxK2n4Qor9xfNrm
We now amend our AAD application record to do the same KIND of thing (ignoring all of the above, essentially). We do use our “app URI” and add it to the redirects:
We also make our self a NEW (true client) app, replacing in mobile config the clientid with that shown below
(the webapp App we are replacing had has 40975017-f200-48fd-9f62-30a466c7408f, note, with app URI of https://discard123.azure-mobile.net/login/aad).
(None of this works… note!)