And we need to say that explicitly. Even if we allow servers to use the two tokens differently, we should clearly state their design considerations and apply any needed restrictions to make that clear. We are leaving way too much to the whims of the individual developer.
Are the access tokens issued using the implicit grant short lived or long lived? Is it valid to issue valid-till-revoked access tokens alongside refresh tokens? What are the requirements for allowing resource owners to revoke access, when it comes to issued access tokens and refresh tokens? Why even issue a refresh token, if the client can authenticate with the authorization server. Why not just include the client identifier and user identifier and let the authorization server lookup what the user already authorized? Yes, this requires different client identifiers for different access rights, but that's easy to do. There are many more open questions. I have been convinced from reading the last 80 or so messages on the list, that we have given developers too much flexibility. We're at a point where I am no longer sure what's the right way of deploying this. I would like to see use enforce a common-sense approach to deploying these tokens, based on the collective wisdom and deployment experience of this group. We have enough hands-on knowledge to agree on how to narrow this down. I am not looking for dramatic changes. I'm looking for restrictions. I want the protocol to be more helpful to developers who are not security experts to make the right decisions, and that includes me. Yes, some use cases will suffer, but that's just what standards are about. EHL From: Kris Selden [mailto:kris.sel...@gmail.com] Sent: Wednesday, June 15, 2011 12:21 PM To: Eran Hammer-Lahav Cc: Brian Eaton; OAuth WG Subject: Re: [OAUTH-WG] Refresh tokens There is a scalability reason, in that the access_token could be verifiable on the resource server without DB lookup or a call out to a central server, then the refresh token serves as the means for revoking in the "an access token good for an hour, with a refresh token good for a year or good-till-revoked." There is a security reason, the refresh_token is only ever exchanged with authorization server whereas the access_token is exchanged with resource servers. This mitigates the risk of a long-lived access_token leaking (query param in a log file on an insecure resource server, beta or poorly coded resource server app, JS SDK client on a non https site that puts the access_token in a cookie, etc) in the "an access token good for an hour, with a refresh token good for a year or good-till-revoked" vs "an access token good-till-revoked without a refresh token." On Jun 15, 2011, at 11:56 AM, Eran Hammer-Lahav wrote: Yes, this is useful and on my list of changes to apply. But I would like to start with a more basic, normative definition of what a refresh token is for. Right now, we have a very vague definition for it, and it is not clear how developers should use it alongside access tokens. EHL
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
