-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider adding support for requesting refresh_token with offline_access scope #1422
Comments
Can you provide more details on your use case? Why do you need to change this behaviour?
In order to support the
FYI, the |
We want clients to explicitly request a refresh token, only when it is needed. We also want to display special text to users on the consent page when |
@nverbos-godaddy Thanks for the extra details. We will consider adding this enhancement depending on demand, which we assess based on upvotes on this issue.
Please keep track of gh-1430 as it will likely provide a hook that will allow you to customize and implement |
@nverbos-godaddy Please take a look at gh-1432, specifically this commit as it provides 2 tests that demonstrate how you can customize and implement partial support for |
Expected Behavior
I want to add support for the
offline_access
scope as described in the openid-connect rfc. When theoffline_access
scope is requested, then a refresh token is issued.Current Behavior
Currently the spring-authorization-server project issues a refresh token when a
RegisteredClient
containsAuthorizationGrantType.REFRESH_TOKEN
. I would like to change this behavior so that the the client must request theoffline_access
scope in order for a refresh token to be issued.Context
What is the best way to add support for this? Initially, I tried copying all of the code from
OAuth2AuthorizationCodeAuthenticationProvider
into my own custom implementation and edited the conditional statement that determines whether or not refresh token should be issued. However, I would like to avoid copying and overriding this for maintainability reasons. Is there a way to customize this for our implementation? Is this a feature that we could add to directly to the spring-authorization-server project?Related gh-501 gh-1430
The text was updated successfully, but these errors were encountered: