Simplifying our Azure AD Authentication Flows

First published on CloudBlogs on Mar, 06 2015
Howdy folks, Today's guest blog post is by Danny Strockis, a Program Manager in our Cloud Authentication services team. His post is targeted to developers who may be wondering about some of the changes we are making to simplify and accelerate our redirection flows. Best regards, Alex Simons (Twitter: @Alex_A_Simons ) Director of Program Management Microsoft Identity and Security Division -------------------------- Hi Everyone, I'm Danny Strockis, one of the Program Managers here in the Cloud Authentication team at Microsoft. If you've ever taken a trace of the authentication requests from your Azure AD protected app you've probably noticed that requests to https://login.windows.net are federated to https://login.microsoftonline.com . The user's credentials are evaluated at https://login.microsoftonline.com and upon successful authentication the user is directed back to https://login.windows.net which finally issues your app the token it requested. A typical sign-in flow might look like this:

We've now made a simplification in our service to remove all those redirects. All authentication requests can now be served directly by https://login.microsoftonline.com end-to-end. To see it in action, open an InPrivate tab and try this link (which will send you to a non-existent "directory searcher" app after sign in): https://login.microsoftonline.com/common/oauth2/authorize?client_id=a5d92493-ae5a-4a9f-bcbf-9f1d354067d3&response_mode=form_post&response_type=code Or, try signing into the Azure Management Portal: https://manage.windowsazure.com . This change presents several advantages:

• Your users get a faster sign-in experience free of extra hops.
• The sign-in user experience includes several new features. Examples are the ability to maintain multiple actively signed-in users and a more responsive UI that behaves appropriately across more devices and screens.
• We can enable a number of features in our engineering systems that will lead to an even more reliable service.

The natural question that follows - what impact does this have on your existing app? Largely, the answer is none. However, if your app makes certain assumptions about our underlying implementation it may require changes. Here are some subtle differences that you should be aware of:

• Applications that send requests to https://login.windows.net will continue to be supported. The redirect to https://login.microsoftonline.com will occur earlier in the authentication flow than before, and will maintain protocol consistency. For example, OAuth2 authorization requests will now redirect to https://login.microsoftonline.com/common/oauth2/authorize rather than https://login.microsoftonline.com/login.srf .
• Any tokens issued, errors displayed or errors reported will now come from https://login.microsoftonline.com .
• The HTML markup and scripts for the new sign-in experience are significantly different even though the visual appearance may be the same. Any tests that rely on exact markup may break and need to be updated.
• The discovery endpoint https://login.windows.net/contoso.com/.well-known/openid-configuration will continue to return legacy https://login.windows.net based endpoints. Those endpoints will then follow the appropriate redirects. The new discovery endpoint https://login.microsoftonline.com/contoso.com/.well-known/openid-configuration will return equivalent https://login.microsoftonline.com endpoints.

And in the interest of being thorough, the following items have not changed:

• The behavior of both token endpoints will remain precisely the same.
• The value of the "issuer" both in metadata and in tokens issued by Azure AD will remain the same – it will continue to be https://sts.windows.net/ based.

If you're creating a new application, you should use https://login.microsoftonline.com as the authority going forward. Our documentation and samples will be updated shortly to reflect the change. If for any reason you need to ship an app using https://login.windows.net going forward, please contact us before doing so – tweet us at @azuread .   For those applications currently authenticating against https://login.windows.net , we recommend making the effort to incorporate the change immediately; your users will get an improved sign in experience, and your authentication flows will be free of extra complexity.   Thanks for reading! We're happy to answer any questions you may have, and as always appreciate your feedback.   Have a great weekend, Danny