Hi Adam,
our OAuth implementations at Deutsche Telekom issue refresh tokens and
we use different access tokens for different RS (for privacy and
security reasons). Today, there is a one-to-one relation between access
and refresh token, which means a client needs to acquire and retain
several refresh tokens. In our experience, this increases complexitity
for the developer and causes them to use other patterns. They use a
master access token and exchange this for other access tokens using a
custom assertion grant type. In my opinion, it would be much simpler to
use a refresh token instead. So we consider to use one refresh token per
client, which can be associated with several services and thus can be
used to obtain access tokens with different scope.
I support your requirement and would like to discuss it in the WG.
regards,
Torsten.
Am 31.10.2012 21:29, schrieb Lewis Adam-CAL022:
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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
