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

Torsten Lodderstedt <> Thu, 03 April 2014 10:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0EAF61A0134 for <>; Thu, 3 Apr 2014 03:13:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.552
X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hAEjCR8TaLqf for <>; Thu, 3 Apr 2014 03:13:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 17DBF1A011C for <>; Thu, 3 Apr 2014 03:13:39 -0700 (PDT)
Received: from [] (helo=[]) by with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from <>) id 1WVeeD-0005UO-Aq; Thu, 03 Apr 2014 12:13:25 +0200
References: <> <>
Mime-Version: 1.0 (1.0)
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
X-Mailer: iPad Mail (11D167)
From: Torsten Lodderstedt <>
Date: Thu, 03 Apr 2014 12:13:25 +0200
To: Phil Hunt <>
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Cc: OAuth WG <>
Subject: Re: [OAUTH-WG] Handling stored tokens in mobile app after software update with client credential change
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Apr 2014 10:13:44 -0000

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)


> Am 03.04.2014 um 00:51 schrieb Phil Hunt <>:
> 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
>> On Apr 2, 2014, at 1:37 PM, André DeMarre <> 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 mailing list