On Tue, May 25, 2010 at 1:46 PM, Torsten Lodderstedt <tors...@lodderstedt.net> wrote: >> >> On Tue, May 25, 2010 at 1:21 PM, Torsten Lodderstedt >> <tors...@lodderstedt.net> 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.
I see, thanks for clarifying. Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
