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: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Torsten
Lodderstedt [tors...@lodderstedt.net]
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
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<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
