Decoding azure mobile authentication on windows 8


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)

image

we run the “login” unit tests for the win8 platform.

 

imageimage

this test invokes the loginaync method of the mobileclient library.

imageimage

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

 

imageimage

image

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:

image

image

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).

image

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..

image

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

image

and the FP reasserts (to AAD AS logically, acting as WS-FEDP SP).

image

So what  mobile client gets back is some kind of “server session” – a  session token if you will.

image

 

Registering all the windows store stuff involves:

image

image

image

image

image

Package SID:

ms-app://s-1-15-2-2046316581-155186758-2005573411-1086478214-2361134102-2500721798-9514390

<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

image

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:

image

We also make our self a NEW (true client) app, replacing in mobile config the clientid with that shown below

image

68a93294-8e46-45b3-90f2-08d7d066f613

(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!)

Advertisements

About home_pw@msn.com

Computer Programmer who often does network administration with focus on security servers. Very strong in Microsoft Azure cloud!
This entry was posted in azuremobile. Bookmark the permalink.