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 _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
