> -----Original Message----- > From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] > Sent: Tuesday, January 25, 2011 12:23 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: RE: RE: [OAUTH-WG] How to integrated DIGEST or SPNEGO with > tokensendpoint? > > Zitat von Eran Hammer-Lahav <e...@hueniverse.com>: > > > There is no clean way to do with without defining new HTTP > > authentication schemes. The token endpoints takes: > > > > 1. Client authentication > > 2. Authorization grant > > > > There is no user authentication. Even the resource owner password > > credentials is not user authentication but only validation of "some > > grant values". > > What's the difference from a conceptual point of view? In my opinion, the > resource owners password is used for both, authenticating the resource > owner and authorizing the token issuance.
The resource owner is not present and therefore not being authenticated. The grant is being validated (and it happens to be a username and password). The client is being authenticated. IOW, the server is authenticating the party making the request. In normal client-server flow, the client is or pretending to be the resource owner by presenting the resource owner's credentials. > > > > What you can do is define an authentication scheme which will > > authenticate the client and provide the grant in one header, or > > the spec makes the grant type a required parameter, so a lonely > authorization header won't be suffiencent. > > > define a new grant type for such credentials. But you can't use > > That brings us back to the mix between POST parameters and authz headers > for credential transmission. Something you critized for good reasons. > > > something like Basic or Digest to provide the resource owner's > > credentials. That's against the endpoint design. > > It's good to know that restriction, but I'm not happy :-( So based on that > information I would say, the only proper way to integrate standard HTTP > schemes would be to invent another endpoint for that purpose. The basic design is that the endpoint takes: 1. client authentication 2. authorization grant In a perfect world, #1 will always be in the Authorization header as the proper HTTP method for authenticating the requestor, and #2 will always be in the body or in another, non HTTP authentication header, as the payload of the request. Another idea I have been toying with is to define a new HTTP request header field which has the same exact format of the Authorization header, but just with another name such as 'Delegation'. In that case, a request using HTTP Basic for *both* client authentication and resource owner password credentials will look like this: GET /resource HTTP/1.1 Authorization: Basic [base64-of-client-password-credentials] Delegation: Basic [base64-of-resource-owner-password-credentials] This makes the delegation header syntax reuse everything from the Authorization header, allowing you to easily use any existing scheme you want, but clearly identifies the role of those credentials in the request. As for complying with the token endpoint required fields, that's just formality. We can simply define a grant type that means "grant is provided in the delegation header". EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
