[OAUTH-WG] Issue: Split the authorization endpoint into two endpoints
Eran Hammer-Lahav <eran@hueniverse.com> Thu, 15 April 2010 18:41 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 B03343A68C5 for <oauth@core3.amsl.com>; Thu, 15 Apr 2010 11:41:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.432
X-Spam-Level:
X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599]
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 356z+1eJv9qC for <oauth@core3.amsl.com>; Thu, 15 Apr 2010 11:41:40 -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 B844F3A67FF for <oauth@ietf.org>; Thu, 15 Apr 2010 11:41:40 -0700 (PDT)
Received: (qmail 27735 invoked from network); 15 Apr 2010 18:41:34 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Apr 2010 18:41:34 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 15 Apr 2010 11:41:22 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: OAuth WG <oauth@ietf.org>
Date: Thu, 15 Apr 2010 11:41:20 -0700
Thread-Topic: Issue: Split the authorization endpoint into two endpoints
Thread-Index: Acrcyz1lDoVqvOFmQEa2c5Oxsc3UxA==
Message-ID: <C7ECABE0.32344%eran@hueniverse.com>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [OAUTH-WG] Issue: Split the authorization endpoint into two endpoints
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: Thu, 15 Apr 2010 18:41:42 -0000
OAuth 2.0 defines a single authorization endpoint with a 'type' parameter for the various flows and flow steps. There are two types of calls made to the authorization endpoint: - Requests for Access - requests in which an end user interacts with the authorization server, granting client access. - Requests for Token - requests in which the client uses a verification code or other credentials to obtain an access token. These requests require SSL/TLS because they always result in the transmission of plaintext credentials in the response and sometimes in the request. A proposal has been made to define two separate endpoints due to the different nature of these endpoints: On 4/6/10 4:06 PM, "Marius Scurtescu" <mscurtescu@google.com> wrote: > Constraints for endpoints: > access token URL: HTTPS and POST only, no user > user authentication URL: HTTP or HTTPS, GET or POST, authenticated user > > In many cases the above constraints can be enforced with configuration > that sits in front of the controllers implementing these endpoints. > For example, Apache config can enforce SSL and POST. Same can be done > in a Java filter. Also a Java filter can enforce that only > authenticated users hit the endpoint, it can redirect to a login page > if needed. > > By keeping two different endpoints all of the above is much simpler. > Nothing prevents an authz server to collapse these two into one > endpoint. While requests for access do not require HTTPS, they should because they involve authenticating the end user. As for enforcing HTTP methods (GET, POST), this is simple to do both at the server configuration level or application level. On the other hand, having a single endpoint makes the specification simpler, and more importantly, makes discovery trivial as a 401 response needs to include a single endpoint for obtaining a token regardless of the flow (some flows use one, others two steps). A richer discovery later can use LRDD on the single authorization endpoint to obtain an XRD describing the flows and UI options provided by the server. But this is outside our scope. Proposal: No change. Keep the single authorization endpoint and require HTTPS for all requests. EHL
- [OAUTH-WG] Issue: Split the authorization endpoin… Eran Hammer-Lahav
- Re: [OAUTH-WG] Issue: Split the authorization end… David Recordon
- Re: [OAUTH-WG] Issue: Split the authorization end… Manger, James H
- Re: [OAUTH-WG] Issue: Split the authorization end… John Kemp
- Re: [OAUTH-WG] Issue: Split the authorization end… Justin Richer
- Re: [OAUTH-WG] Issue: Split the authorization end… Luke Shepard
- Re: [OAUTH-WG] Issue: Split the authorization end… Evan Gilbert
- Re: [OAUTH-WG] Issue: Split the authorization end… David Recordon
- Re: [OAUTH-WG] Issue: Split the authorization end… Eran Hammer-Lahav
- Re: [OAUTH-WG] Issue: Split the authorization end… Marius Scurtescu
- Re: [OAUTH-WG] Issue: Split the authorization end… Manger, James H
- Re: [OAUTH-WG] Issue: Split the authorization end… Eran Hammer-Lahav
- Re: [OAUTH-WG] Issue: Split the authorization end… Manger, James H
- Re: [OAUTH-WG] Issue: Split the authorization end… Torsten Lodderstedt
- Re: [OAUTH-WG] Issue: Split the authorization end… Torsten Lodderstedt
- Re: [OAUTH-WG] Issue: Split the authorization end… Eran Hammer-Lahav
- Re: [OAUTH-WG] Issue: Split the authorization end… Manger, James H
- Re: [OAUTH-WG] Issue: Split the authorization end… Torsten Lodderstedt
- Re: [OAUTH-WG] Issue: Split the authorization end… Luke Shepard
- Re: [OAUTH-WG] Issue: Split the authorization end… Torsten Lodderstedt