[email protected] or @azure/[email protected]I'm working on a project that has implemented MSAL 1.2.0 inside an Angular App, but without using the Angular library (e.g. Just standard JS inside the app as a service).
Ignoring all the other multitudes of issues with this, an issue we have is the redirect_uri creating an iframe loop. The documentation (https://github.com/AzureAD/microsoft-authentication-library-for-js/wiki/FAQs#q6-how-to-avoid-page-reloads-when-acquiring-and-renewing-tokens-silently)
Set redirect_uri property on config to a simple page, that does not require authentication.
What does a "simple page" constitute. On this simple page, do I have to fire MSAL for any reason?
For example, I have a simple HTML page that does nothing but check if the page is inside a frame, if it is, it does nothing. If it is not in an iframe, it means it's a real user so redirect back to my app with the hash appended which will then be handled from there.
I can see that this does away with the iframe looping and I seem to login OK. But there are two main questions.
@mindingdata
[email protected], a "simple page" can be a blank HTML file with no content. For silent and pop actions (e.g. acquireTokenSilent, acquireTokenPopup, etc), MSAL is not required on that page. For redirect actions (acquireTokenRedirect, loginRedirect), MSAL is required.For redirect actions (acquireTokenRedirect, loginRedirect), MSAL is required.
Interesting. Do you mean because the user must be redirected eventually, or because MSAL is required inside the hidden IFrame?
I should note that we are using the redirect method, not the popup.
For example my code on my empty HTML page is nothing but...
<script type="text/javascript">
if(window !== window.parent && !window.opener)
{
//Iframe
}else
{
var tokenHash = window.location.hash.substr(1);
window.location = "http://mywebsite.com/#" + tokenHash;
}
</script>
So any user hitting this after logging in is redirected back to my website with the hash no worries. The iframe however is stopped dead in it's tracks.
Is this a viable solution?
@mindingdata
Interesting. Do you mean because the user must be redirected eventually, or because MSAL is required inside the hidden IFrame?
For silent and popup flows, the main window for the app (which initiated the actions) will monitor the iframe/popup for the redirect back to the application and then parse out the response. Because that main window is doing all the work, MSAL doesn't need to be running on the redirect URI used for those actions.
For loginRedirect/acquireTokenRedirect, the main window itself gets redirected to the login screen and then back to the app, and so the redirect page used must itself have MSAL in order to process the response.
The code you have there should work, yes.
Note, that you can also set the redirectUri per request, so you could do the following:
// Main configuration, sets blank page as default redirect URI (to be used for popup/silent flows)
const msalInstance = new msal.UserAgentApplication({
auth: {
redirectUri: "https://mydomain.com/auth.html"
}
});
// When using a redirect action, set the redirectUri to a page that has MSAL (to process the response)
msalInstance.loginRedirect({
redirectUri: "https://mydomain.com"
})
Closing, let us know if you have any further questions, thanks!