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:tors...@lodderstedt.net]
*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,
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:
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.
Comments? Counter-arguments?
EHL
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
