The present rfc does not specify if the server should indefinitely keep the refresh token functional for every token (except revoked ones), and most refresh tokens are not used (due to authorize workflow is triggered by clients for authentication and resource access).
Hence, I feel the rfc should provide guidance for the transparent ways to limit validity of refresh tokens and what property/setting should be used to automatically expire refresh tokens, and who (between the server, client or uset) should be able to specify/modify/see this property(s). In our implementation, the client can specify/modify this property (or server to set default) to limit refresh tokens. Its not clear if the user have visibility in number of refresh tokens before consent (or a say in refresh token revocation). -- Thanks, Amit Gupta Software Security Architect, InsideView Inc. Sent from my mobile device, Please excuse spelling typos. On Jan 16, 2015 7:07 PM, Justin Richer <jric...@mit.edu> wrote: This seems to be more of an implementation of revocation and handling refresh token lifetimes than anything that the spec would talk about. In what's described below, it doesn't seem that the client ever specifies the threshold, nor would the AS desire the client to do so. This is all something that can happen server-side, out of the view of the client. In other words, I don't (personally) see what would have to change in the RFC for someone to implement this scheme. Can you please clarify what I'm missing? -- Justin On 1/16/2015 3:39 AM, Amit Gupta wrote: Hi Torsten, Stefanie, Marius I wanted to suggest an addition to the token revocation rfc7009 to provide more clarity on how revocation of refresh tokens should be handled. I feel the rfc should, 1. Describe how the client/resource-owner can provide “standing instructions” to the OAuth server to revoke refresh tokens. 2. Describe the default way to for the OAuth server to define constrains for revocation of refresh token if this constrains are not specified by the client/resource owner. The way it could be handled is: 1. Store a Client level threshold (clt) of number of valid refresh tokens per “user-client” combination (and OAuth server can store the default value for clt, if undefined by the client or resource owner). 2. Keep the “time to live” for the access token reasonably small (few minutes to couple of hours). a. Revocation of active token removes the token ad the refresh token. b. When new tokens are generated, up to “clt” number of Refresh tokens is maintained by the OAuth server (the most recent refresh token over writes the cltth refresh token for user-client combination). c. Revocation of inactive token removes the refresh token. We have implemented such a scheme for our OAuth server, whereby “clt” is set to five by default (if not specified in client the properties). Therefore, 1. Whenever a new token and refresh token is created, it overwrites the 5th (clt=5) oldest refresh token (for clientId-userId combination). 2. Code grant tokens are only valid for 1 hour. When the token expires, refresh token is not removed. 3. When an “active” token is revoked, Token and it’s refresh token is also revoked. 4. When an “expired” token is revoked, only the corresponding refresh token is revoked. The above example explicitly specify how to handle revocation of refresh tokens when the client has not informed the OAuth server about how expiry of refresh tokens should be handled. This also allows clients to specify certain constrains (like default time to live for tokens, and client level threshold for number of refresh tokens to keep active for each client-user combination). Are you planning to update the RFC on the scheme to handle revocation of refresh token? If not, would you be willing to include the proposed changes to RFC7009? Please let me know. -- Thanks, Amit _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
