Hi,
Ross Boucher <[email protected]> schrieb: >The spec doesn't seem to have any recommendations on this point, but >should an OAuth v2 API always return the same access token if the same >client makes multiple requests? Is there any benefit to not generating >a new access token for each request? I don't see any. >Similarly, if you do generate new >access tokens (as I am doing now), should you also generate new refresh >tokens? Depends on the grant type. I would expect an authz server to generate new refresh tokens for "code", whether the authz server creates a new one for grant type "refresh_token" might depend on server impl. and client-specific policy (refresh token rotation). > >An unrelated question about revoking access tokens when the same >authorization code is used more than once: should refresh tokens also >be revoked? Does it make sense to not revoke refresh token? Otherwise, it could be used to obtain fresh access tokens. > And, if so, should any tokens issued with that refresh >token then also be revoked? It seems :-) sounds reasonable but not nessessarily feasable > simpler (if slightly less correct) >to just revoke all access tokens for that specific client/resource pair >in that case, rather than tracking the ancestry of all tokens. Generally, I would consider revoking access tokens more difficult then revoking refresh tokens. It depends on your token design. One can use handles for refresh tokens and self-contained access tokens and revoke refresh tokens only. In that case, I would limit the access token lifetime in order to force a periodic refresh. Regarding client/resource: Depends on whether you are able to really identify a particular client instance. Otherwise, you would revoke tokens for different (potentially a lot of) client installations using the same client_id. regards, Torsten. > >Thanks, >Ross_______________________________________________ >OAuth mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
