How to register MSAL JS callback for the custom B2C Invite policy?

Question

This question is related to this one: AngularJS hash # problem after Azure B2C Sign Up policy redirects to application

Here's the Invite custom policy details: https://github.com/azure-ad-b2c/samples/tree/master/policies/invite

The Sign Up invite process is done through e-mail, that is, the user is not using the app and clicking a link on the SPA AngularJS app.

The Sign In works just fine because the user gets redirected to the Sign In policy when they're inside the AngularJS SPA app. They actually click a button when the MSAL JS code is already configured.

For the Sign Up policy the user clicks the invitation link on their e-mail and this link leads to the B2C Sign Up policy. The user clicks the Create button and then they're redirected back to the main app's root address with an #id_token sent from B2C like this:

https://cooldev.azurewebsites.net/#id_token=tokenhere

The problem is that the SPA application has no callback registered to deal with this redirect from the B2C policy.

Any ideas on how to overcome this?

Answer 1

That invitation sample that you have referred to generates an invitation link that is direct to the Azure AD B2C endpoint.

The main disadvantage of this invitation implementation is that the single-page application doesn't call the sign-up flow and, therefore, correlation between the sign-up request and the sign-up response isn't created.

An alternative approach is demonstrated by this invitation sample which generates an invitation link that is direct to an application endpoint and contains:

• The e-mail address of the invited user
• An invitation expiration, and
• A HMAC-based signature

When the invitation link is opened, this application endpoint validates the HMAC-based signature and the invitation expiration and, if they are valid, then it redirects the invited user to the sign-up flow with the ID token.

Answer 2

What's the redirect uri used for the Sign In policy? The same redirect uri should probably be used for the Invite link to the Sign Up policy. I'm not sure why a redirect uri would work for one policy and not the other. In both scenarios, it's just redirecting from your OIDC authority to that uri with the token info (or error message) in the hash. You may have to set up your code that processes the hash to ignore unmatched state .

This redirect uri should ideally point to a lightweight html page that does not load the full SPA. It should only process the hash from the authority, store the values in sessionStorage or localStorage, and then redirect to the SPA. This should allow more prompt behavior and prevent overlapping concerns of what the hash represents.