OAuth2ClientPropertiesRegistrationAdapter shouldn't remove issuer's trailing slash

[jzheaux]

OAuth2ClientPropertiesRegistrationAdapter removes the trailing slash on the user-provided spring.security.oauth2.client.provider.providername.issuer-uri property.

This causes a problem when the issuer for the OAuth 2.0 provider actually does have a trailing slash.

For example, Auth0's iss field always has a trailing slash.

Once the trailing slash is removed, then issuer validation fails since it differs from the iss claim in JWTs and in the OIDC Discovery endpoint.

There is at least one example of a user working around this in the wild by adding an extra slash. :)

Is it necessary to remove the trailing slash?

[philwebb]

Looks like the cleanPath method was added for #13210.

[mbhave]

I looked at this example provided here. The issuer-uri in the example properties had a trailing slash while the response from the server didn't which is why cleanPath was added.

@jzheaux If we didn't clean the path, the issuer-uri in the properties would need to exactly match the one in the server response. If that's an acceptable outcome, we can avoid removing the trailing slash, although that would be a change in behavior for anyone who has a trailing slash configured in their properties.

[jzheaux]

I see, @mbhave.

If we didn't clean the path, the issuer-uri in the properties would need to exactly match the one in the server response

This is the desired behavior.

that would be a change in behavior for anyone who has a trailing slash configured in their properties

Agreed. While not ideal to potentially break users, it should be relatively easy for folks to realize what is happening since the error message is detailed enough:

The Issuer "https://provider.org/" provided in the OpenID Configuration did not match the requested issuer "https://provider.org"

[jgrandja]

@jzheaux Can you provide a sample of the issuer from the Provider Configuration Response for at least 4 providers. I'm thinking there may be inconsistencies between providers.

Also, does the spec specify how the issuer should be normalized in the response. There may be more info here.

[jzheaux]

@jgrandja Auth0 is the only provider that I know of whose issuer ends in a slash. Okta, Google, and UAA all do not have a trailing slash in their issuer value:

Okta: https://instance-name.oktapreview.com/oauth2/default
UAA: https://instance-name/uaa/oauth/token
Auth0: https://instance-name.auth0.com/
Google: https://accounts.google.com

Either way, though, I'd vote that the discrepancies regarding discovery be handled inside ClientRegistrations and JwtDecoders as opposed to in Boot since this property is used more broadly than just for discovery.

[jgrandja]

@jzheaux Agreed, we should handle the trailing slash on our end, whether it's in ClientRegistrations or JwtDecoders or a combination of both. I'd say we remove the cleanIssuerPath on the Boot side.

[mbhave]

sounds good to me (marked it as a bug rather than an enhancement since auth0 doesn't work without the double slash workaround).

[jzheaux]

Thank you, @mbhave!

[making]

FYI
Azure AD's issuer field has a trailing slash as well and I met the same issue as auth0.

https://sts.windows.net/9d14e56a-b1df-4955-9dc6-0a5833c58a1f/.well-known/openid-configuration