Subject: [OAUTH-WG] Issue: Split the authorization endpoint into two endpoints

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 15 Apr 2010 11:41:20 -0700

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" <[email-masked]> 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

---

From: David Recordon <[email-masked]>
Date: Thu, 15 Apr 2010 11:47:52 -0700

Strongly for keeping one endpoint given that the spec uses type
extensively. A huge motivator in the 2.0 effort is simplicity for
client developers.

On Thu, Apr 15, 2010 at 11:41 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 16 Apr 2010 11:22:13 +1000

I strongly favour specifying 2 separate endpoints: one for where to redirect a user, another for direct client calls.

I agree with Marius that these two endpoints are different enough to be separate.
One is only used by users via browsers. The other is only used by client apps. These are different populations, using different authentication mechanisms, with different performance requirements, and different technologies.

The use of a type parameter is a poor tool to distinguishes these cases.

I guess 1 URI could default to the other if not defined.
1 URI could be allowed to be relative to the other to save some bytes.

-- 
James Manger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Friday, 16 April 2010 4:41 AM
To: OAuth WG
Subject: [OAUTH-WG] Issue: Split the authorization endpoint into two endpoints

EHL

---

From: John Kemp <[email-masked]>
Date: Thu, 15 Apr 2010 22:11:27 -0400

> I strongly favour specifying 2 separate endpoints: one for where to redirect a user, another for direct client calls.

I agree.

> 1 URI could be allowed to be relative to the other to save some bytes.

I agree with this reasoning too. 

- johnk

---

From: Justin Richer <[email-masked]>
Date: Fri, 16 Apr 2010 10:01:41 -0400

I favor this approach as well. It feels cleaner to me to have a
separation of purposes here. The two endpoints could always be collapsed
in a particular implementation -- I've seen several OAuth 1.0
implementations that do just this, using a URL parameter to
differentiate between the request, access, and authorization endpoints. 

Having them available separately makes it easier to have different
authentication mechanisms to the endpoints themselves, as well. The
authorization endpoint is (generally) user-credential protected, but the
token endpoint will be authenticated differently depending on which
flows are supported. However, I will say that in most webapp systems,
you can always have the OAuth endpoint forward internally to another
endpoint if user authentication is necessary, so this argument may not
hold up in practical deployment.

Downside is that it does make discovery a little trickier, but discovery
is admittedly outside the scope of this protocol.

 -- justin

---

From: Luke Shepard <[email-masked]>
Date: Fri, 16 Apr 2010 09:58:02 -0700

>> user authentication URL: HTTP or HTTPS, GET or POST, authenticated user

In either case, we should not restrict the access token URL to POST-only. A GET request is just as secure and can be much easier to write code for (just construct the URL and ping, no need to figure out CURLOPT_POSTFIELDS).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Kemp
Sent: Thursday, April 15, 2010 7:11 PM
To: Manger, James H
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Issue: Split the authorization endpoint into two endpoints

I agree.

- johnk

---

From: Evan Gilbert <[email-masked]>
Date: Fri, 16 Apr 2010 11:57:23 -0700

On Fri, Apr 16, 2010 at 7:01 AM, Justin Richer <[email-masked]> wrote:

> flows are supported.

Any flow where the user interacts on a domain that will have the user
credentials (cookies, etc). This is often a different URL path or even
domain from endpoints where a user credential isn't required.

Think I'd lean towards two URLs - the downside is that it makes discovery /
configuration a little bit harder.

> However, I will say that in most webapp systems,
> > I strongly favour specifying 2 separate endpoints: one for where to
> redirect a user, another for direct client calls.
> >
> > One is only used by users via browsers. The other is only used by client
> apps. These are different populations, using different authentication
> mechanisms, with different performance requirements, and different
> technologies.
> >

---

From: David Recordon <[email-masked]>
Date: Fri, 16 Apr 2010 12:14:04 -0700

Talked with Luke and now remember earlier conversations about two
URLs. We'll likely do www.facebook.com for user interactions and
api.facebook.com for server stuff.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 16 Apr 2010 13:51:00 -0700

I'll split them to: Authorization endpoint and Toke endpoint. In the WWW-Authenticate header I'll add a parameter for each (instead of one) for lightweight discovery (which we can keep, change, or drop later).

