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.
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.
Comments?
regards,
Torsten.
EHL
-----Original Message-----
From: tors...@lodderstedt.net [mailto:tors...@lodderstedt.net]
Sent: Monday, January 24, 2011 10:35 PM
To: Eran Hammer-Lahav; OAuth WG
Subject: AW: RE: [OAUTH-WG] How to integrated DIGEST or SPNEGO with
tokensendpoint?
Hi Eran,
thanks for your response. My inquiry was about end-user authentication and
not about client authentication. All http schemes I'm aware of authenticate
users and I want to find a way to leverage them with OAuth to determine the
token's identity.
Regards,
Torsten.
Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland
-----Original Message-----
From: Eran Hammer-Lahav <e...@hueniverse.com>
Date: Mon, 24 Jan 2011 15:25:38
To: Torsten Lodderstedt<tors...@lodderstedt.net>; OAuth
WG<oauth@ietf.org>
Subject: RE: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens
endpoint?
This is pretty straight-forward. There are no special parameters to
indicated
which client authentication is being used. It's either there or not, using
whatever the server supports.
Simply have the token endpoint return a 401 with these WWW-Authenticate
headers. As long as you make it clear how to make between the client
identifier and the credentials used, you are set.
For example, a token response can return:
401 Unauthorized
WWW-Authenticate: Basic realm="example"
WWW-Authenticate: Digest realm="example"
There is no discovery for support for the client_id and client_secret
parameters. The client can simply try it or hardcode it based on
the server's
documentation.
Does this help?
EHL
> -----Original Message-----
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Torsten Lodderstedt
> Sent: Monday, January 24, 2011 1:10 PM
> To: OAuth WG
> Subject: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens
> endpoint?
>
> Hi all,
>
> I'm currently thinking about the integration of existing HTTP
> authentication schemes with OAuth 2.0 for the purpose of end-user
> authentication on the tokens endpoint. Possible candidates are "Digest"
> for challenge-response-based username/password authentication and
> "Spnego" for Kerberos-based authentication. Direct support for both
> could be beneficially in enterprise and other security sensitive
deployments.
>
> An direct integration with the tokens endpoint would allow to leverage
> existing implementations and infrastructure for OAuth/HTTP-based
> architectures. For example, HTTPClient has direct support for Spnego-
> Authentication.
>
> Both HTTP authentication schemes use dedicated WWW-Authenticate and
> Authorization headers for passing credential and other data between
> client and server. OAuth in contrast uses grant types to indicate the
> authentication method, credentials are passed as URI query parameters
> and it lacks any discovery of available authentication methods/
grant types.
>
> How could one integrate existing schemes into that design? What is our
> story? Do we need to define a special grant type "HTTP authorization"?
> Shall Authorization headers overrule URI parameters?
>
> Any ideas of the WG are higly appreciated.
>
> regards,
> Torsten.
>
>
>_______________________________________________
> 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
