Azure v2.0 issuer compatibility

[matt-sullivan]

I'm having a few issues attempting to use Azure as a oidc server.

As documented in #108, discovery validation fails on the issuer and jwt keys can't be downloaded due to CORS, but I think both can be avoided (by manually specifying config, and exposing/proxying keys through our own back-end.)

However, there is one problem I don't have a workaround for. The Microsoft endpoint at https://login.microsoftonline.com/common/v2.0 can be used to authenticate any Azure tenant, but the tokens it provides have the issuer set to https://login.microsoftonline.com/{GUID}/v2.0

I'd be happy to submit a PR to make this work, but should it:

1. Support a custom issuer validation function/interface?
2. Have a flag to allow any issuer with the same domain name?
3. Have a flag to disable issuer validation completely? (Relying on user's of the library to separately validate.)

I think 2 is the simplest (and best) option, but does that make sense to you?

For reference, here are the azure docs: https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols-oidc

[Gimly]

I'm facing the exact same issue. There definitely should be a way to make the validation more lax. I would also vote for the second option.

Microsoft has created its own library to connect to Azure AD with JS frameworks https://github.com/AzureAD/microsoft-authentication-library-for-js. But I find it pretty limited, and that would mean locking to Azure as well.

[manfredsteyer]

Sorry for the late reply. I was busy at some conferences.

I think, you could just set the following flag:

https://manfredsteyer.github.io/angular-oauth2-oidc/angular-oauth2-oidc/docs/classes/AuthConfig.html#strictDiscoveryDocumentValidation

What do you think?

[matt-sullivan]

Hi Manfred,

That flag isn't enough to make it work, the processIdToken function fails with a 'wrong issuer' error.

That flag would be useful/necessary for discovery document validation, but Microsoft don't support CORS on their jwt endpoint so it discovery won't work properly anyway.

I've actually decided to use my .Net back-end to authenticate to the various oidc servers, hopefully simplifying the angular side and removing the need for any changes here.

Cheers,
Matt

[Gimly]

@manfredsteyer I just tried to put the strictDiscoveryDocumentValidation to false and it doesn't change anything. I still get the following error message:

invalid issuer in discovery document expected: https://login.microsoftonline.com/tfp/test.onmicrosoft.com/B2C_1_SignUp/v2.0 current: https://login.microsoftonline.com/339e6f86-7de6-4a7f-89d7-4bb50b002291/v2.0/

[asadsahi]

having same issue on my local machine with or without setting: strictDiscoveryDocumentValidation;

[asadsahi]

I have just fixed it by suffixing a slash at the end, is that right?

issuer: window.location.origin + '/'

[manfredsteyer]

@asadsahi Great that this works for you now.
@Gimly I think it's a bit more difficult for Azure AD b/c them "violate" the OIDC here. strictDiscoveryDocumentValidation only activates/ deactivates additional checks that are best practices.

The next version that lands in a few days will have a config flag skipIssuerCheck. By setting it to true, this check should go away.

What do you think @Gimly, do you want to contribute a sample that shows how to use Azure AD? Perhaps you already have such a proof of concept.

[Gimly]

@manfredsteyer Unfortunately I don't have a proof of concept using this library anymore. I got frustrated about Azure AD not respecting OIDC, so I switched to using their own library directly. It's pretty annoying as their library won't work if I decide to switch to another identity provider, but it works.

If I have a bit of time I'll try to put something together, it shouldn't be that much work since I already did a version for msal.js. But I can't promise it will be fast 😄.