`AuthorizationGrantType` does not work when capitalized in configuration

[msosa]

Expected Behavior

spring.security.oauth2.client.registration.{provider}.authorization-grant-type: CLIENT_CREDENTIALS

should correctly trigger the authorize in the respective Provider, ClientCredentialsOAuth2AuthorizedClientProvider in this case.

Current Behavior

currently the AuthorizationGrantType skips and won't use client credentials workflow due to different capitalizations.

Context

I will not say how long this issue had plagued me... but it did take me a while to realize all my settings were correct besides the capitalization of authorization-grant-type. I see ClientAuthenticationMethod has equalsIgnoreCase in the equals but that will be changed in 6.0 due to it breaking the hashcode/equals, so AuthorizationGrantType can't do that either.

Would it be possible to lower case the value in the constructor so capitalization doesn't matter?

[sjohnr]

Hi @msosa, thanks for reaching out!

RFC 6749 defines the client credentials grant type as a lower-case value. We generally want to align with the specification when possible. Is there a particular reason you were trying to use the grant type in all caps?

[msosa]

Yes, when I was looking at the Javadoc for it I saw CLIENT_CREDENTIALS as a static field and wrongly assumed that was just one of the values to use. Obviously looking at it now when I look at the code I see the static field is creating it with lower case, but also did not suspect it was an issue since the all caps hadn't caused any failures.

If the RFC defines the grant type as all lower case, could the class make the value lower case on instantiation?

[sjohnr]

Yes, when I was looking at the Javadoc for it I saw CLIENT_CREDENTIALS as a static field

Thanks! That is good to know where you first saw it.

looking at it now when I look at the code I see the static field is creating it with lower case, but also did not suspect it was an issue since the all caps hadn't caused any failures.

Since it's using the constructor which takes any value it succeeds without error, which in the case you point out, allows for a mis-configured application without realizing it.

If the RFC defines the grant type as all lower case, could the class make the value lower case on instantiation?

Perhaps. However, I think the preference would be not to change user input when possible. In any case, this would be a breaking change and I think it should wait and get some discussion first.

My preference would be to instead encourage users to thoroughly read the reference documentation, which contains examples for each grant type (such as authorization_code and client_credentials).

Perhaps logging a warning would be a viable alternative?

[msosa]

Yeah that makes sense, definitely don't want to have a breaking change for this.

Yes I definitely think a warning would be helpful if that's something that can be done.

[sjohnr]

Thanks. I'll update the title to reflect that it could be logged as a warning. I don't think this will be a high priority for 5.8, but let me know if you'd like to submit a PR for this.

[sjohnr]

Actually, I'll open a new issue for this instead and close this one with a link to it.

[msosa]

Thanks. I'll update the title to reflect that it could be logged as a warning. I don't think this will be a high priority for 5.8, but let me know if you'd like to submit a PR for this.

I can try and submit one, couple of questions though.

Would the warning show if there are any capitals in the value, or would it only show if a value you input is similar to one of the spring-provided defaults?

And would this warning be inside the constructor?