We are starting to get the hang of the windows 8 [phone] era SSO logon and the role of the web authentication broker – particular when suppoorted by an IDP or an FP like MicrosoftOnline/aad than might set session cookies. Note how I never said “ADAL”.
It differs from the windows 8 store sample in that the phone platform does not have a web authentication broker. So, the app implements its own, equivalent functionality – using an embedded browser. The latter is a conventional webview, and can store cookies in a share container (unlike a WAB instantiation, that at mot will store cookies in a compartmentalized cookie jar, labeled by package ID).
Without needing to be invoked with/without an SSO flag, the library duly launches a browser that points at MicrosoftOnline (and its screen that offers USERS the ability to stay signed in, using a option button). the latter writes cookies, of course, that now have a container to be stored in.
If one runs the test twice – in what is the same phone emulator instance – one sees the cookie based SSO with microsoftOnline (an FP fronting our IDP, recall) work. That FP duly asserts, automatically the second time, to the AAD OAUTH SP endpoint, controlling whether the AS then issues an authorization_code grant that the embedded browser delivers to the waiting microsoft azure mobile site’s login/aad endpoint. This consumes the code (and any tokens) and duly mints a session token that it delivers to the browser on the “pre-arranged” URI whose form causes the browser to close down…ingest the URI (and its session codes), and pass control back to the navigator controller.