Subject: [OAUTH-WG] Removal: HTTP Basic Authentication for Client Credentials

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 14 Jan 2011 23:53:26 -0700

OAuth 2.0 provides two methods for client authentication using password credentials: request parameters and HTTP Basic authentication. I suggest we drop the requirement to support HTTP Basic authentication, and only mention it as an example for alternative methods. My reasons are:

1.       A few providers have expressed concerns over the need to support Basic authentication, and some explicitly said they will not support it. Parameter-based authentication, OTOH, is widely deployed in 2.0.

2.       Due to the way OAuth is being implemented at the HTTP authentication layer (even if it is wrong), can conflict within the framework as both a consumer and provider of authentication components.

3.       The mapping between username and client_id, while not complicated, is still a big awkward, and can be confusing when combined with the username and password grant type. On the other hand, the use of client_id in the end-user authorization endpoint lends itself nicely to the use of the same parameter elsewhere.

4.       Some existing authentication frameworks will have an issue handling the mix of Basic authentication and parameters authentication due to how each is deployed. In cases where a front gate handles Basic, it will be hard to let requests through for parameter processing.

Comments? Counter-arguments?

EHL

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 16 Jan 2011 19:54:33 +0100

Hi Eran,

you made some good points and I agree with most of your analysis. The 
way we use BASIC in the current draft is not perfect, mainly because it 
is a compromise. It was basically the attempt to be more HTTP compliant 
while still supporting the parameter-based approach.

I would strongly object against removing BASIC and relying on body 
parameters, only.  We (Deutsche Telekom) have implemented that scheme 
and do not see a real problem with it.

In order to overcome the problems you listed, I would like to propose an 
alternative approach.

I would suggest to drop support for passing any credentials to the 
tokens endpoint in the body of the POST request. Instead, I would 
suggest to define one HTTP authentication scheme per grant type and send 
the corresponding parameters within the Authorization header.

Conceptually, the tokens endpoint is a resource URI clients use to 
obtain tokens. The expected token scope can be explicitely specified by 
the corresponding URI query parameter. So the simplest, complete request 
to obtain a token could look as follows:

      POST /token HTTP/1.1
      Host: server.example.com
      Content-Type: application/x-www-form-urlencoded

      scope=something

Most authorization servers will certainly need credentials of some kind 
as pre-requisite for token issuance. These credentials actually 
authenticate the resource owner and the client to the authorization 
server as well as prove the client's authorization to get the token. 
Such credentials are usually passed using authorization headers in HTTP 
requests.

Let's take the example of the grant type "code". We could define a 
scheme "CODE", which carries the parameters code, redirect_uri, 
client_id and client_secret (optionally) as named values. An example 
request could look as follows

      POST /token HTTP/1.1
      Host: server.example.com
      Content-Type: application/x-www-form-urlencoded
      Authorization: CODE code='i1WsRn1uB1',
                          
redirect_uri='https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb',
                          client_id='s6BhdRkqt3',
                          client_secret='gX1fBat3bV'

      scope=something

The following examples illustrate the approach with respect to the grant 
types "password" and "refresh_token", respectively.

      POST /token HTTP/1.1
      Host: server.example.com
      Content-Type: application/x-www-form-urlencoded
      Authorization: PWD username='johndoe',
                         password='A3ddj3w',
                          client_id='s6BhdRkqt3',
                          client_secret='gX1fBat3bV'

      scope=something

      POST /token HTTP/1.1
      Host: server.example.com
      Content-Type: application/x-www-form-urlencoded
      Authorization: REFRESH token='n4E9O119d',
                             client_id='s6BhdRkqt3',
                             client_secret='gX1fBat3bV'

      scope=something

I see the following advantages:
1) The suggest approach is aligned with HTTP. So instead of using HTTP 
as "transport protocol" only (as in the dark times of SOAP), we could 
make better use of the existing framework for messaging, caching, and 
security.

2) Since the proposed approach is alligned with HTTP authentication and 
authorization in general, it would be an easy task to add support for 
additional, existing authentication mechanisms, such as Kerberos/SPNEGO, 
Digest or GBA to an OAuth authorization server.

3) WWW-Authenticate headers could be used to provide clients with useful 
information about the capabilities of the authorization server. In the 
following example, the server reacts to an unauthenticated request with 
the following response

      HTTP/1.1 401 Unauthorized
      WWW-Authenticate: CODE uri="tokenservice.example.com/authorize"
      WWW-Authenticate: PWD realm='users.example.com'
      WWW-Authenticate: REFRESH

