Dynamic Issuer Validation

[inzanez]

Hi

I am trying to use the issuer 'https://login.microsoftonline.com/common/v2.0' which serves all Microsoft accounts, regardless of their tenant. Now it seems that openid sees a tenant mismatch, because Microsoft will resolve the tenant which will not be 'common' but the actual tenant id once a user logs in.

Configured issuer and token issuer mismatch: 'https://login.microsoftonline.com/%7Btenantid%7D/v2.0', 'https://login.microsoftonline.com/d5ee1c08-df48-41ab-9948-80530002a9a8/v2.0

Is there already support for something like a dynamic issuer? https://login.microsoftonline.com/{tenantid}/v2.0,...not sure how that is supposed to be done, but validating the token errors :-)

I see that there is the 'microsoft' feature; I just wonder if turning off issuer check is not an issue?

[inzanez]

Generally speaking: is this Microsoft token validation only required for Multitenant configs? Otherwise....one could make it a default for all 'microsoft.com/...' endpoints, right? As I see for now I need to manually switch to openid::provider::microsoft::validate_token(...

[kilork]

Hi @inzanez, there is a special module called microsoft as this problem with issuer validation for Microsoft is well known. That Microsoft is not following the standard should not be an example for all other OpenID providers. Means handling of special cases should not be a part of common implementation. I can still admit we can create a new feature to add special case for people who want to have special cases and assert issuer only if it does not start with preselected list of prefixes or whatever. How do you think?

[inzanez]

@kilork I agree, yes. I just realized that it seems to work with the standard flow in case of "single tenant configuration" and only fails for multi-tenant config. For now I am doing this:

        if oidc_client
            .provider
            .auth_uri()
            .to_string()
            .starts_with("https://login.microsoftonline.com")
        {
            openid::provider::microsoft::validate_token(oidc_client, id_token, None, None)?;
        } else {
            oidc_client.validate_token(id_token, None, None)?;
        }

I guess it would be the application's responsibility to further specify if the current provider is single- or multi-tenant and based on that decide to only use the microsoft specific validation when it really is multi-tenant.

That way a default integration would leave that choice to the app, ...