Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
Simplifying our Azure AD Authentication Flows
Published Sep 06 2018 08:00 PM 26.3K Views
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-9f1d... 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 for reading! We're happy to answer any questions you may have, and as always appreciate your feedback.   Have a great weekend, Danny
2 Comments
Copper Contributor

4 years later and Azure App Services are still redirecting to login.windows.net when using implicit authentication resulting in CORS issues due to multi-redirects.

Copper Contributor
I'm seeing tokens issued from login.microsoftonline do have an issuer sts.windows.net.  However, metadocs from the login.microsoftonline domain do not match this issuer which causes token validation issues. For example, here's one of my metadocs: https://login.microsoftonline.com/e8513859-fd27-4b85-b275-b2f61ada8ac4/v2.0/.well-known/openid-confi... You'll notice that, at the time of this writing, the issuer is not a sts.windows.net-based domain. I posted a discussion about this in the Azure AD tech forum if you'd like to take a look, or if you know a good person to forward this to that would also be helpful.  Thanks! https://social.msdn.microsoft.com/Forums/en-US/08199c62-f2ce-4e1d-adf8-ff7fd1c3064a/issuer-in-loginm...
Version history
Last update:
‎Sep 06 2018 08:00 PM
Updated by: