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

André DeMarre <andredemarre@gmail.com> Wed, 02 April 2014 20:37 UTC

Return-Path: <andredemarre@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 4C1851A03D7 for <oauth@ietfa.amsl.com>; Wed, 2 Apr 2014 13:37:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id WZzIXyp5AGPk for <oauth@ietfa.amsl.com>; Wed, 2 Apr 2014 13:37:45 -0700 (PDT)
Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6581A03D2 for <oauth@ietf.org>; Wed, 2 Apr 2014 13:37:44 -0700 (PDT)
Received: by mail-qg0-f49.google.com with SMTP id e89so776618qgf.8 for <oauth@ietf.org>; Wed, 02 Apr 2014 13:37:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=fRD7YYGjqU8eSAbRPCc3hQawpPlqlnNOnRXBC3niEB8=; b=N32FPparfhvi3EiCw7dvLmwR451h6nOGJoT0YgWiERO+ZwpGLQYnChLOF3uEtKgpNS 4ejYisi0D540yK6tI4qiOhjJvieFk8oRk21eSwgLMowlK6v7VgYFsKyZXCKSgtJzP+Hq 18eYyOjBvHhL3YP72x1PWrU9ICLteMfpULX85p6mL3rMmJmjd5hZVb/yH6M/YdIX28ZG uP6d1zXPQ0Y5r8sWs/bBQocGluNWxqblcllmN6icYOqN78uOTiJG+icXr6q4oZcTF/BK Zzkmo9NAcoN4AImet1FAVVqi3sshbrJtKpWO97td40Mjsa5Ywr5Gf4wVLmzV0JM3tdPP Qw2g==
MIME-Version: 1.0
X-Received: by with SMTP id j10mr2997273qgf.7.1396471060953; Wed, 02 Apr 2014 13:37:40 -0700 (PDT)
Received: by with HTTP; Wed, 2 Apr 2014 13:37:40 -0700 (PDT)
Date: Wed, 02 Apr 2014 13:37:40 -0700
Message-ID: <CAEwGkqAthUkfpd_iv0YOZNuPk25VkhBV9xkcLWHkTCMZuA15Jw@mail.gmail.com>
From: André DeMarre <andredemarre@gmail.com>
To: OAuth WG <oauth@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/H6KqOc5A--xXJ5MHwpfGDOuA32c
Subject: [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 20:37:51 -0000

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

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