Our thoughts on implicit grant with Microsoft identity

Microsoft identity platform team

Microsoft Azure Active Directory uses open industry standard protocols such as OAuth2 and OpenID Connect. The OAuth2 working group recently released a draft of the best practices on how to secure applications using OAuth2 and OpenID Connect. In this document there are proposed changes to how the OAuth2 working group recommends authenticating users in JavaScript Single Page Applications (SPA). Customers using Azure Active Directory are asking us if this impacts their current SPA implementations and if there is any reason for concern.

First, it’s important to understand this emerging recommendation is not a result of any newly discovered vulnerability in the way users are being authenticated in SPA. Instead, this is an evolution of the best practices as new technologies become available to web browsers, mobile devices, and identity systems. Large collaborative efforts such as OAuth2 means guidance evolves in public so that as an industry we can move towards better interoperability and security across our platforms. Sometimes these best practices turn out to be impractical when implemented in the real world, and sometimes the industry floats new proposals that are adopted industry wide before standards are updated.

Using Azure Active Directory Authentication Library for JavaScript (ADAL JS) or Microsoft Authentication Library for Javascript Preview (MSAL JS) provides the best assurance your web applications are always up to date with the latest recommendations and security research without needing to be an identity industry expert. If you are currently using the latest version of our ADAL JS or MSAL JS Preview libraries there is nothing more you need to do.

We would like to share some additional information with you on the Implicit Grant and Azure Active Directory. Microsoft currently follows the industry recommended guidance for securing Implicit Grant. We leverage the “state” parameter to prevent token replays in SPA. We also use the “nonce” parameter to ensure an authorization code cannot be injected into the authorization response for SPA. In addition, we take the added security measure of validating the authority requested by the client with the authority provided in the token, ensuring we do not fall prey to the “mix up” vulnerability. Finally, we do explicit matching of the redirect URI. In the latest version of our endpoint, we also do not allow wildcards in the redirect URI. Apps that use wildcards are recommended to update their redirect URIs in their app registration. We also ensure the redirect URIs are using TLS. Of course, these mitigations require a client library that will leverage these service features. The Azure Active Directory Authentication Library for JavaScript (ADAL JS) or Microsoft Authentication Library for Javascript Preview (MSAL JS) leverages these features and will update to use more security features as best practices evolve.

The implicit grant is not perfect, and we are working collaboratively with both the OAuth2 working group and browser vendors on a few concerns that have evolved since the OAuth standard was ratified. These include credentials being stored in browser history and new restrictions on the usage of cookies by some vendors. However, we do not recommend any changes to SPA implementations at this time.

As always, feel free to reach out to us on our Twitter account, GitHub repository, or Stack Overflow.

-The Microsoft identity platform team

Feedback usabilla icon