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

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