If you follow this blog you are probably aware that we are hard at work building a unified developer and user experience across the Azure Active Directory and Microsoft Account cloud services. The developer facing piece of this is our v2.0 app model, which we announced back in August and is in preview.
As the v2.0 model nears GA, we have a few important changes you should be aware of. Danny Strockis from our developer platform team has written up a quick blog post on them which you will find below.
I hope you’ll find the information useful! And as always, we’d love to receive any feedback or suggestions you have.
Alex Simons (Twitter: @Alex_A_Simons)
Director of Program Management
Microsoft Identity Products and Services
Attention developers! Over the next two weeks, we will be making a few updates to our v2.0 authentication protocols that may mean breaking changes for any apps you have written during our preview period.
The v2.0 app model and authentication protocols bring together the Microsoft Account and Azure AD cloud services into a converged programming model. We announced the v2.0 app model preview back in August as a way to sign in users with both personal and work accounts using a single button, a single library, and a single app registration. We’ve received some great feedback during this preview, and we’re making a few minor but important tweaks in anticipation of GA.
If this is the first time you’re hearing of the v2.0 app model, you can safely ignore the changes discussed here. And if you want to learn more, now is a great time to begin trying things out by exploring our v2.0 documentation.
Here is a quick overview of what exactly is changing:
- The x5t value is being removed from JWT headers.
- The profile_info property is being removed from token responses.
- The id_token_expires_in value is being removed from responses.
- The meaning of the scope ‘openid’ is changing.
- The issuer value in JWT tokens is losing a ‘/’ character.
Each of these is considered a breaking change, and may require you to make edits to your application code. Your mission, should you choose to accept it, is to review the full details of these changes here and take necessary action to gracefully handle these changes.
The primary motivation for introducing these changes is to be compliant with the OpenID Connect standard specification. By being OpenID Connect compliant, we hope to minimize differences between integrating with Microsoft identity services and with other identity services in the industry. We want to make it easy for developers to use their favorite open source authentication libraries without having to alter the libraries to accommodate Microsoft differences.
Lastly, we’d like to say thank you for trying things out during this preview period. The insights and experiences of our early adopters have been invaluable thus far, and we hope you’ll continue to share your opinions and ideas.
Danny (Twitter: @dStrockis)