*: update refresh tokens instead of deleting and creating another #757
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 |
Closed
| @@ -273,6 +268,10 @@ func (a *app) handleCallback(w http.ResponseWriter, r *http.Request) { | |||
| oauth2Config := a.oauth2Config(nil) | |||
| switch { | |||
| case code != "": | |||
| if state := r.FormValue("state"); state != exampleAppState { | |||
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? |
added 4 commits
January 11, 2017 12:07
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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