Add jwt-bearer authorization grant

[jgrandja]

Add jwt-bearer authorization grant support.

Related specifications

RFC 7523
2.1 Using JWTs as Authorization Grants

RFC 7521
4.1 Using Assertions as Authorization Grants

Closes gh-6053

[jgrandja]

Merged via 7694aa2 eff4cdc

[H-LREB]

@jgrandja Thank you for the merge.

I have a question about the class JwtBearerOAuth2AuthorizedClientProvider. At line 62, the check of token expiration has been omitted. What happens if token is expired? In my understanding, the Provider will still return null. Won't this cause the expired token to be reused, resulting in a 401 error?

[jgrandja]

What happens if token is expired?

Yes, the request will fail at the resource with 401 and the ServletOAuth2AuthorizedClientExchangeFilterFunction.AuthorizationFailureForwarder will handle the error and ultimately remove the OAuth2AuthorizedClient via the default RemoveAuthorizedClientOAuth2AuthorizationFailureHandler.

RemoveAuthorizedClientOAuth2AuthorizationFailureHandler is also used on authorization/re-authorization failures within OAuth2AuthorizedClientManager. Please review the OAuth2AuthorizedClientManager reference for further details.

[H-LREB]

Thank you @jgrandja for this information.

I understand the importance of the declaring a AuthorizationFailureForwarder, as it is necessary to clear the OAuth2AuthorizedClient when it becomes invalid.
However, in this case, the error is not exceptional or related to some unexpected behaviour. We know for sure that tokens will expire (e.g. every 5 minutes, or every hour ...etc.). This means that developers will have to handle those situations (which happen periodically).
Not only does this give more work / responsibility to development teams (e.g. by doing a retry of the business request using WebClient) but it also makes 401 errors « normal ». This makes it harder to recognize the 401 errors resulting from attack attempts.
In my humble opinion, it is much simpler and more efficient if Spring Security handles token expiration in JwtBearerOAuth2AuthorizedClientProvider (line 62), the same way it does with PasswordOAuth2AuthorizedClientProvider.

What do you think?

[jgrandja]

@H-LREB This is now fixed via gh-9700

[H-LREB]

That is a wonderful news.
Thank you!