Document Azure "{tenantid}" discovery quirks

[ericchiang]

This has become such a common question that I think it's worth documenting or having a special error message.

#121
#159
#204

[ericchiang]

To be clear, if we see an issuer URL returned like https://login.microsoftonline.com/{tenantid}/v2.0, the error should be something like:

invalid Azure issuer URL, consider using "https://login.microsoftonline.com/{tenantid}/v2.0" where "{tenantid}" is your Azure Tenant ID

[MaikuMori]

As far as I know, the URL I'm providing is correct.

These are the endpoints given to me in Azure page where I register my "app" to get the client id and secret.

Note the word common instead of my tenant id. This is because I want to accept all Live ID logins and not the accounts specific to my "tenant".

Also see this documentation:

https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols#endpoints

common is a special value and if I use anything else it will have different effect.

They're breaking the spec on purpose or have a bug. If it is indeed a bug, I don't know where to open issue to actually get it fixed.

[ericchiang]

Ah thanks for the follow up. Yeah it looks like its broken on their end.

I'd strongly recommend opening an issue with Microsoft https://github.com/MicrosoftDocs/azure-docs/issues?utf8=%E2%9C%93&q=%22524b460d-47b7-72c9-e994-ea94b3a9dd2b%22&in=body

Out of curiosity, what's the "iss" claim of the ID Token?

[MaikuMori]

Managed to get it working as per #121 (comment).

This still obviously it is non-standard implementation on Microsofts side. At the same time I believe the error message should explain that instead of using:

https://login.microsoftonline.com/common/v2.0/

one should use:

https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0

Sadly that's not mentioned anywhere in MS docs. And doing another Google search, now I'm not even sure that using 9188040d-6c67-4c5b-b112-36a304b66dad allows login with non-personal accounts. What a mess.

Edit:
Issuer claim of ID token washttps://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0 when I logged in with personal live id. I still need to test with other type. This is what got me to the "fix".

Edit 2:
Nope, according to their docs that UUID is alias for consumers special tenant and will only work with personal accounts.

[ericchiang]

Thanks for the update!

It sounds like there's still some confusion around what the correct URL to use for Azure is. Going to see how https://github.com/MicrosoftDocs/azure-docs/issues/38427 plays out before taking action here.

On a different note, I think this demonstrates why the inability to skip issuer validation is good. I'd rather users understand the correct solution, instead of choosing the easy option to insecurely skip validation and continue with an incorrect setup.

[yacchi]

The same problem occurs in 'organizations' and no aliases like 'common' are found.
I agree that their end is broken, but I can't use it as it is, so is there any better way to use it?

[ericchiang]

Yeah it sounds like they aren't going to make it spec compliant https://github.com/MicrosoftDocs/azure-docs/issues/38427#issuecomment-555855086

@yacchi you can do discovery yourself and build a verifier with:

https://godoc.org/github.com/coreos/go-oidc#NewRemoteKeySet
https://godoc.org/github.com/coreos/go-oidc#NewVerifier

[yacchi]

Thanks.
It seems that verifier can be used.

It would be very useful to be able to use provider as well, but is it difficult?

[ericchiang]

It would be very useful to be able to use provider as well, but is it difficult?

Creating a Provider requires a spec compliant OpenID Connect issuer. So no, you can't create on with certain Azure setups.