which indicates its support for the grant types authorization_code, 
username/password and refresh token. Additionally it provides the client 
with the end-user endpoint URI of the authorization server and the user 
realm supported for password authentication.

4) The proposed mechanism should work nicely with existing 
authentication frameworks, since we would no longer use a mixed model 
for passing credentials and dedicated HTTP authentication schemes.

What do you think? What do others think?

regards,
Torsten.

Am 15.01.2011 07:53, schrieb Eran Hammer-Lahav:
>
> OAuth 2.0 provides two methods for client authentication using 
> password credentials: request parameters and HTTP Basic 
> authentication. I suggest we drop the requirement to support HTTP 
> Basic authentication, and only mention it as an example for 
> alternative methods. My reasons are:
>
> 1.A few providers have expressed concerns over the need to support 
> Basic authentication, and some explicitly said they will not support 
> it. Parameter-based authentication, OTOH, is widely deployed in 2.0.
>
> 2.Due to the way OAuth is being implemented at the HTTP authentication 
> layer (even if it is wrong), can conflict within the framework as both 
> a consumer and provider of authentication components.
>
> 3.The mapping between username and client_id, while not complicated, 
> is still a big awkward, and can be confusing when combined with the 
> username and password grant type. On the other hand, the use of 
> client_id in the end-user authorization endpoint lends itself nicely 
> to the use of the same parameter elsewhere.
>
> 4.Some existing authentication frameworks will have an issue handling 
> the mix of Basic authentication and parameters authentication due to 
> how each is deployed. In cases where a front gate handles Basic, it 
> will be hard to let requests through for parameter processing.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 17 Jan 2011 10:42:51 -0500

+1 to making BASIC optional. I don't think we were going to be supporting it
in general, either.

 -- Justin
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Eran Hammer-Lahav [[email-masked]]
Sent: Saturday, January 15, 2011 1:53 AM
To: OAuth WG
Subject: [OAUTH-WG] Removal: HTTP Basic Authentication for Client Credentials

EHL

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 17 Jan 2011 10:55:05 -0500

I absolutely don't want to drop credentials being passed as parameters. I think that's more widely deployed than using the BASIC style auth as well.

I do think that Torsten's approach below has a certain elegance to it, but it would require deeper access to queries that not all deployment frameworks allow (or at least, make easy to access). For part 3 below, it's usually the PR and not the AS that's returning the 401, so this would require the PR to know what kinds of things the AS will accept. Right now, the client needs to know that, which I think is more reasonable.

 -- Justin
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Torsten Lodderstedt [[email-masked]]
Sent: Sunday, January 16, 2011 1:54 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Removal: credential body parameters

Hi Eran,

you made some good points and I agree with most of your analysis. The way we use BASIC in the current draft is not perfect, mainly because it is a compromise. It was basically the attempt to be more HTTP compliant while still supporting the parameter-based approach.

I would strongly object against removing BASIC and relying on body parameters, only.  We (Deutsche Telekom) have implemented that scheme and do not see a real problem with it.

In order to overcome the problems you listed, I would like to propose an alternative approach.

I would suggest to drop support for passing any credentials to the tokens endpoint in the body of the POST request. Instead, I would suggest to define one HTTP authentication scheme per grant type and send the corresponding parameters within the Authorization header.

Conceptually, the tokens endpoint is a resource URI clients use to obtain tokens. The expected token scope can be explicitely specified by the corresponding URI query parameter. So the simplest, complete request to obtain a token could look as follows:

     POST /token HTTP/1.1
     Host: server.example.com

     scope=something

Most authorization servers will certainly need credentials of some kind as pre-requisite for token issuance. These credentials actually authenticate the resource owner and the client to the authorization server as well as prove the client's authorization to get the token. Such credentials are usually passed using authorization headers in HTTP requests.

Let's take the example of the grant type "code". We could define a scheme "CODE", which carries the parameters code, redirect_uri, client_id and client_secret (optionally) as named values. An example request could look as follows

     POST /token HTTP/1.1
     Host: server.example.com

     scope=something

