-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Allow for reduced scopes when issuing new refresh tokens #47
Comments
I already mentioned this and checked the RFC for the correct behaviour some time before (and this is also important for allowing multiple access tokens). Here again what I wrote: The Refresh Token Grant must differ between two cases - issue a new refresh token when a new access token is created, or not. This defines the further steps in the flow and the possibilities on the client side. Therefore it must be possible to define the preferred behavior for this Grant: RefreshToken::useRefreshTokenRotation(true|false) If TRUE:
If FALSE:
|
Surely
So the flow goes:
IF TRUE:
IF FALSE:
I don't understand why you think it should error if the scope param is set. In section 6 it says:
Therefore it should only error if the request includes additional scopes that weren't originally used in the request. |
That's basically right, but there is one special case, when token rotation is activated and the scope is limited at the same time - this leads to the following problem:
I think this can be solved by
|
After some drawing this out on a piece of paper I agree. I'll implement it. |
Implemented in e591fbb |
I also thought about it and I think this is a problem of the dtabase structure: The scopes depend of the access token, which is correct, But you can hve multiple access tokens and I think it is also possible, that an old access token is deleted, while the session itselt and the refresh tokens are still valid. This could lead to a sitiuation where you cannot get the original scope anymore. I think we need to save the original scope for the session in an additional table, just for re-creating them (so only if we create a refresh token). This would make the scopes independent from the access token an you would be able to always rote tokens and limit scopes, also at the same time. |
As discussed in point 7 in #41
The text was updated successfully, but these errors were encountered: