[OAUTH-WG] client credentials returning a refresh token

Brian Eaton <beaton@google.com> Sun, 11 July 2010 03:09 UTC

Return-Path: <beaton@google.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C585C3A68D9 for <oauth@core3.amsl.com>; Sat, 10 Jul 2010 20:09:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.471
X-Spam-Level:
X-Spam-Status: No, score=-105.471 tagged_above=-999 required=5 tests=[AWL=0.506, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sExQ8YYrZPdj for <oauth@core3.amsl.com>; Sat, 10 Jul 2010 20:09:15 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id B0C283A66B4 for <oauth@ietf.org>; Sat, 10 Jul 2010 20:09:15 -0700 (PDT)
Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id o6B39Lv6026887 for <oauth@ietf.org>; Sat, 10 Jul 2010 20:09:22 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278817762; bh=9iPp8Xmp3ZKN14JvzRxhNcmRm90=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=p9mkY9wkigbOFYc71PoYGWIVBpcp6+7IGTQ0yuchTj364F8IIa9v8AMoE0Zu+f5Gg X7kCvwianEUwb/KHh6PCw==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type:x-system-of-record; b=X0j/1NITu3JeBgUzt4zadTrv5oAm8WjZAXBZshIfyTvXdTUvKc4NNx6xJ/nDyB9Md rrtPPZ4KM9Nba33+4zWZA==
Received: from pwj8 (pwj8.prod.google.com [10.241.219.72]) by kpbe14.cbf.corp.google.com with ESMTP id o6B39KNU011362 for <oauth@ietf.org>; Sat, 10 Jul 2010 20:09:21 -0700
Received: by pwj8 with SMTP id 8so1354628pwj.9 for <oauth@ietf.org>; Sat, 10 Jul 2010 20:09:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.207.9 with SMTP id e9mr428685wfg.56.1278817760480; Sat, 10 Jul 2010 20:09:20 -0700 (PDT)
Received: by 10.142.193.19 with HTTP; Sat, 10 Jul 2010 20:09:20 -0700 (PDT)
Date: Sat, 10 Jul 2010 20:09:20 -0700
Message-ID: <AANLkTinxhtT3hjM9w0aUHgq-kD5ioo217iV6gzX5p1NO@mail.gmail.com>
From: Brian Eaton <beaton@google.com>
To: oauth@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
X-System-Of-Record: true
Subject: [OAUTH-WG] client credentials returning a refresh token
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sun, 11 Jul 2010 03:09:16 -0000

Hey folks -

The client credentials flow should never return a refresh token, for
the following reasons:

- it's never necessary
- it's a security problem
- it's inefficient
- it's confusing

I'll go over each of those points in detail, but here are the changes
to the spec I'd like to see.

Page 8: diagram shows "with optional refresh token".  Delete that.
Somewhere in document: add a specific description of the client_id +
client_secret produces access_token equation.  (This seems to have
been dropped in draft 7... or am I missing something?)


Here are the detailed reasons why the refresh token in this flow is a bad idea.

1) it's never necessary

In order to use a refresh token to get a new access token, you need to
present a client-id and a client-secret.

If you have a client-id and client-secret, you can just use the client
credentials flow to get a new access token.

So keeping the refresh token around serves no purpose.

2) it's a security problem

Creating a refresh token is roughly equivalent to creating an
alternate password (client secret) for the client.  It's one more
secret that needs to be protected.

When a client using the client credentials flow is compromised, you
need to reset their client secret to recover.  But because this
profile is creating refresh tokens, you also need to go and revoke all
of the refresh tokens.

3) it's inefficient

Refresh tokens are long-lived secrets.  They need server-side storage.
 So every single time a client authenticates, you're going to have to
allocate long-lived storage associated with that authentication.

4) it's confusing

The spec offers no guidance as to when servers should return refresh
tokens, or what clients ought to do with them.

This is basically a trap.