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

Torsten Lodderstedt <torsten@lodderstedt.net> Thu, 03 April 2014 10:13 UTC

Return-Path: <torsten@lodderstedt.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAF61A0134 for <oauth@ietfa.amsl.com>; Thu, 3 Apr 2014 03:13:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.552
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAEjCR8TaLqf for <oauth@ietfa.amsl.com>; Thu, 3 Apr 2014 03:13:40 -0700 (PDT)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.36]) by ietfa.amsl.com (Postfix) with ESMTP id 17DBF1A011C for <oauth@ietf.org>; Thu, 3 Apr 2014 03:13:39 -0700 (PDT)
Received: from [88.128.80.2] (helo=[10.53.168.21]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1WVeeD-0005UO-Aq; Thu, 03 Apr 2014 12:13:25 +0200
References: <CAEwGkqAthUkfpd_iv0YOZNuPk25VkhBV9xkcLWHkTCMZuA15Jw@mail.gmail.com> <1783183C-08FF-46C8-97D1-96BDA0115B2C@oracle.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <1783183C-08FF-46C8-97D1-96BDA0115B2C@oracle.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <4FDD0389-40AB-421F-BB3C-62DE0E47297E@lodderstedt.net>
X-Mailer: iPad Mail (11D167)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Date: Thu, 3 Apr 2014 12:13:25 +0200
To: Phil Hunt <phil.hunt@oracle.com>
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/A9cdtXgG6Eh_XlFOKnSINDsF5ow
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Handling stored tokens in mobile app after software update with client credential change
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=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)

Regards,
Torsten.

> Am 03.04.2014 um 00:51 schrieb Phil Hunt <phil.hunt@oracle.com>om>:
> 
> 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