Hi Torsten,
I get the point for a BCP around the revocation/validity of refresh
tokens. I’ll compile a documents for what we thought should be the
best practice around limiting the validity of refresh tokens (too many
of these were unused, and keeping them alive was both a security
liability, and performance overhead). Would I have to send the draft
to oauth@ietf.org <mailto:oauth@ietf.org>? or a specific working group
email?
Thanks again for your response.
--
Thanks
Amit
*From:*Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
*Sent:* Sunday, January 18, 2015 2:11 PM
*To:* Amit Gupta
*Cc:* Justin Richer; sdro...@gmx.de; oauth@ietf.org; mscurte...@google.com
*Subject:* Re: [OAUTH-WG] RFC 7009 OAuth 2.0 Token Revocation
//proposed change wrt to "default" revocation of refresh tokens
Hi Amit,
as far as I understand you are asking for a documentation of
guidelines for refresh token lifecycle management. Such guidlines are
not in scope for RFC 7009, as it only wants to add a request to the AS
to give the client an (interoperable) way to explicitly revoke tokens.
Tokens lifecycle (incl. expiration) and respective policies are at the
discretion of the AS. Those topics are intentionally left unspecified
by this and other OAuth RFC in order to not limit the design options
of AS implementations. Note for example that our (Deutsche Telekom's)
AS treats refresh token expiration differently then your
implementation. But thanks to RFC 7009, a client could revoke tokens
using the same code snippet at both ASs.
Guidelines could be documented in an additional BCP (best current
practice) RFC. If you like, you can post an individual draft and ask
the WG to adopt it as WG document.
Best regards,
Torsten.
Am 16.01.2015 um 17:10 schrieb Amit Gupta <amit.gu...@insideview.com
<mailto:amit.gu...@insideview.com>>:
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
<mailto: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 clt^th 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 5^th (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
