Re: [OAUTH-WG] client credentials returning a refresh token
Eran Hammer-Lahav <eran@hueniverse.com> Sun, 11 July 2010 03:13 UTC
Return-Path: <eran@hueniverse.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 DCD2E3A68DC for <oauth@core3.amsl.com>; Sat, 10 Jul 2010 20:13:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.283
X-Spam-Level:
X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 fhJPnSZTtlgu for <oauth@core3.amsl.com>; Sat, 10 Jul 2010 20:13:49 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 85B893A68D9 for <oauth@ietf.org>; Sat, 10 Jul 2010 20:13:49 -0700 (PDT)
Received: (qmail 18512 invoked from network); 11 Jul 2010 03:13:55 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Jul 2010 03:13:55 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sat, 10 Jul 2010 20:13:55 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Brian Eaton <beaton@google.com>, OAuth WG <oauth@ietf.org>
Date: Sat, 10 Jul 2010 20:13:52 -0700
Thread-Topic: [OAUTH-WG] client credentials returning a refresh token
Thread-Index: AcsgpnhqmBmwvBa8R+GFgzOa90//9wAAJ4jN
Message-ID: <C85E8500.36FA9%eran@hueniverse.com>
In-Reply-To: <AANLkTinxhtT3hjM9w0aUHgq-kD5ioo217iV6gzX5p1NO@mail.gmail.com>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C85E850036FA9eranhueniversecom_"
MIME-Version: 1.0
Subject: Re: [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:13:51 -0000
How about write some new text about what refresh tokens are for and when they should be issued. I think this can benefit from its own section. The rest is mostly editorial. EHL On 7/10/10 8:09 PM, "Brian Eaton" <beaton@google.com> wrote: 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. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] client credentials returning a refresh… Brian Eaton
- Re: [OAUTH-WG] client credentials returning a ref… Eran Hammer-Lahav
- Re: [OAUTH-WG] client credentials returning a ref… Eran Hammer-Lahav