EHL

On 4/15/10 6:22 PM, "James Manger" <[email-masked]> wrote:

--
James Manger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Friday, 16 April 2010 4:41 AM
To: OAuth WG
Subject: [OAUTH-WG] Issue: Split the authorization endpoint into two endpoints

EHL

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 16 Apr 2010 14:14:13 -0700

> In either case, we should not restrict the access token URL to POST-only. A GET request is just as secure and can be much easier to write code for (just construct the URL and ping, no need to figur…

If you are using GET, then refresh tokens and client secrets will end
up side by side in web server log files.

Marius

---

From: "Manger, James H" <[email-masked]>
Date: Sat, 17 Apr 2010 12:02:45 +1000

>> In either case, we should not restrict the access token URL to POST-only.
>> A GET request is just as secure and can be much easier to write code for

> up side by side in web server log files.

These are exactly the sort of reasons why client authentication should be any "normal" auth scheme, and not an OAuth-special client_secret POST parameter. That fails for PUT, DELETE, and POST with a non-form body; and the security changes with GET.

--
James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 16 Apr 2010 19:57:44 -0700

This has nothing to do with it. There is no PUT and DELETE or POST with non-form body when *requesting a token*.

We need to do a better job not to confuse accessing protected resources with the flow calls. They are completely different.

EHL

--
James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Sat, 17 Apr 2010 14:52:28 +1000

> This has nothing to do with it. There is no PUT and DELETE or POST with non-form body when *requesting a token*.

It is relevant.

I don’t want to authenticate direct client requests *only* when they *request a token*.

Clients might make any variety of direct requests unrelated to OAuth.

There might even be other OAuth-related requests from clients to an authorization server in future (eg get meta data, or delete a token; even refreshing a token might be better as a GET).

I want to be able to use the same client auth mechanism, and same client credentials, for all these calls.

Some of these calls might be PUTs, DELETEs, non-form POSTs, GETs etc. even if requesting (& refreshing) a token is always a form POST.

Hence client_secret as a POST parameter when requesting a token is a poor design.

It should be perfectly valid (and not uncommon I expect) for a service to support OAuth for user delegation, but not use OAuth for making all direct client calls token-based — these address quite different issues.

Other services might use short-term refreshable tokens when clients (on their own behalf) access less trusted “content” service, but will use “normal” auth when clients talk to the trusted account/authorization system.

--

James Manger

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Saturday, 17 April 2010 12:58 PM
To: Manger, James H; Luke Shepard; John Kemp
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Issue: Split the authorization endpoint into two endpoints

EHL

--
James Manger

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 17 Apr 2010 10:10:28 +0200

I support the idea to use standard HTTP auth mechanisms for 
authentication on the authorization server endpoint. From a design 
standpoint this is just an API - which we cannot to protect via OAuth 
tokens because it issues these tokens. But we can use HTTP standard 
authorization mechanisms (and headers) as BASIC or DIGEST to 
authenticate the callers. This gives implementations the option to use 
other mechanisms (like SPNEGO or CERT). And as James pointed out, there 
might (will in our case) other requests on this endpoint used to provide 
additional services via other HTTP methods, e.g. DELETE. Moreover, 
standard authn modules (as in HTTPClient) can directly be used to 
implement access to OAuth authorization servers.

I would recommend to separate functional API parameters, like callback 
url, and authorization data.

regards,
Torsten.

Am 17.04.2010 06:52, schrieb Manger, James H:
>
> > This has nothing to do with it. There is no PUT and DELETE or POST 
> with non-form body when *requesting a token**.
>
> *
>
> It is relevant.
>
> I don’t want to authenticate direct client requests **only** when they 
> **request a token**.
>
> There might even be other OAuth-related requests from clients to an 
> authorization server in future (eg get meta data, or delete a token; 
> even refreshing a token might be better as a GET).
>
> Some of these calls might be PUTs, DELETEs, non-form POSTs, GETs etc. 
> even if requesting (& refreshing) a token is always a form POST.
>
> It should be perfectly valid (and not uncommon I expect) for a service 
> to support OAuth for user delegation, but not use OAuth for making all 
> direct client calls token-based — these address quite different issues.
>
> Other services might use short-term refreshable tokens when clients 
> (on their own behalf) access less trusted “content” service, but will 
> use “normal” auth when clients talk to the trusted 
> account/authorization system.
>
> -- 
>
> James Manger
>
> *From:* Eran Hammer-Lahav [mailto:[email-masked]]
> *Sent:* Saturday, 17 April 2010 12:58 PM
> *To:* Manger, James H; Luke Shepard; John Kemp
> *Cc:* OAuth WG
> *Subject:* Re: [OAUTH-WG] Issue: Split the authorization endpoint into 
> two endpoints
>
> This has nothing to do with it. There is no PUT and DELETE or POST 
> with non-form body when *requesting a token**.
>
> *We need to do a better job not to confuse accessing protected 
> resources with the flow calls. They are completely different.
>
> EHL
>
>
> These are exactly the sort of reasons why client authentication should 
> be any "normal" auth scheme, and not an OAuth-special client_secret 
> POST parameter. That fails for PUT, DELETE, and POST with a non-form 
> body; and the security changes with GET.
>
> --
> James Manger
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 17 Apr 2010 10:21:50 +0200

sounds good.

One question arose: OpenId has the same design challenge. There are 
direct calls, like "associate", as well as indirect calls, like 
"checkid_setup". OpenId uses a single endpoint on the OP and 
differentiate the request types via the openid.mode parameter.

Does anyone know why OpenId want that way?

Am 16.04.2010 22:51, schrieb Eran Hammer-Lahav:
> I'll split them to: Authorization endpoint and Toke endpoint. In the 
> WWW-Authenticate header I'll add a parameter for each (instead of one) 
> for lightweight discovery (which we can keep, change, or drop later).
>
> EHL
>
>
>     I strongly favour specifying 2 separate endpoints: one for where
>     to redirect a user, another for direct client calls.
>
>     One is only used by users via browsers. The other is only used by
>     client apps. These are different populations, using different
>     authentication mechanisms, with different performance
>     requirements, and different technologies.
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 17 Apr 2010 04:42:57 -0700

How would use differentiate between the username and password profile and the client credentials profile, if you are using Basic or Digest?

EHL

On 4/17/10 1:10 AM, "Torsten Lodderstedt" <[email-masked]> wrote:

I support the idea to use standard HTTP auth mechanisms for authentication on the authorization server endpoint. From a design standpoint this is just an API - which we cannot to protect via OAuth tokens because it issues these tokens. But we can use HTTP standard authorization mechanisms (and headers) as BASIC or DIGEST to authenticate the callers. This gives implementations the option to use other mechanisms (like SPNEGO or CERT). And as James pointed out, there might (will in our case) other requests on this endpoint used to provide additional services via other HTTP methods, e.g. DELETE. Moreover, standard authn modules (as in HTTPClient) can directly be used to implement access to OAuth authorization servers.

I would recommend to separate functional API parameters, like callback url, and authorization data.

regards,
Torsten.

Am 17.04.2010 06:52, schrieb Manger, James H:
  Re: [OAUTH-WG] Issue: Split the authorization endpoint into two endpoints

It is relevant.

I don't want to authenticate direct client requests *only* when they *request a token*.

It should be perfectly valid (and not uncommon I expect) for a service to support OAuth for user delegation, but not use OAuth for making all direct client calls token-based - these address quite different issues.

Other services might use short-term refreshable tokens when clients (on their own behalf) access less trusted "content" service, but will use "normal" auth when clients talk to the trusted account/authorization system.

---

From: "Manger, James H" <[email-masked]>
Date: Sat, 17 Apr 2010 22:04:57 +1000

> How would use differentiate between the username and password profile and the client credentials profile, if you are using Basic or Digest?

Removing the client_secret from both flows still leaves one flow with ‘username’ and ‘password’ POST parameters (of the user, not client), which indicates whether a token acting for the user or client is desired.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 17 Apr 2010 14:47:09 +0200

good question!

I see two strategies:

a) HTTP Authn Schemes are used for client authn only, this would require 
to pass user credentials as API parameters in  "Username and Password Flow"
b) like (a) except user credentials for "Username and Password Flow" are 
passed in as Authorization Header. The Benefit: applications currently 
using BASIC/DIGEST authentication can easily migrate since authn does 
not have to be changed. I see the "Username and Password Flow" primarily 
as a migration flow (as stated in 3.6.1). So an exception would be 
legitimated from my point of view. Moreover the spec could explictly 
recommend to move implementation to other flows, like web or device.

