The other option is to have an alternative redirect page that is targeted after the iframe renews the token (by specifying it in the ADAL config with the redirectUri property). it isn’t in an iframe), which is fine if you have this kind of control over how your app starts (like with AngularJS or React). ![]() The simpler solution is to control how your app is bootstrapped so that it only loads if the window = window.parent (i.e. The ADAL.js team recommend a couple of different approaches to getting around this issue in their FAQ page on github. So, we have our app’s JavaScript (and any HTTP calls) loading twice: once in the main window and again in the iframe. So what’s the big deal? Little hidden iframe refreshing a token never did anyone any harm, right? Well, if you just leave the ADAL config with the default redirectUri setting, the iframe logs in to the Azure AD endpoint and then heads on back to your SPA and… reloads. This will show up in the DOM (if you inspect in the browser dev tools) as an iframe element with an ID of “adalRenewFrame” followed by the endpoint that it is renewing the token for (in the below example this is ). This is where ADAL.js creates a hidden iframe (browser fragment) that sends a request to get a fresh token. It’s the bottom third of the diagram (after the token expires) that causes the issue I am addressing in this post. The ADAL.js and the Azure AD auth endpoint do all the heavy lifting: Implicit auth allows for the application developer to not have to host their own token authentication service. One relates to how ADAL obtains refresh tokens in this crazy world of implicit auth. ![]() Unfortunately (as with most things auth-related), there are some gotcha’s to be aware of. Microsoft’s JavaScript implementation of its Azure Active Directory Authentication Library (ADAL.js) allows for some great client-side-only Single Page App (SPA) scenarios.
0 Comments
Leave a Reply. |