Freigeben über

Changes to Azure AD Authentication Flows - Simplicity & Consistency

  • Artikel

I thought I would post this up here for the regular readers, a colleague of mine whom is a Program Manager over in the Cloud Authentication Services Team recently wrote an article, rather than duplicating effort! have a read below this is especially important to you developers out there whom maybe wondering about some of the changes...

so,

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:

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 Danny!

Source: https://blogs.technet.com/b/ad/archive/2015/03/06/simplifying-our-azure-ad-authentication-flows.aspx

If you have any questions feel free to reach out to us over at the @azuread twitter alias! or if I can do anything to help let me know!

Enjoy!

James.