[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 10.140.108.138 with SMTP id j10mr2997273qgf.7.1396471060953; Wed, 02 Apr 2014 13:37:40 -0700 (PDT)
Received: by 10.96.36.229 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 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-WG] Handling stored tokens in mobile app a… André DeMarre
- Re: [OAUTH-WG] Handling stored tokens in mobile a… Phil Hunt
- Re: [OAUTH-WG] Handling stored tokens in mobile a… Torsten Lodderstedt
- Re: [OAUTH-WG] Handling stored tokens in mobile a… George Fletcher
- Re: [OAUTH-WG] Handling stored tokens in mobile a… Torsten Lodderstedt
- Re: [OAUTH-WG] Handling stored tokens in mobile a… Justin Richer
- Re: [OAUTH-WG] Handling stored tokens in mobile a… George Fletcher
- Re: [OAUTH-WG] Handling stored tokens in mobile a… Phil Hunt
- Re: [OAUTH-WG] Handling stored tokens in mobile a… George Fletcher