Hi Dick, Totally agree about keeping things simple :)
I'll be the first to admit that many of my use cases are edge cases, but I was sort of hoping that "this one" might find some common mindshare within the community. Maybe it is just Google using refresh tokens today on the social web, but I think we all know that OAuth is going to have life well beyond the social web. Whether that's good or bad has of course been the foundation of so much of the recent "entertainment" in the OAuth blogsphere :) If I can't find anybody else in the community to agree that what I propose is useful, then I'll cry uncle and let it rest. Btw, in response to your question "why not have 3 different calls to the AS so that there are separate refresh tokens for each RS? " ... it all comes down to end user experience / latency. -adam From: Dick Hardt [mailto:[email protected]] Sent: Wednesday, October 31, 2012 3:11 PM To: Lewis Adam-CAL022 Cc: Dick Hardt; [email protected] Subject: Re: [OAUTH-WG] access tokens & refresh tokens of different scopes Hi Adam Give your clarification, why not have 3 different calls to the AS so that there are separate refresh tokens for each RS? If you don't want to do that, then you will need to make the second call. I'm not too keen on making the protocol more complicated for an edge case. btw: the only AS I know that uses refresh tokens in the social web is Google. All others have long lived access tokens IF the user granted long lived access. -- Dick On Oct 31, 2012, at 12:54 PM, Lewis Adam-CAL022 <[email protected]<mailto:[email protected]>> wrote: Hi Dick, I guess one thing that didn't quite come out in my first explanation is that the scopes could belong to different resource servers. So I'd rather not hand RS1 an access token that can be used to access protected resources on RS2 or RS3. That is too much power for any RS to have :) Granted if I were using a holder of key profile of OAuth (something I am also very interested in) that could prevent such a thing from happening. But even with that in place, it seems ugly to send a set of scopes to an RS that only supports a subset of those scopes (though I know it's done that way today). I know a lot of my use cases are a bit atypical for the wg, but It still seems to me to be in line with the OAuth spirit to keep the access token as restricted as possible (both in terms of lifetime and in terms of scope). adam From: Dick Hardt [mailto:[email protected]<http://gmail.com>] Sent: Wednesday, October 31, 2012 12:19 PM To: Lewis Adam-CAL022 Subject: Re: [OAUTH-WG] access tokens & refresh tokens of different scopes If the latency is important, you can deal with the latency by making the first call to the RS with the original access token while you are waiting for the stricter scoped access token to come back. Once you have a stricter scope access token, you can replace the original access token. In practice, I don't think the latency is going to be an issue, and myself, I would be making a call to get a new access token just before I was going to do some work since the access token is very short lived. -- Dick On Oct 31, 2012, at 10:00 AM, Lewis Adam-CAL022 <[email protected]<mailto:[email protected]>> wrote: I have a use case where I would like to request both an access token and a refresh token, but I would like the access token to have a scope less than that of the refresh token. It is standard OAuth behavior for using the refresh token to request additional access tokens (of equal or lesser scope) but the first access token that comes back always has the "master scope" of the refresh token. For various security concerns, I always want my access tokens to be of a stricter scope that the refresh token. For example, consider the scenario of a structured (JWT) access token that does not require the RS to call back to the AS introspection endpoint. Following typical OAuth guidance, it is best practice to use short lived access tokens with long lived refresh tokens. But I'd rather a compromised access token not compromise access to ALL my resource servers. Using the existing standard I could simply destroy the first access token when it is received and then request another of lesser scope using the refresh token, but now I've just wasted a round trip over the air, consuming bandwidth and adding latency to the end user experience. Is there anybody in the working group that feels this would be valuable? adam _______________________________________________ OAuth mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
