We don't want to share grant information across multiple instances of public client.
However we don't necessarily want to preclude multiple instances of a private client, Though how the AS would tell them apart is a interesting side question. >From a revocation point of view if you revoke the grant for one instance of a >client you revoke it for all, though for a public client the grant is not >doing anything anyway as the AS shield not be pre approving based on the grant. There are still some open questions about an extension to identify client instances, though personally I prefer to have each instance with it's own client ID. The language around grants has always been a bit philosophical for my taste. If I recall correctly in the code flow the code is the representation of the grant. In the implicit flow the grant is implicit in the access token. What construct (if any in the implicit case) is stored in the AS to represent this is mostly left to the imagination of the implementer. John B. On 2012-12-25, at 8:24 AM, Torsten Lodderstedt <tors...@lodderstedt.net> wrote: > Hi Mark, > > thanks for reviewing the draft. Comments inline. > > Am 02.12.2012 18:27, schrieb Mark Wubben: >> The draft relies heavily on the definition "access grant", but no definition >> is provided in the draft or RFC 6749. It's been my interpretation that an >> "access grant" is the *fact* that a resource owner has authorized a client >> (potentially scoped) access to the protected resources. Once access is >> granted in this manner, further access tokens may be obtained without >> explicit permission by the end-user. That is, in the Protocol Flow there is >> no user input between steps A and B. > > That's correct. > >> >> In "1. Introduction" it is stated: >> >>> A >>> revocation request will invalidate the actual token and, if >>> applicable, other tokens based on the same access grant and the >>> access grant itself. >> then, in "2. Token Revocation": >> >>> In the next step, the authorization server invalidates the token and >>> the respective access grant. If the particular token is a refresh >>> token and the authorization server supports the revocation of access >>> tokens, then the authorization server SHOULD also invalidate all >>> access tokens based on the same access grant >> This implies that an access grant only applies to an app authorized on a >> single device. If an app is installed on multiple devices and the access >> grant is shared between both instances, revoking device A's access token >> results in the unexpected revocation of device B's token. > > You raised an interesting point. Is it desirable to share an access grant > among different client instances? I would like to discuss this topic in the > working group. > > If we assume it is desirable, how would the authorization process look alike? > > I would assume that as result of the authorization process of the 1st client > instance, the authorization server stores an access grant, which is > identified by the client_id and the user_id of the resource owner. Moreover, > it creates a refresh token, which the 1st client instance uses to obtain new > access tokens. As this client is public, the refresh token is the credential > the intial client uses to prove its identity. > > How does the 2nd client instance join the party? I would assume the 2nd > client to initiate another code grant type flow (using the same client_id as > the 1st client). I see two ways the authorization server could process this > process: > > 1) After authenticating the resource owner, the authorization server finds > the existing access grant for the client_id/user_id combination and > automatically issues tokens w/o further user consent. Since the authorization > server cannot authenticate the client_id, a malicious client could obtain and > abuse the access grant of the legitimate client. That's why the security > considerations of the core spec > (http://tools.ietf.org/html/draft-ietf-oauth-v2-31#section-10.2) state: > > The authorization server SHOULD NOT process repeated authorization > requests automatically (without active resource owner interaction) > without authenticating the client or relying on other measures to > ensure the repeated request comes from the original client and not an > impersonator. > > Validating the redirect URI won't help that much, since this URI is typically > device local (custom scheme or localhost). > > 2) The authorization server asks the resource owner for user consent and > issues another pair of access/refresh token to the 2nd client. In this case, > why would one bind this tokens to the already existing access grant? This > would limit the resource owners capability to revoke grants for particular > instances. I would rather create another access grant. > > Based on this thoughts I think it is not desirable to share an access grant > among different client instances. > > What do others think? > >> >> If "access grant" could be defined as "an authorization issued to the >> client, based on the single use of an Authorization Grant" it becomes clear >> than only the tokens spawning from the app's authorization on device A >> should be revoked. > > I would like to adopt your proposal if the WG agrees. > >> >> --- >> >> I spotted a typo in "3. Implementation Note": > > Thanks. Fixed. > > regards, > Torsten. >> >>> Whether this is an viable option or >>> whether access token revocation is required should be decided based >>> on the service provider's risk analysis. >> "an viable option" should be "a viable option". >> >> On 24 Nov 2012, at 18:13, Hannes Tschofenig <hannes.tschofe...@gmx.net> >> wrote: >> >>> Hi all, >>> >>> this is a working group last call for draft-ietf-oauth-revocation-03 on >>> "Token Revocation". The draft is available here: >>> http://tools.ietf.org/html/draft-ietf-oauth-revocation-03 >>> >>> Please send you comments to the OAuth mailing list by December 10, 2012. >>> >>> Thanks, >>> Hannes & Derek >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> -- >> Mark Wubben >> >> http://novemberborn.net >> http://twitter.com/novemberborn >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