regards,
Torsten.

Am 17.04.2010 13:42, schrieb Eran Hammer-Lahav:
> How would use differentiate between the username and password profile 
> and the client credentials profile, if you are using Basic or Digest?
>
> EHL
>
>
>     standpoint this is just an API - which we cannot to protect via
>     OAuth tokens because it issues these tokens. But we can use HTTP
>     standard authorization mechanisms (and headers) as BASIC or DIGEST
>     to authenticate the callers. This gives implementations the option
>     to use other mechanisms (like SPNEGO or CERT). And as James
>     pointed out, there might (will in our case) other requests on this
>     endpoint used to provide additional services via other HTTP
>     methods, e.g. DELETE. Moreover, standard authn modules (as in
>     HTTPClient) can directly be used to implement access to OAuth
>     authorization servers.
>
>         > This has nothing to do with it. There is no PUT and DELETE or
>         POST with non-form body when *requesting a token**.
>
>
>         *
>         It is relevant.
>
>         I don't want to authenticate direct client requests **only**
>         when they **request a token**.
>
>         There might even be other OAuth-related requests from clients
>         to an authorization server in future (eg get meta data, or
>         delete a token; even refreshing a token might be better as a GET).
>
>         I want to be able to use the same client auth mechanism, and
>         same client credentials, for all these calls.
>
>         Some of these calls might be PUTs, DELETEs, non-form POSTs,
>         GETs etc. even if requesting (& refreshing) a token is always
>         a form POST.
>
>         It should be perfectly valid (and not uncommon I expect) for a
>         service to support OAuth for user delegation, but not use
>         OAuth for making all direct client calls token-based --- these
>         address quite different issues.
>
>         Other services might use short-term refreshable tokens when
>         clients (on their own behalf) access less trusted "content"
>         service, but will use "normal" auth when clients talk to the
>         trusted account/authorization system.
>
>
>
>

