OIDC Issuer Verification

[eddiecarpenter]

The returned issuer value of the authentication provider is compared the configured issuer value and if there is a mismatch the authentication fails.

The problem I am experiencing is that we are using Microsoft's authentication (Azure) allowing multiple Microsoft tenants to access our system. The Issuer string on their side is defined as https://login.microsoftonline.com/{tenantid}/v2.0 where the {tenantid} is the tenant the user belongs too. In other word the Issuer is dynamic and cannot be defined at configuration time!

My suggested solutions are:

1. Allow for a best match where only the first bit of the issuer is defined, for example: https://login.microsoftonline.com/
2. Add a configuration flag that mark the verification as optional or alternatively if no issuer is defined ignore the verification process.
3. Added a mechanism similar to the TenantResolver that allows the developer to override the issuer verification process.

Eddie

[famod]

/cc @sberyozkin

PS: not sure I chose the right label

[sberyozkin]

@famod it is fine, thanks, I also added oidc

[sberyozkin]

@eddiecarpenter Hi, what happens if you do not configure quarkus.oidc.token.issuer ? i.e, what issuer is returned as part of the discovered well-known configuration ?

[sberyozkin]

What Quarkus version is it ? Can you try 1.13.1.Final please ?

[eddiecarpenter]

@eddiecarpenter Hi, what happens if you do not configure quarkus.oidc.token.issuer ? i.e, what issuer is returned as part of the discovered well-known configuration ?

Microsoft's well-known service is at https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration and it returns https://login.microsoftonline.com/{tenantid}/v2.0 as the issuer.

If I do not configure the issuer it defaults to https://login.microsoftonline.com/{tenantid}/v2.0

[sberyozkin]

@eddiecarpenter does it work now :-) ?

[eddiecarpenter]

I am using the latest version 1.13.1-Final :-)

For completes my configuration is as follows. I have X'd the sensitive fields out.

quarkus.oidc.tenant-enabled=false
quarkus.oidc.microsoft.auth-server-url=https://login.microsoftonline.com/common/v2.0
quarkus.oidc.microsoft.client-id=XXXXXXXXXXXXXXXXXXXXXXXXXXXX
quarkus.oidc.microsoft.credentials.secret=XXXXXXXXXXXXXXXXXXXXXXXXXXXX
quarkus.oidc.microsoft.application-type=web-app
quarkus.oidc.microsoft.authentication.scopes=profile,email
quarkus.oidc.microsoft.authentication.redirect-path=/auth/signin-microsoft
quarkus.oidc.microsoft.logout.path=/auth/logout-microsoft
quarkus.oidc.microsoft.logout.post-logout-path=/auth/home
quarkus.oidc.microsoft.authentication.restore-path-after-redirect=true

[sberyozkin]

@eddiecarpenter

If I do not configure the issuer it defaults to https://login.microsoftonline.com/{tenantid}/v2.0

OK, so believe it works now, thanks

[eddiecarpenter]

@eddiecarpenter

If I do not configure the issuer it defaults to https://login.microsoftonline.com/{tenantid}/v2.0

OK, so believe it works now, thanks

No, it does not work as expected. If I define an issuer with a known tenant-id the oidc mechanism works. As explain above, the problem is that the issuer value returned is dynamic and unknown at configuration/startup time.

[eddiecarpenter]

My apologies, I somehow clicked on the wrong link and closed the issue.

[sberyozkin]

@eddiecarpenter I'm getting confused - sorry, so why did you close the issue ?

and,

If I do not configure the issuer it defaults to https://login.microsoftonline.com/{tenantid}/v2.0

Do you mean the literal {tenant-id}, i.e, not /my-tenant/v2.0, etc but {tenant-id} ? While, when the user is authenticating, you have /my-tenanr/v2.0, etc ?

[sberyozkin]

@eddiecarpenter OK, np :-)

[eddiecarpenter]

@eddiecarpenter I'm getting confused - sorry, so why did you close the issue ?

and,

If I do not configure the issuer it defaults to https://login.microsoftonline.com/{tenantid}/v2.0

Do you mean the literal {tenant-id}, i.e, not /my-tenant/v2.0, etc but {tenant-id} ? While, when the user is authenticating, you have /my-tenanr/v2.0, etc ?

Microsoft literally returns https://login.microsoftonline.com/{tenantid}/v2.0 in their well known service response, but in the openid OAUTH2 response replaces the {tenantid} tag with actual tenant-id the user/email address belongs too.

[sberyozkin]

@eddiecarpenter Got it - thanks. Well, yeah, in this case we can't match it - unless we start going the JAX-RS path and take tenant-id as a template var :-), but it would be too messy.... CC @pedroigor

[sberyozkin]

@eddiecarpenter Ok, we'll sort it out - in meantime, here is a workaround:

Set auth-server-url, discovery-enabled=false, and jwks-path=/certs (point to the correct Azure path relative to auth-server-url) - and no issuer will be discovered - and the check will be skipped

[eddiecarpenter]

@eddiecarpenter Ok, we'll sort it out - in meantime, here is a workaround:

Set auth-server-url, discovery-enabled=false, and jwks-path=/certs (point to the correct Azure path relative to auth-server-url) - and no issuer will be discovered - and the check will be skipped

Thanks