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

George Fletcher <gffletch@aol.com> Thu, 03 April 2014 13:43 UTC

Return-Path: <gffletch@aol.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 D134C1A0205 for <oauth@ietfa.amsl.com>; Thu, 3 Apr 2014 06:43:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.01
X-Spam-Level:
X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Z9ZXASKOS9Dw for <oauth@ietfa.amsl.com>; Thu, 3 Apr 2014 06:43:37 -0700 (PDT)
Received: from omr-m02.mx.aol.com (omr-m02.mx.aol.com [64.12.143.76]) by ietfa.amsl.com (Postfix) with ESMTP id 784FF1A0204 for <oauth@ietf.org>; Thu, 3 Apr 2014 06:43:27 -0700 (PDT)
Received: from mtaout-mae01.mx.aol.com (mtaout-mae01.mx.aol.com [172.26.254.141]) by omr-m02.mx.aol.com (Outbound Mail Relay) with ESMTP id 2A5697022B761; Thu, 3 Apr 2014 09:43:23 -0400 (EDT)
Received: from [10.172.4.228] (unknown [10.172.4.228]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mae01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id C91D9380000A3; Thu, 3 Apr 2014 09:43:22 -0400 (EDT)
Message-ID: <533D657A.2020106@aol.com>
Date: Thu, 03 Apr 2014 09:43:22 -0400
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Torsten Lodderstedt <torsten@lodderstedt.net>, Phil Hunt <phil.hunt@oracle.com>
References: <CAEwGkqAthUkfpd_iv0YOZNuPk25VkhBV9xkcLWHkTCMZuA15Jw@mail.gmail.com> <1783183C-08FF-46C8-97D1-96BDA0115B2C@oracle.com> <4FDD0389-40AB-421F-BB3C-62DE0E47297E@lodderstedt.net>
In-Reply-To: <4FDD0389-40AB-421F-BB3C-62DE0E47297E@lodderstedt.net>
Content-Type: multipart/alternative; boundary="------------070505040606000308020008"
x-aol-global-disposition: G
X-AOL-VSS-INFO: 5600.1067/97355
X-AOL-VSS-CODE: clean
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1396532603; bh=3a/DgYsJHHA/QN4/+PT+2x8tdZb/d8GnHdsR1RJbijw=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=Bu41qMPXpCV9oZeRVtVPhrQrrmADFkoiUBkmlnIL7bFVi7AccU+17rlTKFNX/s+cM AwG/5sRV7pOqIMC7wWGjNhhMgfJRlVe+FCkSswYWFZkcLRQ818FyRQEcWVbis/5G4f KkIFQqOSp6+et7+/M5OOxs+81lPTPOt34/kypO8w=
x-aol-sid: 3039ac1afe8d533d657a7c42
X-AOL-IP: 10.172.4.228
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Zvg8AAQgjp9D-XrYfTs4NGqOmVI
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 13:43:43 -0000

Hi Torsten,

We actually have the same issue. Deployed clients in the field where we 
want to update the client_id and doing so invalidates the existing 
refresh_token stored with the client. From a user experience 
perspective, this is a pain and from a risk perspective I think it's 
fine to effectively do a "token exchange" from the old refresh_token to 
the new one (with the appropriate security considerations in mind).

Andre got me thinking about this and here is what I'm leaning towards 
implementing in our system.

Use the JWT Client Assertion flow requesting an authorization grant for 
the existing user. The JWT would contain an "iss" of the new client_id, 
a "sub" of the userid the client should already know about, an "aud" of 
the Authorization Server, a short lived "exp" value as this is 
effectively a one-time token exchange, and an additional claim of the 
old refresh_token. Maybe an additional claim with the old client_id as 
well (still thinking about that as the client_id is already associated 
with the refresh_token).

This allows the AS to do the following checks...
1. Make sure the assertion is being presented by the new client (the 
level of surety is based on the risk associated with the client. If the 
client is provisioned with additional keys some how that's much stronger 
than just using a client_secret which, as you point out, doesn't really 
prove anything).
2. Verify that the "sub" value in the JWT is the same as that identified 
by the refresh_token
3. Verify that the client_id defined as the "issuer" is allowed to make 
this token exchange call and that the client_id in the refresh_token is 
one of those being replaced
4. Verify the audience of the JWT

If all the checks pass, then a new refresh_token can be issued, with 
exactly the same scopes as the "old" refresh_token (no ability in this 
flow to change scopes). The semantics of the refresh_token (e.g. authN 
time, expiry time, etc) need to be copied to the new refresh_token. In 
other words there should be no way to "extend" the lifetime of the 
refresh_token via this mechanism. It's purely a token exchange to 
provide a new refresh_token mapped to the new client_id.

Interested in feedback as to the viability of this.

Phil, I agree this doesn't need to be standardized, and I would like to 
see the community start collecting some "best practices" to help others 
that come across the same use case. It will ensure a more secure 
internet for all of us.

Thanks,
George

On 4/3/14, 6:13 AM, Torsten Lodderstedt wrote:
> 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>:
>>
>> 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
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
George Fletcher <http://connect.me/gffletch>