DongHyeonkaandClaude Opus 5
b16e1dccf7
Five simultaneous refreshes with one token return a single 200, and that winner's new token is already dead. Reuse detection removes the client session while the user session stays, which is why the other responses read Session doesn't have required client rather than a reuse error. Comparing policies shows rotation off passes all five and keeps the session, while raising refreshTokenMaxReuse to one still destroys it. Since no retry can recover a removed client session, Q2's own criterion resolves to a lock, and a database row lock is the natural place because its lifetime is tied to the connection. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
12 lines
690 B
Plaintext
12 lines
690 B
Plaintext
=== [1] refresh token 하나 확보 ===
|
|
토큰 길이: 811
|
|
jti: 8e7e3ee2-0dc8-573d-58ec-d12651a50b9c
|
|
sid: BvFiB01Rntz1FcLdf7zG4BNt
|
|
|
|
=== [2] 같은 refresh token 으로 동시에 5회 갱신 ===
|
|
요청 1: HTTP 400 {"error":"invalid_grant","error_description":"Maximum allowed refresh token reuse exceeded"}
|
|
요청 2: HTTP 400 {"error":"invalid_grant","error_description":"Session doesn't have required client"}
|
|
요청 3: HTTP 400 {"error":"invalid_grant","error_description":"Session doesn't have required client"}
|
|
요청 4: HTTP 400 {"error":"invalid_grant","error_description":"Session doesn't have required client"}
|
|
요청 5: HTTP 200 {"access_token":"...(발급됨)
|