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