On Tue, May 25, 2010 at 1:21 PM, Torsten Lodderstedt
<[email protected]> wrote:
As proposed by Marius, the authorization server could issue a refresh token
and the client could use the refresh request in combination with the
downscoping feature in order to acquire access tokens.
Consequences?
In the setup illustrated above, the authorization server cannot create any
access token (or an arbitrary one), it can only return a refresh token. This
would mean to make the access token response parameter optional. Here I'm
colliding with my mental picture of refresh tokens as long-living and
storable tokens. Are these refresh tokens still long-living or as
short-living as a Kerberos TGT? If they are still long-living, what about
the use cases where we don't want to return refresh tokens? As far as I
remember, user agent and username/password flow were candidates. How shall
we handle them?
I think the authz server can create an access token that will grant
access to all requested scopes, just as the corresponding refresh
token. If the client intends to do down-scoping then it will probably
just discard this initial access token.
One way to ensure that the client is not lazy and it is not using the
broadly scoped access token is to have services refuse access tokens
that are not narrowed down to only what the service needs.
Marius
As I said, every service in our setup needs another access token, with
different content, signed and encrypted with another shared secret. It
is technically impossible to create the super access token. Refresh
tokens are just handles representing the user's authorization and
are used by the authz server only. They therefore can represent any scope.
regards,
Torsten.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
