Am 25.01.2011 10:25, schrieb Bob Gregory:
Perhaps I'm missing something here, but once a client has requested an
access grant, the auth server is free to authenticate the end-user in
whatever way it chooses, and it would seem sensible to signal authn
requirements with standard HTTP headers.
Why, then, would you want to integrate existing HTTP schemes at the
token endpoint instead of at the authorization endpoint?
You certainly can integrate HTTP authentication schemes into the
end-user authorization endpoint. But this endpoint is intended to be
used for direct interaction between end-user and authorization server
and requires to open a web browser. That's something one probably does
not want for on certain devices (handsets, gaming devices) or if no user
consent is required (enterprise). So I'm looking into cases, where the
client wants to directly exchange credentials, such as password or
ticket for an access token. I mean the resource owner password flow is
already an example of such a flow.
regards,
Torsten.
-- Bob Gregory
On Tue, Jan 25, 2011 at 8:22 AM, Torsten Lodderstedt
<[email protected] <mailto:[email protected]>> wrote:
Zitat von Eran Hammer-Lahav <[email protected]
<mailto:[email protected]>>:
> 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: [email protected] <mailto:[email protected]>
[mailto:[email protected] <mailto:[email protected]>]
>> 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 <[email protected]
<mailto:[email protected]>>
>> Date: Mon, 24 Jan 2011 15:25:38
>> To: Torsten Lodderstedt<[email protected]
<mailto:[email protected]>>; OAuth
>> WG<[email protected] <mailto:[email protected]>>
>> 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: [email protected] <mailto:[email protected]>
[mailto:[email protected] <mailto:[email protected]>] 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
>> > [email protected] <mailto:[email protected]>
>> > https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
