Microsoft-authentication-library-for-js: Is MSAL specific to Azure services, or is it compatible with AspNet Core Identity / IdentityServer4?

[ryancole]

Hello,

Is MSAL specific to Azure services, or is it compatible with AspNet Core Identity / IdentityServer4? I'm looking for browser libraries to use with our AspNet Core Identity / IdentityServer4 back-end. I was looking at oidc-client, but I also knew about MSAL. Some documentation pages make MSAL sound like it works with any OpenID / OAuth back-end, but then others make it sound specific to Azure (B2C, etc).

Will MSAL work with our Identity / IdentityServer4 back-end?

[tnorling]

@jennyf19 This looks like a .Net question. Could you take a look?

[ryancole]

@jennyf19 This looks like a .Net question. Could you take a look?

Sorry for my unclear post. It’s not really about .net.

We use MSAL.js to authenticate against Azure B2C for a React single page web app. We actually decided to stop using B2C and instead chose to code and host our own identity provider server. We are using Microsoft’s built in AspNet Core Identity for user management and IdentityServer4 for OpenId / OAuth work flows. In essence it’s the same or similar to B2C.

My question is just whether MSAL.js can be used for non-Azure OpenId providers like IdentityServer and AspNet Core Identity?

The docs make it sound like it can on some pages but like it can’t on others.

I initially removed MSAL and went with oidc-client, when removing B2C, but I liked MSAL better.

[tnorling]

@ryancole Gotcha. Theoretically it could work if you set the validateAuthority flag to false. However, this would not be officially supported by us. Any alterations you would need to make to the code in order to make it work would be up to you.

[jennyf19]

@DarylThayil @jasonnutter can you provide any guidance to @ryancole on his inquiry ->

"My question is just whether MSAL.js can be used for non-Azure OpenId providers like IdentityServer and AspNet Core Identity?"

[jasonnutter]

@jennyf19 @ryancole I don't believe we support other OpenID providers as first-class scenarios. As @tnorling mentions, you could attempt to use them and see how things go, but I don't believe we would prioritize fixing incompatibilities (esp. for non-MSFT products). That said, PRs are welcome!

[adriannasui]

@jasonnutter @jennyf19 @DarylThayil

Here is my feeedback on this, 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.

Let me explain my scenario. We run multiple _IdentityServer4_ instances and one _AzureAD v2.0_ instance. We build many javascript (_react_, mobile) apps to login to these services (with _code + PKCE flow_). I would like to use only one client to connect to both of these services. My preference would be to use _msal-browser.js_, due to a cleaner interface, but it cannot correctly work with _IdentityServer4_. So I have to use both clients.

The reasons that _msal-browser.js_ cannot connect to _IdentityServer4_ are small implementation choices, not pertaining to the main functionality.
Today I have spent some hours investigating this and I gave up. Some issues I have encountered (I would probably consider them bugs):

1. _msal-browser.js_ does not support a basic url 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.identitysrf.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.identitysrf.com/authpath_ it passes that check, but this requires routing hacks on the IdentityServer4 server)
2. _DEFAULT_AUTH_ENDPOINT_PATH(oauth2/v2.0/authorize?)_ and _DEFAULT_TOKEN_ENDPOINT_PATH(oauth2/v2.0/token?)_ are non standard path artefacts - 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 for one love the simplicity of use with the new _msal-browser_ client (works great with _Azure AD 2.0_) and I am dissapointed to see that there are some very small obstacles in the way of using it with _IdentityServer4_ (which is considered a very accurate implementation of the standards for the NET community)

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

Best regards,
Adrian

[jennyf19]

@jmprieur @hamiltonha fyi

@adriannasui I would suggest opening a new issue w/this information, so it's not buried here and the team can respond more easily. Thanks for your time, input, and investigation, much appreciate.

[jennyf19]

https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/2120