---

From: Luke Shepard <[email-masked]>
Date: Sat, 17 Apr 2010 07:32:05 -0700

If, for your service, you want to use different means of authenticating clients, I see no reason why you can’t. Just ignore client_secret and do it your own way (it’s optional).

From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Friday, April 16, 2010 9:52 PM
To: Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] Issue: Split the authorization endpoint into two endpoints

It is relevant.

--
James Manger

EHL

--
James Manger

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 18 Apr 2010 15:25:11 +0200

from my point of view, the discussion is not necessarily about other 
means (== authn mechn). Shared secrets are acceptable for most cases. 
The discussion is about how client credentials are passed to the 
authorization server API (direct calls only). The proposal is to do it 
the HTTP authentication way. The spec recommends to use Oauth 
Authorization headers for securing service/API access via HTTP instead 
of API parameters. From my point of view, it is a matter of consistency 
to apply the same pattern (credentials in Authorization headers) to the 
OAuth authorization server API as well.

 From my point of view, the value of having the client_secret parameter 
is an interoperability baseline. Every library knowns how to perform 
client authn for OAuth. That's important!. You can achieve the same goal 
using a BASIC Authorization header + a lot of other advantages, which 
have already been pointed out in this thread.

Additionally, WWW-Authentication headers could be used by the 
authorization server to signal the need for client authentication. In 
the current spec, I don't see a way to find out when client authn is 
required and when not.

regards,
Torsten.

Am 17.04.2010 16:32, schrieb Luke Shepard:
>
> If, for your service, you want to use different means of 
> authenticating clients, I see no reason why you can’t. Just ignore 
> client_secret and do it your own way (it’s optional).
>
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Manger, James H
> *Sent:* Friday, April 16, 2010 9:52 PM
> *To:* Eran Hammer-Lahav; OAuth WG
> with non-form body when *requesting a token**.*
>
> It is relevant.
>