The following examples illustrate the approach with respect to the grant types "password" and "refresh_token", respectively.

     POST /token HTTP/1.1
     Host: server.example.com

     scope=something

     POST /token HTTP/1.1
     Host: server.example.com

     scope=something

I see the following advantages:
1) The suggest approach is aligned with HTTP. So instead of using HTTP as "transport protocol" only (as in the dark times of SOAP), we could make better use of the existing framework for messaging, caching, and security.

2) Since the proposed approach is alligned with HTTP authentication and authorization in general, it would be an easy task to add support for additional, existing authentication mechanisms, such as Kerberos/SPNEGO, Digest or GBA to an OAuth authorization server.

3) WWW-Authenticate headers could be used to provide clients with useful information about the capabilities of the authorization server. In the following example, the server reacts to an unauthenticated request with the following response

which indicates its support for the grant types authorization_code, username/password and refresh token. Additionally it provides the client with the end-user endpoint URI of the authorization server and the user realm supported for password authentication.

4) The proposed mechanism should work nicely with existing authentication frameworks, since we would no longer use a mixed model for passing credentials and dedicated HTTP authentication schemes.

regards,
Torsten.

EHL

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 18 Jan 2011 17:28:05 +0000

Concern here is that HTTP Basic Auth provides a straightforward interop profile for the web server profile

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richer, Justin P.
Sent: Monday, January 17, 2011 7:43 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] Removal: HTTP Basic Authentication for Client Credentials

 -- Justin

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 18 Jan 2011 10:49:57 -0700

So does requiring the parameter-based approach which has identical security properties. We need to require at least one, and we already know some will not deploy Basic.

EHL

> From: Anthony Nadalin [mailto:[email-masked]]
> Sent: Tuesday, January 18, 2011 9:28 AM
> To: Richer, Justin P.; Eran Hammer-Lahav; OAuth WG
> Subject: RE: [OAUTH-WG] Removal: HTTP Basic Authentication for Client
> Credentials
> 
> OAuth 2.0 provides two methods for client authentication using password
> credentials: request parameters and HTTP Basic authentication. I suggest we
> drop the requirement to support HTTP Basic authentication, and only
> mention it as an example for alternative methods. My reasons are:
> 
> 
> 1.       A few providers have expressed concerns over the need to support
> Basic authentication, and some explicitly said they will not support it.
> Parameter-based authentication, OTOH, is widely deployed in 2.0.
> 
> 2.       Due to the way OAuth is being implemented at the HTTP authentication
> layer (even if it is wrong), can conflict within the framework as both a
> consumer and provider of authentication components.
> 
> 3.       The mapping between username and client_id, while not complicated,
> username and password grant type. On the other hand, the use of client_id
> in the end-user authorization endpoint lends itself nicely to the use of the
> same parameter elsewhere.
> 
> 4.       Some existing authentication frameworks will have an issue handling
> the mix of Basic authentication and parameters authentication due to how
> each is deployed. In cases where a front gate handles Basic, it will be hard to
> let requests through for parameter processing.
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 18 Jan 2011 20:58:23 +0100

Justin,

WRT 401 - just think of the AS as a RS for tokens.

An (ordinary) RS would probably return 401 with WWW-Autenticate MAC/BEARER/OAUTH2 carrying the ASs tokens endpoint URI. Or the client knows the AS URI at development time (more likely these days).

The client now makes an unauthorized request to this URI and the AS responds with another 401 and a set of WWW-Authenticate headers as shown in my posting.

regards,
Torsten.

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 18 Jan 2011 22:54:30 +0000

If it is left as optional (not removed) then I'm OK to go with parameter-based approach as default

-----Original Message-----
From: Eran Hammer-Lahav [mailto:[email-masked]] 
Sent: Tuesday, January 18, 2011 9:50 AM
To: Anthony Nadalin; Richer, Justin P.; OAuth WG
Subject: RE: [OAUTH-WG] Removal: HTTP Basic Authentication for Client Credentials

EHL

> Concern here is that HTTP Basic Auth provides a straightforward 
> interop profile for the web server profile
> 
> +1 to making BASIC optional. I don't think we were going to be 
> +supporting it
> in general, either.
> 
>  -- Justin
> password
> credentials: request parameters and HTTP Basic authentication. I 
> suggest we drop the requirement to support HTTP Basic authentication, 
> and only mention it as an example for alternative methods. My reasons are:
> 
>

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 18 Jan 2011 18:21:09 -0500

