Expected Behavior When an Authorization Server returns an access token with a custom attribute for scope, the value stored in the database column oauth2_authorized_client.access_token_scopes contains the scope(s) in the access token.

Current Behavior When an Authorization Server returns an access token with a custom attribute for scope (e.g. "scp": "read_notifications.v1"), the value stored in the database column oauth2_authorized_client.access_token_scopes is null.

Context The application I am developing has different scopes based on the features enabled. I need to be able to query oauth2_authorized_client on the access_token_scopes column to find a match so I use the proper access token. However that column is empty because the 3rd party Authorization Server returns an access token with the attribute "scp": for scopes.

The Spring ResourceServer DSL has jwtAuthenticationConverter(). Something similar would be ideal as it happens upstream from all Oauth2AuthorizedClient behavior.

The only alternative I have thought of to date is to modify the schema for oauth2_authorized_client to include a generated primary key and then create a separate table with the scopes with a link to the generated primary key. I would have to figure out how to call the logic to populate this table. I considered GrantedAuthoritiesMapper but I "think" it is too late in the flow, i.e. the row has already been written by the time it would be called.

A workaround might be to subclass R2dbcReactiveOAuth2AuthorizedClientService with a custom OAuth2AuthorizedClientParametersMapper.

Comment From: sjohnr

Hi @tvogel8570, thanks for reaching out! I see two things in your issue:

  1. A question about how to properly configure OAuth2 Client support to parse and save the scp attribute in an OAuth2 Access Token Response.
  2. An enhancement suggestion of a way to easily configure handling the scp attribute for all clients.

Regarding 1, please see Customizing the Access Token Response and the existing OAuth2BodyExtractors class. Note that this has little to do with R2dbcReactiveOAuth2AuthorizedClientService which is only used for persisting the result.

For 2, we're currently working on gh-11783 (and more specifically gh-13288) which I'm hoping will provide an easy way of customizing the entire chain of components required to make and handle token requests. While it is currently possible today (see docs), an easier way to customize the access token response (via a BodyExtractor) will be part of that solution.

Does that help? Does it feel like I've understood your request(s) correctly?

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: spring-projects-issues

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.