Microsoft-authentication-library-for-js: msal-browser lacking compatibility with IdentityServer4

Created on 8 Aug 2020 · 3Comments · Source: AzureAD/microsoft-authentication-library-for-js

Please follow the issue template below. Failure to do so will result in a delay in answering your question.

Library

[ ] [email protected] or @azure/[email protected]
[X] @azure/[email protected]
[ ] @azure/[email protected]
[ ] @azure/[email protected]
[ ] @azure/[email protected]

Description

Here is my feeedback on _msal-browser_, after spending some weeks working on authorization and authentication for my company's products.

Since the Microsoft docs state that _Azure AD 2.0_ is compliant with with _OAUTH2_ and _OIDC_, compatibility with these standards should be a supported scenario. In my opinion, supporting these standards should be a goal for the _AzureAD_ and _MSAL_ teams.
This would greatly increase trust in the products. It would convey that we are all going in the same direction, and converging to a standard as much as possible.
_IdentityServer4_ is considered by the .NET community as the go to solution for many _OAUTH OIDC_ scenarios. And it is considered as an accurate implementation of the protocols.

Let me explain my scenario
We run multiple _IdentityServer4_ instances and one _AzureAD v2.0_ instance. We build many _java script_ (react, mobile) apps that login and authorize to these services by using the _code authorization + PKCE flow._ From these applications, depending on the server, we use either _msal-browser_ (for azure) or _oidc-client_ (for Identity Server)

I would like to use only one client to connect to both of these services. My preference would be to use _msal-browser.js_, mainly because it is specialized to this particular authorization flow but also because it has a cleaner interface. Unfortunately, as of the time of writing, _msal-browser.js_ cannot correctly work with _IdentityServer4_. So I have to use both clients, depending on which auth server I am using in the app.

I for one love the simplicity of use with the new _msal-browser_ client (works great with _Azure AD 2.0_) and I am disappointed to see that there are some very small obstacles in the way of using it with _IdentityServer4_.

I also know that this is a huge market (standalone javascript browser client applications) - that need to authenticate, authorize users safely with code_authorization + PKCE. (check weekly downloads for packages like angular-oauth2-oidc, oidc-client)

Isues I found with msal-browser
From what I found, the reasons that _msal-browser.js_ cannot connect to _IdentityServer4_ are small implementation choices, not pertaining to the main functionality, cryptography, etc.
I have spent many hours trying to get _msal-browser_ to work with _IdentityServer4_ and after digging in the code a bit, I gave up. Some issues I found:

msal-browser.js does not support a basic url (no path) for the authorization server, one that is missing the tenant part that is specific to _Azure AD 2.0_. If I set my authority url to something like _www.myidentityauthority.com_ it will fail ("url_parse_error", it does not work without a tenant in the path. if I set my authority url to something like _www.myidentityauthority.com/authpath_ it passes that check, but this requires routing hacks on the _IdentityServer4_ server - which we are not going to pursue)
_DEFAULT_AUTH_ENDPOINT_PATH(oauth2/v2.0/authorize?)_ and _DEFAULT_TOKEN_ENDPOINT_PATH(oauth2/v2.0/token?)_ are non standard path artifacts - but the _authorizationEndpoint()_ method concatenates these to the authority url, thus forcing you tu use a certain url path, and there is no way to configure this. again, this requires routing hacks on the server

I hope I have provided some information useful for improving the _msal-browser_ client.

Unfortunately I am somewhat of a javascript noob, so I would not feel comfortable working on a PR for these, but I would be willing to test them out if someone would implement them.

compatibility feature msal-browser

Source