Modernize your Custom Apps Authentication with msal-browser
New features in Microsoft office 365 continue to make it a powerful hub for teamwork by enabling you to use apps in new ways—including the ability to take quick actions from applications like Microsoft teams without any need to refresh your application between transactions.
Modern applications built in Microsoft 365 are increasingly built on the 'Single page application' model, which interacts with the web browser by dynamically rewriting the current web page with new data from the web server, instead of the default method of the browser loading entire new pages. The goal is faster transitions that make the website feel more like a native app.
Microsoft is bringing new changes to the single-page applications and how they authenticate especially with the use of Microsoft Graph APIs to access security and compliance API endpoints for instance.
The de facto standard for implementing authentication for Single Page Applications without a backend component was the implicit grant flow which is not a recommended approach anymore, and the oAuth 2.0 specifications recommend using the authorization code flow with Proof Key for Code Exchange (Pixie / PKCE) instead. This can be easily implemented by the new version of the Microsoft Authentication Library which is the msal-browser (msal.js 2.0+).
The issues with an implicit flow are well documented here. Apart from the known issues, implicit flow makes use of session cookies to maintain the browser session by passing cookies via a hidden iframe request to the authorization server for a new access token when the old access token expires.
Security features in modern browsers like safari’s Intelligent Tracking Prevention (ITP) block access to third-party cookies. Other chromium-based browsers have also planned to block access to third-party cookies by default. (You can change the settings in some browsers now to achieve this). Hence it is imperative that applications built on the implicit authentication flow must change to stay compliant with browser restrictions.
An application that uses implicit flow relies on this standard of using cookies (silent authentication) and such applications are bound to break on browsers where third party cookies are blocked. There is a new approach that makes use of a concept called Pixie (PKCE – Proof Key for code exchange) which is a part of the authorization code grant flow.
In simple terms, the auth code flow with PKCE looks like this
1. The client app (SPA) in our case, generates a random value called the code verifier
2. The app then encodes this code verifier and generates a code challenge
3. The auth code flow then begins. A request is made to the ‘authorize’ endpoint with the code challenge generated and the method that was used to encode the code verifier
4. The authorization server stores this code challenge for later use
5. The user is asked for credentials and the authorization server returns the authorization code to the redirect URI that was used during app registration
6. This code is then redeemed for an access token by sending a post request to the ‘token’ endpoint only this time the code verifier is sent along with the authorization code
7. The authorization server then encodes the code verifier with the encoding method (specified in step 3) and compares it with the code challenge that it saved in step 4.
8. If it matches, then an access token is returned along with a refresh token
The implicit grant flow is not supported by msal.js 2.0+
If you use single page applications either in SharePoint online or Microsoft Teams or standalone single page apps, you will most likely require remediation of such applications to transition to the new model. Infotechtion can help you with your transition through our technical experts and application modernization approach. Read more about our approach to modernize SharePoint online or contact us for further discussion.