*: update refresh tokens instead of deleting and creating another#757
Conversation
ericchiang
force-pushed
the
constant-refresh-tokens
branch
2 times, most recently
from
2c8753e to
3ee1d92
Compare
ericchiang
force-pushed
the
constant-refresh-tokens
branch
from
3ee1d92 to
13b5649
Compare
|
rebase for good measure. |
ericchiang
force-pushed
the
constant-refresh-tokens
branch
from
13b5649 to
98c7ed7
Compare
|
There was a conflict with #767. Rebased, updated to include the fix, and ran the Kubernetes integration tests. |
ericchiang
force-pushed
the
constant-refresh-tokens
branch
from
98c7ed7 to
2ecb196
Compare
|
@rithujohn191 please take a look |
rithujohn191
left a comment
rithujohn191
left a comment
There was a problem hiding this comment.
Everything LGTM. Just had a small doubt.
There was a problem hiding this comment.
Just wondering if there is a reason why we should not perform this check for "state" in case of 'refresh'
There was a problem hiding this comment.
"state" is only part of a auth code response[0]. it's not part of a refresh event.
I think it's confusing because we're handling both the auth request redirect response (GET) and a frontend post to re-render the page (POST). Maybe we should switch this so GETs and POSTs are what determine the course of action? e.g.
switch r.Method {
case "GET":
// ... handle state and do code exchange
case "POST":
// ... try to refresh token
}
There was a problem hiding this comment.
Yes that would definitely make the flow more clear
ericchiang
force-pushed
the
constant-refresh-tokens
branch
from
2ecb196 to
0f5ce72
Compare
|
@rithujohn191 Updated the example-app. |
|
Might need a rebase? |
The server implements a strategy called "Refresh Token Rotation" to ensure refresh tokens can only be claimed once. ref: https://tools.ietf.org/html/rfc6819#section-5.2.2.3 Previously "refresh_token" values in token responses where just the ID of the internal refresh object. To implement rotation, when a client redeemed a refresh token, the object would be deleted, a new one created, and the new ID returned as the new "refresh_token". However, this means there was no consistent ID for refresh tokens internally, making things like foreign keys very hard to implement. This is problematic for revocation features like showing all the refresh tokens a user or client has out. This PR updates the "refresh_token" to be an encoded protobuf message, which holds the internal ID and a nonce. When a refresh token is used, the nonce is updated to prevent reuse, but the ID remains the same. Additionally it adds the timestamp of each token's last use.
ericchiang
force-pushed
the
constant-refresh-tokens
branch
from
0f5ce72 to
ed20fee
Compare
2 participants
The server implements a strategy called "Refresh Token Rotation" to
ensure refresh tokens can only be claimed once.
ref: https://tools.ietf.org/html/rfc6819#section-5.2.2.3
Previously "refresh_token" values in token responses where just the
ID of the internal refresh object. To implement rotation, when a
client redeemed a refresh token, the object would be deleted, a new
one created, and the new ID returned as the new "refresh_token".
However, this means there was no consistent ID for refresh tokens
internally, making things like foreign keys very hard to implement.
This is problematic for revocation features like showing all the
refresh tokens a user or client has out.
This PR updates the "refresh_token" to be an encoded protobuf
message, which holds the internal ID and a nonce. When a refresh
token is used, the nonce is updated to prevent reuse, but the ID
remains the same. Additionally it adds the timestamp of each
token's last use.
cc @rithujohn191