The 2020 specification for implementing Azure B2C SSO relies on using the OpenID Connect library and Authorization code flow
Fig 1 - Client libraries used for performing AD authentication and authorization flow
Fig 2 - Authorization Code Flow with PKCE (Proof Key for Code Exchange)
Due to the fact that I had to implement SSO for one existing application that is using MSAL for authentication and has already been deployed to Production (therefore allowed minimal changes), the example described below is using the MSAL library and the Implicit authorization flow.
There are several areas that need to be addressed when implementing single sign-on for applications deployed into Azure B2C:
authentication and authorization
setting up custom policies
adding application permissions into the token - claims exchanger
Authentication and authorization - see the blog from below:
Setting up custom policies - see the blog from below:
The claims exchanger
Fig. 3 - Authorization flow shows how the roles are added as claims into the token
Fig 4 - The roles attribute it is displayed inside the token
Fig 5 - The Azure function adds the roles into the claim and acts as a proxy to the right application's server who performs the work.
There are 2 ways you can implement the SSO:
1. Using the login hint for applications that shared the same domain
Fig 6 - SSO implemented using the login hint when the apps are in the same domain
Fig 7 - The MSAL library caches the authorization information into local storage.
Fig 8 - Http Interceptor code retrieves a token using the login hint stored in the cookie,
Note: You have to use the MSAL library and the userAgent object (by using just the @azure/msal-angular will not do it)
Fig 9 - Once you log out from the application, you will have to log in again using your B2C account.
2. Using custom policies (just by setting the policies correctly, it will work with no code changes)