+1

Igor

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 18 Jan 2011 16:53:40 -0800

+1

I think it is way too late for drastic changes like this. As shown by
existing implementations, pretty much everyone cares only about
credentials sent as parameters.

Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 18 Jan 2011 16:56:47 -0800

+1

I think basic auth for client credentials belongs to an extension,
that simplifies the core spec. Is there a good reason to keep an
optional feature in core?

Marius

On Tue, Jan 18, 2011 at 3:21 PM, Igor Faynberg
<[email-masked]> wrote:
>> From: Eran Hammer-Lahav [mailto:[email-masked]] Sent: Tuesday,
>> January 18, 2011 9:50 AM
>> So does requiring the parameter-based approach which has identical
>> security properties. We need to require at least one, and we already know
>> some will not deploy Basic.
>>
>> EHL
>>
>>
>>>
>>> credentials: request parameters and HTTP Basic authentication. I suggest
>>> we drop the requirement to support HTTP Basic authentication, and only
>>> username and password grant type. On the other hand, the use of client_id in
>>> the end-user authorization endpoint lends itself nicely to the use of the
>>> each is deployed. In cases where a front gate handles Basic, it will be hard
>>> to let requests through for parameter processing.
>>>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 18 Jan 2011 23:20:09 -0700

This seems to conflict with the ability to mix and match grant types and client authentication. If you define an authentication scheme for each grant type, how would you also include client authentication using, say, Basic or Digest? Seems like a complex framework for combining schemes into one header.

EHL

From: Torsten Lodderstedt [mailto:[email-masked]]
Sent: Sunday, January 16, 2011 10:55 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Removal: credential body parameters

Hi Eran,

     POST /token HTTP/1.1
     Host: server.example.com

     scope=something

     POST /token HTTP/1.1
     Host: server.example.com

     scope=something

     POST /token HTTP/1.1
     Host: server.example.com

     scope=something

     POST /token HTTP/1.1
     Host: server.example.com

     scope=something

regards,
Torsten.

A few providers have expressed concerns over the need to support Basic authentication, and some explicitly said they will not support it. Parameter-based authentication, OTOH, is widely deployed in 2.0.

Due to the way OAuth is being implemented at the HTTP authentication layer (even if it is wrong), can conflict within the framework as both a consumer and provider of authentication components.

The mapping between username and client_id, while not complicated, is still a big awkward, and can be confusing when combined with the username and password grant type. On the other hand, the use of client_id in the end-user authorization endpoint lends itself nicely to the use of the same parameter elsewhere.

Some existing authentication frameworks will have an issue handling the mix of Basic authentication and parameters authentication due to how each is deployed. In cases where a front gate handles Basic, it will be hard to let requests through for parameter processing.

EHL

OAuth mailing list

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 19 Jan 2011 07:35:51 +0100

Where do you see the conflict? In my proposal, user and client 
credentials are combined into one Authorization header. But the same 
holds for request parameters. I don't know whether combining credentials 
in request parameters is more or less complex/conflicting then combining 
them as named values within a header.

regards,
Torsten.

