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 <[email protected]>: > > 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 > [email protected] > >> On Apr 2, 2014, at 1:37 PM, André DeMarre <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
