4 ms·
Hmmm, is there guidance saying that you should auto-redirect? The spec says, "If the authorization server observes multiple attempts to exchange an authorizati
by diafygi 7y ago
Hmmm, is there guidance saying that you should auto-redirect?
The spec says, "If the authorization server observes multiple attempts to exchange an authorization code for an access token, the authorization server SHOULD attempt to revoke all access tokens already granted based on the compromised authorization code."[1]
If an authorization server implements the recommended behavior and an auto-redirect, doesn't that mean that GET requests will no longer be safely considered immutable since they may cause revocation of previous access_tokens?
[1]: https://tools.ietf.org/html/rfc6749#section-10.5 https://tools.ietf.org/html/rfc6749#section-10.5
- couchand 7y agoI did not get the impression that there is an attempt to reuse the authorization code, but rather that a completely new flow was initiated. Reusing the same authorization code should of course be considered suspicious.
- diafygi 7y agoAh, yes, that's correct. I guess I was assuming that once you issue a new authorization code, the authorization server should invalidate any previously issued access_tokens/refresh_tokens because the new authorization code represents a new grant. Or are you supposed to wait until the code is sent to the token endpoint (to get the access_token/refresh_token) before invalidating old access_tokens?
- couchand 7y agoFor web app clients, you definitely don't want to invalidate other access tokens in case the user has other sessions open. For native clients, the calculus might be different.