Summary
I have to consume a 3rd party REST API. This API does not support client_credentials authentication grant type. Instead they have a process of getting a long-lived refresh token. However, it is not easy to integrate the refresh token into the WebClient request to get an access token.
Was hoping to just configure the same way I would given a client_credentials flow. Something similar to:
spring:
security:
oauth2:
client:
registration:
external-api:
client-id: <client_id>
client-secret: <client_secret>
client-authentication-method: CLIENT_SECRET_BASIC
refresh_token: <refresh_token>
authorization-grant-type: refresh_token
provider:
external-api:
token-uri: https://external-api.com/oauth2/token
Expected Behavior
Configuration or guide that shows how this can be achieved.
Comment From: sjohnr
Hi @sickan90, thanks for reaching out!
I believe this is related to this question, correct?
Was hoping to just configure the same way I would given a client_credentials flow.
The configuration properties referenced in your example are part of Spring Boot, and so would not be directly in scope for Spring Security.
Additionally, the refresh_token grant rarely exists in isolation and is not exactly like client_credentials, which only requires an OAuth 2.0 Token Request to complete. Another grant is usually required to gather the refresh token in the first place. While there are use cases that can require loading a refresh token gathered from another source, the way that refresh token would be used and how it would be managed within an application is entirely application-specific.
For example, should all users interacting with the application share the use of this refresh token? I don't believe this would be a good default, hence customization examples like this in the reference documentation contain this warning:
It is recommended to be cautious with this feature since all HTTP requests will receive the access token.
Finally,
Configuration or guide that shows how this can be achieved.
The accepted answer on stackoverflow should provide a good starting point for this. If you have any thoughts on how it can be improved, please feel free to add a comment on that answer.
As it sits, this enhancement isn't applicable and doesn't quite align with the existing OAuth2 Client features and therefore seems best as a customization in the application. If you have additional ideas or details from the specification about how this could better fit in the framework, feel free to share and we can open a new enhancement to capture this. For now, I'm going to close this issue.