mirror/dex - dex - xhrpb gitea

2215 Commits

34 Branches

98 Tags

73 MiB

Branch: v2.34.x

Commit Graph

Author	SHA1	Message	Date
Mark Sagi-Kazar	d25051c867	chore(deps): upgrade protobuf in server/internal package Signed-off-by: Mark Sagi-Kazar <mark.sagikazar@gmail.com>	5 years ago
Eric Chiang	f778b2d33b	server: update refresh tokens instead of deleting and creating another 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.	9 years ago

Author

SHA1

Message

Date

Mark Sagi-Kazar

d25051c867

chore(deps): upgrade protobuf in server/internal package

Signed-off-by: Mark Sagi-Kazar <mark.sagikazar@gmail.com>

5 years ago

Eric Chiang

f778b2d33b

server: update refresh tokens instead of deleting and creating another

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.

9 years ago

2 Commits (v2.34.x)