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

Phil Hunt <phil.hunt@oracle.com> Wed, 02 April 2014 22:51 UTC

Return-Path: <phil.hunt@oracle.com>
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 BB62C1A03F3 for <oauth@ietfa.amsl.com>; Wed, 2 Apr 2014 15:51:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.911
X-Spam-Level:
X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 MBmCPUGaXM6m for <oauth@ietfa.amsl.com>; Wed, 2 Apr 2014 15:51:44 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 183391A040D for <oauth@ietf.org>; Wed, 2 Apr 2014 15:51:44 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s32MpckH026037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Apr 2014 22:51:38 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s32Mpbj1002447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Apr 2014 22:51:38 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s32Mpbqa018783; Wed, 2 Apr 2014 22:51:37 GMT
Received: from [192.168.1.186] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 Apr 2014 15:51:36 -0700
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Phil Hunt <phil.hunt@oracle.com>
In-Reply-To: <CAEwGkqAthUkfpd_iv0YOZNuPk25VkhBV9xkcLWHkTCMZuA15Jw@mail.gmail.com>
Date: Wed, 2 Apr 2014 15:51:35 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <1783183C-08FF-46C8-97D1-96BDA0115B2C@oracle.com>
References: <CAEwGkqAthUkfpd_iv0YOZNuPk25VkhBV9xkcLWHkTCMZuA15Jw@mail.gmail.com>
To: =?windows-1252?Q?Andr=E9_DeMarre?= <andredemarre@gmail.com>
X-Mailer: Apple Mail (2.1874)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/x9HRUjFcpBSfcFb7IuHPYML4aKU
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: Wed, 02 Apr 2014 22:51:48 -0000

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