Re: [OAUTH-WG] Handling stored tokens in mobile app after software update with client credential change

Hi Andre,

I would expect the AS to treat a client with a different client id as another client. So the new client should not be able to use the "old" refresh tokens.

Some further questions/remarks:
- if you utilize refresh tokens, access tokens should be transient. Right? So you don't need to bother
- public client means w/o secret - there is no security benefit of having a secret for the type of client you described (see Spec section 10)

Regards,
Torsten.

> Am 03.04.2014 um 00:51 schrieb Phil Hunt <phil.hunt@oracle.com>:
> 
> I don’t see a strong reason to standardize behaviour here.  But it seems like a change in scope after a client upgrade is a good reason to expire existing tokens and re-authorize as well as simply expire tokens.
> 
> Some may choose to be very conservative and always expire tokens on any client update. But I think that unless there is a critical security due to the nature of the client and/or server, there is no reason to assume it is necessary beyond “good practice”.
> 
> One good reason for expiring tokens is that you are forcing the client to re-confirm it has the new client credential and it is still valid.
> 
> If you revoke tokens and refresh tokens, your authorization and authentication system might inspect browser cookies that hold the previous SSO state and/or previous authorization state.  Thus you could avoid re-authenticating the user and simply ask about the new scopes.
> 
> Phil
> 
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
> 
>> On Apr 2, 2014, at 1:37 PM, André DeMarre <andredemarre@gmail.com> wrote:
>> 
>> We have a mobile app which operates as an OAuth 2.0 public client
>> (w/client credentials). It uses the resource owner password
>> credentials grant type for authorized communication with our resource
>> servers.
>> 
>> We are working on a software update and want to change the registered
>> client_id and client_secret for the new app version (register a new
>> client at the auth server). The problem is that after the app updates
>> on users' devices, it will inherit the app data of the previous
>> version, including the access and refresh tokens.
>> 
>> Since the token scope issued to the new client might be different, we
>> know that we want the new app version to discard the previous
>> version's access tokens. But what about the refresh token?
>> Technically, the new version of the app will be a different client,
>> but the core OAuth spec section 6 says "the refresh token is bound to
>> the client to which it was issued." So what should we do?
>> 
>> We can program the app to discard the previous version's refresh
>> token, but that would inconvenience our users to re-enter their
>> password after the software update.
>> 
>> I'm tempted to allow the new client to use the refresh token issued to
>> the previous client, but that violates the spec.
>> 
>> Does the OAuth community have any insight here? Thank you.
>> 
>> Kind Regards,
>> Andre DeMarre
>> 
>> _______________________________________________
>> 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