Am 19.01.2011 07:20, schrieb Eran Hammer-Lahav:
>
> This seems to conflict with the ability to mix and match grant types 
> and client authentication. If you define an authentication scheme for 
> each grant type, how would you also include client authentication 
> using, say, Basic or Digest? Seems like a complex framework for 
> combining schemes into one header.
>
> EHL
>
> *From:*Torsten Lodderstedt [mailto:[email-masked]]
> *Sent:* Sunday, January 16, 2011 10:55 AM
> *To:* Eran Hammer-Lahav
> *Cc:* OAuth WG
> *Subject:* Re: [OAUTH-WG] Removal: credential body parameters
>
> Hi Eran,
>
> way we use BASIC in the current draft is not perfect, mainly because 
> it is a compromise. It was basically the attempt to be more HTTP 
> compliant while still supporting the parameter-based approach.
>
> suggest to define one HTTP authentication scheme per grant type and 
> send the corresponding parameters within the Authorization header.
>
> obtain tokens. The expected token scope can be explicitely specified 
> by the corresponding URI query parameter. So the simplest, complete 
> request to obtain a token could look as follows:
>
>      POST /token HTTP/1.1
>      Host: server.example.com
> Most authorization servers will certainly need credentials of some 
> kind as pre-requisite for token issuance. These credentials actually 
> Such credentials are usually passed using authorization headers in 
> HTTP requests.
>
> The following examples illustrate the approach with respect to the 
> grant types "password" and "refresh_token", respectively.
>
>      POST /token HTTP/1.1
>      Host: server.example.com
> 2) Since the proposed approach is alligned with HTTP authentication 
> and authorization in general, it would be an easy task to add support 
> for additional, existing authentication mechanisms, such as 
> Kerberos/SPNEGO, Digest or GBA to an OAuth authorization server.
>
> 3) WWW-Authenticate headers could be used to provide clients with 
> useful information about the capabilities of the authorization server. 
> In the following example, the server reacts to an unauthenticated 
> request with the following response
>
> username/password and refresh token. Additionally it provides the 
> client with the end-user endpoint URI of the authorization server and 
> the user realm supported for password authentication.
>
> A few providers have expressed concerns over the need to support Basic 
> authentication, and some explicitly said they will not support it. 
> Due to the way OAuth is being implemented at the HTTP authentication 
> The mapping between username and client_id, while not complicated, is 
> still a big awkward, and can be confusing when combined with the 
> Some existing authentication frameworks will have an issue handling 
> [email-masked]  <mailto:[email-masked]>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 18 Jan 2011 23:37:19 -0700

If I want to use an existing client authentication scheme such as Digest, your solution creates a conflict, unless we define a way to combine grant + Digest into one header.

EHL

From: Torsten Lodderstedt [mailto:[email-masked]]
Sent: Tuesday, January 18, 2011 10:36 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Removal: credential body parameters

Where do you see the conflict? In my proposal, user and client credentials are combined into one Authorization header. But the same holds for request parameters. I don't know whether combining credentials in request parameters is more or less complex/conflicting then combining them as named values within a header.

regards,
Torsten.

EHL

Hi Eran,

     POST /token HTTP/1.1
     Host: server.example.com

     scope=something

     POST /token HTTP/1.1
     Host: server.example.com

     scope=something

     POST /token HTTP/1.1
     Host: server.example.com

     scope=something

     POST /token HTTP/1.1
     Host: server.example.com

     scope=something

regards,
Torsten.

EHL

OAuth mailing list

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 19 Jan 2011 07:44:14 +0100

That's true, but combining existing schemes with user credentials sent 
in the request body creates other problems (as you already stated). And 
most existing schemes are used for user authentication these days.

It would be interesting to see, how many client authentication 
mechanisms exists that poeple want to use with OAuth in the context of a 
combined user/client authentication.

Authentication of autonomous clients is like user authentication in my 
opinion, so no combination is required there.

regards,
Torsten.

Am 19.01.2011 07:37, schrieb Eran Hammer-Lahav:
>
> If I want to use an existing client authentication scheme such as 
> Digest, your solution creates a conflict, unless we define a way to 
> combine grant + Digest into one header.
>
> EHL
>
> *Sent:* Tuesday, January 18, 2011 10:36 PM
> *To:* Eran Hammer-Lahav
> *Cc:* OAuth WG
> holds for request parameters. I don't know whether combining 
> credentials in request parameters is more or less complex/conflicting 
> then combining them as named values within a header.
>
> regards,
> Torsten.
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 19 Jan 2011 00:15:24 -0700

The requirement to support client credentials in the body is implicit, which means providers can choose not to use it if they rather use a different method of client authentication.

EHL

From: Torsten Lodderstedt [mailto:[email-masked]]
Sent: Tuesday, January 18, 2011 10:44 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Removal: credential body parameters

That's true, but combining existing schemes with user credentials sent in the request body creates other problems (as you already stated). And most existing schemes are used for user authentication these days.

It would be interesting to see, how many client authentication mechanisms exists that poeple want to use with OAuth in the context of a combined user/client authentication.

Authentication of autonomous clients is like user authentication in my opinion, so no combination is required there.

regards,
Torsten.

EHL

regards,
Torsten.

EHL

Hi Eran,

     POST /token HTTP/1.1
     Host: server.example.com

     scope=something

     POST /token HTTP/1.1
     Host: server.example.com

     scope=something

     POST /token HTTP/1.1
     Host: server.example.com

     scope=something

     POST /token HTTP/1.1
     Host: server.example.com

     scope=something

regards,
Torsten.

EHL

OAuth mailing list