Add support for authentication using pop-up method instead of full redirect.

[mattmazzola]

I think adaljs should add support for authentication using a pop-up instead of a full redirect.

There are two major benefits to using this technique:

• Much easier for developers!
• Works with SPA frameworks.

Much easier for developers!

With the pop-up method more of the conceptual complexity can be abstracted into the adaljs library and the developer can have much easier time using the library. Adaljs currently does a full redirect and then in order to work with angularjs router there is a bunch of code like:

$rootScope.$on('$locationChangeStart', locationChangeHandler);
....
var locationChangeHandler = function () {
                var hash = $window.location.hash;

                if (_adal.isCallback(hash)) {
                    // callback can come from login or iframe request

                    var requestInfo = _adal.getRequestInfo(hash);
                    _adal.saveTokenFromHash(requestInfo);
....

This is watching the url and if it has a parameter of 'id_token' then it saves the tokens etc.. This logic is currently exposed to the framework such as AngularJS and would have to re-written for every framework which is the largest barrier to using adaljs. Now imagine you have to rewrite all of this for Ember, React, Knockout, etc... way too much overhead especially when people have to try to integrate into existing projects which may already have complex router configurations.

I hope in the future adaljs is modeled after other major JS OAuth SDK's such as Facebook or Google.
FB: http://connect.facebook.net/en_US/all.js
Google: https://apis.google.com/js/client.js?onload=googleApiLoaded

With pop-up style of authentication you can get rid of all url watching stuff in angular and have a simple call like:

FB.login(function(fbResponse) {
  if (fbResponse.authResponse) {
    Ember.run(function() {
      resolve({ accessToken: fbResponse.authResponse.accessToken });
    });
  } else {
    reject();
  }
});

This encapsulates the entire login process in one asynchronous call! Yes, with pop-ups there is a the possibility that pop-ups maybe disabled, but the benefits out weigh this greatly. Especially if this is an option the developer can choose. Just realize what that means for ease of use! FB/Google SDK's handle setting up the window and watching that frame's url for change and closing then it has redirected. I assume this is extremely similar to how the Windows 8 WebAuthenticationBroker works.

Works with SPA frameworks.

The first point was more about how the pop-up can greatly simply needed code and reduce learning for developers, this second point is more about just explaining why the full redirect breaks other SPA frameworks and the pop-up solves the issue. Most SPA frameworks have a router which watches for changes in the hash which correlate to a route as seen in AngularJS. With the full redirect happens the router will attempt to navigate to route 'id_token' which won't exist and thus cause an error. It seems that AAD is always putting the id_token in the hash portion of the url such as adal.html#id_token=eyJ0eXAiOiJKV1Qi... when I would expect it to be able to control this and put it in the search portion of the url such as adal.html?id_token=eyJ0eXAiOiJKV1Qi.... Even if I change the line:

str.push('redirect_uri=' + encodeURIComponent(obj.redirectUri) + '%3F');

I assumed it would append the id_token=asdfasdf to the ? but it still overrides and uses hash. I assume this is because the hash portion of the url can be changed without page refresh, but perhaps someone can clarify if this is infact customizable by the adaljs request to AAD.

[vibronet]

Today Azure AD does not allow the credential gathering UX to be hosted in an iFrame, for security reasons. This is very unlikely to change anytime soon, and without that ability it would be pretty hard to achieve a popup behavior. On mobile platforms, a top use case, popping out another browser window would also be impractical... about the placement of the id_token, that follows the oauth/openid connect specs and is meant to ensure that the token will be delivered to the user agent but not the server.

[mattmazzola]

Oh, I see. Thanks for quick response! I'll close this one then.

[mattmazzola]

Now that ADAL.js v1 is out and the ground work of getting implicit grant flow working is done and developers looking to use this authentication flow are unblocked is there any chance this issue would be re-opened for the next version? Or if not, maybe a timeline of when this would happen if ever?

I would guess for the next version of ADAL the main goal is to refine the library and make it as simple to integrate and use as possible. As seen in the explanation above, enabling the login page to be loaded in a separate frame can reduce the surface area of your library to one call which returns a promise and that is about as ideal as you can get. From my experience with twitter and facebook libraries, the mobile browsers automatically handle this scenario and will force the popup to be frameless so it appears naturally.

I'm not familiar with the security reasons for not allowing the login page to be in iframe. I thought it allows people to use the login page in ways that are non-uniform and malicious people could try to spoof the UI and trick users to enter credentials into a 'fake' login page with similar look at feel, but perhaps there are more serious reasons preventing this feature.

[tushargupta51]

We have added the popUp support in 1.0.12. Set popUp: true in config to enable logging in using pop up. We will update our samples soon to reflect that.

[Hackeron]

Can you provide an example of logging in using PopUp in Iframe for angular 2+?