Microsoft-authentication-library-for-js: Request for comment: Upcoming API changes in MSAL.js 1.0.0-preview

[navyasric]

As mentioned on the MSAL.js Roadmap, we are working towards the release of MSAL.js 1.0.0-preview which will include breaking API changes in the core MSAL.js library.

Please find details of these changes in Upcoming changes in MSAL.js 1.0.0-preview and provide your feedback on the API by responding to this issue.

[jannikbuschke]

The api looks much better than the current one.

[anubi]

The feedback I have is probably not helpful, because I'm new to this library and Azure's authentication scheme in general. However, I think my overall experience is just clouded because of the general complexity of Azure B2C and the facilitation of multiple downstream APIs.

I can authenticate against a dummy app I registered in Tenant A and get access tokens for whatever scopes I choose, downstream APIs won't know anything at all about the access tokens I pass onto them, since the decrypted tokens don't contain the list of scopes they were authorized against. It's also opaque to me why user information, such as 'email' isn't provided even though I specifically request that scope. Validating the token's authenticity (in a service API related to my SPA) by verifying its signature is less than ideal, I'd much prefer an Introspection endpoint over trying to discern whether my Issuer is https://login.microsoftonline.com/common/ or https://login.microsoftonline.com/{appId}/ myself, since I'm doing multi tenant. I don't understand why my application should need to query the graph API to get user information which could just as easily come in the token. It's hard to convince other stakeholders to adopt this added complexity, or maybe I'm just misunderstanding the fundamentals. Documentation for all this stuff is quite all over the place from one project to the next.

Still, this library has been a lifesaver for streamlining the user authentication piece so far in angular. That I cannot easily extend or instantiate some of the underlying msal-core objects in Angular, like IdToken, is confusing to me though.

[jannikbuschke]

I aggree with the documentation issue: its overly complex and stuff is all over the place. Its unclear what is up-to-date and recommended to do by microsoft. Also there are many different flows.

I think security needs more priority, especially it should be simple, easy to understand, easy to implement/configure.

Current state is a developer needs quite some time to understand different flows, read different tutorials and need try and error. Not at all ideal.

[sameerag]

@anubi We have focused the API improvements for msal-core in the last quarter. We plan to bringup angular wrapper up to speed with msal-core in the near future.

With regards to documentation, any feedback is welcome. We are continuously trying to simplify and make it more user friendly for anyone to adapt our authentication solutions.

[jannikbuschke]

Actually this focus on angular is weird. We have the web platform, there is React, Vue, plain JavaScript/HTML and others. The web is diverse. Why does MS even need to provide an Angular wrapper?

Pls just provide a top notch javascript lib!

The community is able to tailor it for more specific needs/opinions.

[anubi]

I agree that the focus on angular is weird. In this particular case, it works out for me, since my team is using angular. But we could just as well be using react or vue or xyz. But I disagree with the sense that the community should drive this - what'll happen is we'll have a dozen or more forks of the same thing that will all be broken by any changes Microsoft makes to endpoints and contracts; it's quite a lot of responsibility to hand over the community for something as fundamental and essential is authentication. Something that, when I provide details to my stakeholders, get wary about people spending so much time engineering such complex but fundamental 'boilerplate' for a 'new cloud' application that is already made complex by other factors.

For instance, this library uses the Implicit flow. According to current IETF standards, SPAs and basically everyone, should no longer be using this flow. Code Authorization Flow grant with PKCE is the interactive authentication scheme you can apply to SPAs, regular web applications, or native applications. It is currently the most secure OAuth flow, from just an attack vector point of view. Also, Microsoft has also already implemented a v2 endpoint for their authentication. I'm sure there will at some point be a v3. That this library has these things baked into it mean it will be relatively expensive to maintain.

That said, I do appreciate the effort from Microsoft to create some helper libraries. It really streamlines things for people like me, who would otherwise have the task of creating quite a bit of code (which could introduce important security vulnerabilities when I fuck up).

But probably the best strategy, from my naive perspective, is to have a super generic base JS library that can be easily extended to different frameworks, or even new oauth specs too I guess, though that is much harder. Microsoft would only maintain the most abstracted base framework for authentication and somehow leave some of the framework dependent implementation to others.

[hxiongg]

Agreed that we should focus more on security, one of which is to move away from implicit flow to auth code with PKCE flow.

[rayterrill]

Echoing the dislike for focusing on Angular (We personally use VueJS). I don’t love the idea of focusing on any one framework - code should ideally be framework agnostic.

Also echoing frustrations with the documentation. Too many options, documentation that’s out of date, etc. I would love to see a variety of examples - a super simple POC-level example, something slightly more complicated (maybe calling Graph API or something people are likely to be doing), and maybe a fully-functional application people can pick apart to really dig into how things should work.

As an example of something that burned me specifically - we spent days trying to get the Graph Security API working with MSALJS or ADALJS. Come to find out it will never work because it expects roles to be returned, and those are stripped out during implicit flow for length reasons (but we couldn’t find this really documented anywhere).

100% agree auth code + PKCE is the way to go.

[jannikbuschke]

To also bring some positive feedback; imho the 1.0 version is much much better api wise and I also feel the documentation has improved over time.

[DarylThayil]

closing because we released!