-
Notifications
You must be signed in to change notification settings - Fork 395
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
Refresh Token implementation and RFC 6749 #220
Comments
Any update? |
Any update? it has been more then a year since the initial request for this feature |
For the same reason I have decided not to use it and implement my own. A shame. |
@appleboy would you consider merging a PR implementing this ? That would be a breaking change for v3.0 I guess. |
This issue makes this package non usable for me. |
You could also explicitly state that in the docs the refresh token isn't implemented as one would expect, which would make everything a lot clearer |
As far as I see gin-jwt consider Access token as same as Refresh token.
When we login, in response we can find a token that later we can send to refresh endpoint.
Additionally, we have also MaxRefresh settings, that allows us to refresh token, even if it is expired.
As far as I understand this approach increases security risks. The idea of refresh token - get it once, hide it better than access token and use it only for auth purposes, but not for access to resources.
Here RFC that clarify flow: https://tools.ietf.org/html/rfc6749#section-1.4.
Question is: what is the reason that gin-gwt implement it like this? How about to follow RFC6749?
The text was updated successfully, but these errors were encountered: