Apologies if I'm speaking out of school :) but it seems the Refresh Token offers an opportunity for solving Torsten's problem.
- Instead of calling it a Refresh Token, why not redefine it as a Service Token (or Sub-Access Token) with a specific scope and intended Resource Server. - In 3.3.1., when the Client perform authentication it needs to identify the multiple Resource Servers it seeks to access (each with a separate scope and requested access lifetimes). - In the Access Token Response (3.3.2.1) coming back from the Authorization Server, the response would contain a matching number of Service Tokens, each with a separate access_secret, scope, expires_in values. - The Client can then use any of these Service Tokens independent of the original Access Request, until the expiration of the Service Token. No need for the Client to prompt the human user. /thomas/ > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Marius Scurtescu > Sent: Tuesday, May 25, 2010 4:51 PM > To: Torsten Lodderstedt > Cc: OAuth WG ([email protected]) > Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization > flow? > > On Tue, May 25, 2010 at 1:46 PM, Torsten Lodderstedt > <[email protected]> wrote: > >> > >> 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. > > I see, thanks for clarifying. > > Marius > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
