Am 30.12.2012 um 13:53 schrieb Mark Wubben <[email protected]>:
> On 25 Dec 2012, at 12:24, Torsten Lodderstedt <[email protected]> wrote: >> 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. > > … > >> 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. > > My specific use case is an official mobile app that takes user credentials > and exchanges them directly for an access token. There is no explicit user > consent. The AS could reuse the existing access grant, or create a new > one.They would have the same scope regardless. Other than increased storage > requirements on the server there is no difference. > > Creating different access grants for every authorization would allow the > grant for device A to be revoked while device B keeps working. The user could > also remove the app from device A and then re-install it, which leaves the > old access grant intact and not revoked. > That may be solved by tying authorizations to specific devices, which OAuth > currently does not cover. I'm also not sure whether that'd be feasible > technically. I would assume that the app revokes its refresh token during uninstall, which should cause the revocation of the authorization as well. Or it's automatically invalidated after some inactivity period. regards, Torsten. > > -- > Mark Wubben > > http://novemberborn.net > http://twitter.com/novemberborn > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
