Subject: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens endpoint?

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 24 Jan 2011 22:10:02 +0100

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.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 24 Jan 2011 15:25:38 -0700

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-masked] [mailto:[email-masked]] 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"
> "Spnego" for Kerberos-based authentication. Direct support for both could
> be beneficially in enterprise and other security sensitive deployments.
> 
> architectures. For example, HTTPClient has direct support for Spnego-
> Authentication.
> 
> 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.
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Mon, 24 Jan 2011 14:56:07 -0800

Why not have the token server specify a form based authentication for OAuth token requests? 

WWW-Authenticate: Form url="/tokenrequest.jsp"

Thus, a server could respond:
401 Unauthorized
WWW-Authenticate: Basic realm="example"
WWW-Authenticate: Digest realm="example"
WWW-Authenticate: Form url="/tokenrequest.jsp",realm="example"

Normally, a form would have caused a redirect, but in this case we aren't talking about browser based clients so the redirect doesn't make sense.  This gives the clients a choice and a way to discover parameters (if really needed). By parsing the form, it could discover what form parameters are required. I suspect as Eran indicates below, this wouldn't happen to often as site server documentation would already make this clear.

Phil
[email-masked]

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 24 Jan 2011 16:11:47 -0700

I am not sure I understand this exactly, but I don't see the need. Basically, the token endpoint requires client authentication (yeah, with exceptions). The spec provides one super-simple way to accomplish that using form-encoded parameters, but that's really focused on the hardcoded clients - those pointed at known services. While libraries will support the two parameters, it is unlikely that clients will use it to obtain a token from an unfamiliar server (since they are not registered).

IOW, the client password credential authentication described in the spec is a useful hack for the common needs most API developers today have, based on existing API keys used. I would hate see this expanded to more hack-ish client authentication schemes using parameters. In general, alternative client authentication methods (which have nothing to do directly with the two parameters), should be defined or adopted for client authentication using normal HTTP authentication headers.

The way to think about this is to remove client authentication from the token endpoint and just assume the server doesn't care about client identity. You give it a grant and get back an access token. Now, since we do care about client identity, we add client authentication *on-top* of the endpoint. The two parameters are therefore a hack which adds authentication into the endpoint. New schemes should work outside the request.

EHL

> From: Phil Hunt [mailto:[email-masked]]
> Sent: Monday, January 24, 2011 2:56 PM
> To: Eran Hammer-Lahav
> Cc: Torsten Lodderstedt; OAuth WG
> Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens
> endpoint?
> 
> Normally, a form would have caused a redirect, but in this case we aren't
> talking about browser based clients so the redirect doesn't make sense.  This
> gives the clients a choice and a way to discover parameters (if really needed).
> By parsing the form, it could discover what form parameters are required. I
> suspect as Eran indicates below, this wouldn't happen to often as site server
> documentation would already make this clear.
> 
> Phil
> [email-masked]
> 
> 
> 
> 
> > 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.
> >
> > 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
> >
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Torsten Lodderstedt
> >> 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.
> >>
> >> How could one integrate existing schemes into that design? What is
> >> our story? Do we need to define a special grant type "HTTP
> authorization"?

---

From: Phil Hunt <[email-masked]>
Date: Mon, 24 Jan 2011 15:39:09 -0800

I think the problem comes up if you want to authenticate using some other means (e.g. client_assertion) using form based authentication.  At that point separation between the token end-point and platform security is not clear.  The client_id and client_secret approach also has the same issue of not separating client authentication from the token request.

One possible flow might be:

Step 1: client: request token (no client credential supplied)
Step 2: server responds with authentication required, returns HTTP 401 as below
401 Unauthorized
WWW-Authenticate: Basic realm="tokenSvc"
WWW-Authenticate: Digest realm="tokenSvc"
WWW-Authenticate: Form url="/clientAuthenticate.jsp",realm="tokenSvc"

Step 3: client elects form based authentication by responding to the form returned from clientAuthenticate.jsp. For example, the form might require client_assertion, or other form based authentication approaches.

Step 4: server authenticates and returns a "client" token used token requests.
Step 5: client goes to original token endpoint and by client authorization token (in Authorization header) and original request.

Sure the spec says client_id and secret, but doesn't allow for the form to specify other required elements the site wants to impose.  

By actually asking for the form, the client can discover what is needed.  Also, steps 1-4 might only have to be done relatively infrequently. Once a client is authenticated, it could make multiple OAuth token requests for multiple grant codes.

Another variation (combined token and client auth) is a case where authentication field and token request are combined in one form. Not sure if WWW-Authenticate should indicate that variation. 

Phil
[email-masked]

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 24 Jan 2011 16:42:20 -0700

My point is that for client_id/client_secret this is not needed because clients are only likely to use it when dealing with a known server with well-known characteristics. Those defining other schemes, including client_assertion will need to figure out their client profile and how to address its needs.

EHL

> Sent: Monday, January 24, 2011 3:39 PM
> To: Eran Hammer-Lahav
> I think the problem comes up if you want to authenticate using some other
> means (e.g. client_assertion) using form based authentication.  At that point
> separation between the token end-point and platform security is not clear.
> The client_id and client_secret approach also has the same issue of not
> separating client authentication from the token request.
> 
> Step 1: client: request token (no client credential supplied) Step 2: server
> responds with authentication required, returns HTTP 401 as below
> 401 Unauthorized
> Step 3: client elects form based authentication by responding to the form
> returned from clientAuthenticate.jsp. For example, the form might require
> client_assertion, or other form based authentication approaches.
> 
> Step 5: client goes to original token endpoint and by client authorization
> token (in Authorization header) and original request.
> 
> Sure the spec says client_id and secret, but doesn't allow for the form to
> specify other required elements the site wants to impose.
> 
> By actually asking for the form, the client can discover what is needed.  Also,
> steps 1-4 might only have to be done relatively infrequently. Once a client is
> authenticated, it could make multiple OAuth token requests for multiple
> grant codes.
> 
> Another variation (combined token and client auth) is a case where
> authentication field and token request are combined in one form. Not sure if
> WWW-Authenticate should indicate that variation.
> 
> Phil
> [email-masked]
> 
> 
> 
> 
> > I am not sure I understand this exactly, but I don't see the need. Basically,
> the token endpoint requires client authentication (yeah, with exceptions).
> The spec provides one super-simple way to accomplish that using form-
> encoded parameters, but that's really focused on the hardcoded clients -
> those pointed at known services. While libraries will support the two
> parameters, it is unlikely that clients will use it to obtain a token from an
> unfamiliar server (since they are not registered).
> >
> > IOW, the client password credential authentication described in the spec is
> a useful hack for the common needs most API developers today have, based
> on existing API keys used. I would hate see this expanded to more hack-ish
> client authentication schemes using parameters. In general, alternative client
> authentication methods (which have nothing to do directly with the two
> parameters), should be defined or adopted for client authentication using
> normal HTTP authentication headers.
> >
> > The way to think about this is to remove client authentication from the
> token endpoint and just assume the server doesn't care about client identity.
> You give it a grant and get back an access token. Now, since we do care about
> client identity, we add client authentication *on-top* of the endpoint. The
> two parameters are therefore a hack which adds authentication into the
> endpoint. New schemes should work outside the request.
> >
> > EHL
> >
> >
> >> Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with
> >> tokens endpoint?
> >>
> >> Normally, a form would have caused a redirect, but in this case we
> >> aren't talking about browser based clients so the redirect doesn't
> >> make sense.  This gives the clients a choice and a way to discover
> parameters (if really needed).
> >> By parsing the form, it could discover what form parameters are
> >> required. I suspect as Eran indicates below, this wouldn't happen to
> >> often as site server documentation would already make this clear.
> >>
> >> Phil
> >> [email-masked]
> >>
> >>
> >>
> >>
> >> which client authentication is being used. It's either there or not,
> >> using whatever the server supports.
> >>>
> >> Authenticate headers. As long as you make it clear how to make
> >> between the client identifier and the credentials used, you are set.
> >>>
> >> parameters. The client can simply try it or hardcode it based on the
> >> server's documentation.
> >>>
> >>> Does this help?
> >>>
> >>> EHL
> >>>
> >>>> 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.
> >>>>

---

From: [email-masked]
Date: Tue, 25 Jan 2011 06:35:20 +0000

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® Webmail von Telekom Deutschland  

-----Original Message-----
From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 24 Jan 2011 15:25:38 
To: Torsten Lodderstedt<[email-masked]>; OAuth WG<[email-masked]>
Subject: RE: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens
 endpoint?

401 Unauthorized

Does this help?

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 25 Jan 2011 00:51:37 -0700

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 you can do is define an authentication scheme which will authenticate the client and provide the grant in one header, or define a new grant type for such credentials. But you can't use something like Basic or Digest to provide the resource owner's credentials. That's against the endpoint design.

EHL

> From: [email-masked] [mailto:[email-masked]]
> 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
> 
> 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.
> 
> > and it lacks any discovery of available authentication methods/ grant types.
> >

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 25 Jan 2011 09:22:30 +0100

Zitat von Eran Hammer-Lahav <[email-masked]>:

> 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.

---

From: Bob Gregory <[email-masked]>
Date: Tue, 25 Jan 2011 09:25:27 +0000

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?

-- Bob Gregory

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 25 Jan 2011 09:41:29 -0700

Torsten is looking to supplement/replace the Resource Owner Password Credentials grant with similar constructs but using existing user password frameworks. This has nothing to do with actual user interactions and the authorization endpoint.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bob Gregory
Sent: Tuesday, January 25, 2011 1:25 AM
To: Torsten Lodderstedt
Cc: Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokensendpoint?

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?

-- Bob Gregory

On Tue, Jan 25, 2011 at 8:22 AM, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:

Comments?

regards,
Torsten.

>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
>> From: Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>>
>> To: Torsten Lodderstedt<[email-masked]<mailto:[email-masked]>>; OAuth
>> WG<[email-masked]<mailto:[email-masked]>>
>> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
>> > Of Torsten Lodderstedt
>> > [email-masked]<mailto:[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Eaton <[email-masked]>
Date: Tue, 25 Jan 2011 09:53:20 -0800

Hey Torsten -

I'm trying to parse through these messages to figure out the flows
you're interested in.

I think you're aiming for rules like this one, right?

kerberos authentication -> access token

    or

digest authentication -> access token

And furthermore your intended use cases are applications installed on
an end-users machine, where the end-users machine participates in some
kind of authentication service.  For example, maybe the machine is
joined to some kerberos realm, or maybe the user has a smart card.

Have I identified the use cases properly?  Or are you dealing with
three-legged OAuth situations, where you actually want user consent on
a web page?

Cheers,
Brian

On Tue, Jan 25, 2011 at 12:22 AM, Torsten Lodderstedt
<[email-masked]> wrote:
>> 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
>
> That brings us back to the mix between POST parameters and authz headers for
> credential transmission. Something you critized for good reasons.
>
> 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
>>
>>
>>> server's

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 25 Jan 2011 23:58:14 -0700

> From: Torsten Lodderstedt [mailto:[email-masked]]
> 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?
> 
> 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.

> That brings us back to the mix between POST parameters and authz headers
> for credential transmission. Something you critized for good reasons.
> 

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

---

From: [email-masked]
Date: Wed, 26 Jan 2011 08:45:02 +0000

Hi Brian,

you identified the use cases correctly. No interactive user-consent would be required.

Regards,
Torsten.

-----Original Message-----
From: Brian Eaton <[email-masked]>
Date: Tue, 25 Jan 2011 09:53:20 
To: Torsten Lodderstedt<[email-masked]>
Cc: Eran Hammer-Lahav<[email-masked]>; OAuth WG<[email-masked]>
Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokensendpoint?

Hey Torsten -

    or

Cheers,
Brian

---

From: Brian Eaton <[email-masked]>
Date: Wed, 26 Jan 2011 09:00:12 -0800

OK, thanks for clarifying.  Back to your original questions.

We've been handling this mostly in a single shared token endpoint.  In
a few cases we've gone with separate end-points because it made things
easier.  We've kept parameters such as scope consistent, since they
are properties of the output token rather than the input
authentication.

Precedent of authentication methods hasn't been an issue - the client
only sends one.

We haven't done any work on discovery, because the client wouldn't be
sending the authentication credentials if it didn't know what it was
doing already.

We've also done some work on authentication plug-ins that find the
credentials on the machine and use them, without telling the calling
application exactly where they came from.  We've talked about
SASL/GSSAPI/PAM/SSPI style integration, but so far that hasn't seemed
like a high-value proposition.

---

From: Brian Eaton <[email-masked]>
Date: Wed, 26 Jan 2011 09:01:22 -0800

On Tue, Jan 25, 2011 at 10:58 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> The resource owner is not present and therefore not being authenticated.

OK, so it turns out that in this use case the resource owner is
present, and is being authenticated.  They happen to be using a client
other than a web browser.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 26 Jan 2011 10:07:28 -0700

Can you share an actual example of how you are authenticating *both* the resource owner and client in a single request?

EHL

> From: Brian Eaton [mailto:[email-masked]]
> Sent: Wednesday, January 26, 2011 9:01 AM
> To: Eran Hammer-Lahav
> OK, so it turns out that in this use case the resource owner is present, and is
> being authenticated.  They happen to be using a client other than a web
> browser.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 26 Jan 2011 22:43:24 +0100

Am 25.01.2011 10:25, schrieb Bob Gregory:
> 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-masked] <mailto:[email-masked]>> wrote:
>
>     >> From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>]
>     >> WG<[email-masked] <mailto:[email-masked]>>
>     >> > From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     Behalf
>     >> > Of Torsten Lodderstedt
>     leverage
>     Spnego-
>     >> > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Brian Eaton <[email-masked]>
Date: Wed, 26 Jan 2011 14:02:25 -0800

> Can you share an actual example of how you are authenticating *both* the resource owner and client in a single request?

That's not a business requirement.

So the desired flow goes like this:

    kerberos (or other magic sauce) authentication -> access token

not like this:

    client authentication + kerberos authentication -> access token

and definitely not like this:

    client authentication + kerberos authentication -> refresh token

If we did see a need to authenticate the client, we would use the same
mechanisms as normal: client_id and client_secret, or else
client_assertion.

(Curious to know if other people looking at these problems break it
down the same way.)

Cheers,
Brian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 26 Jan 2011 15:53:55 -0700

Can you share what the actual request looks on the wire? How are you passing the Kerberos authentication in the request? What do you set the grant type to?

EHL

> Sent: Wednesday, January 26, 2011 2:02 PM
> To: Eran Hammer-Lahav
> > Can you share an actual example of how you are authenticating *both* the
> resource owner and client in a single request?
> 
> mechanisms as normal: client_id and client_secret, or else client_assertion.
> 
> (Curious to know if other people looking at these problems break it down the
> same way.)
> 
> Cheers,
> Brian

---

From: Brian Eaton <[email-masked]>
Date: Wed, 26 Jan 2011 17:37:33 -0800

> Can you share what the actual request looks on the wire? How are you passing the Kerberos authentication in the request? What do you set the grant type to?

Most of this pre-dates grant type and the OAuth2 brand. =)

>From memory, the kerberos to access token swap looks like this:

GET /some/token/endpoint?s=<scope>&g=<desired-ticket-attributes>
Authorization: Negotiate <stock-negotiate-kerberos-header-here>

And the response includes a ticket that is basically an OAuth2 access
token, for the specified scope, with some additional metadata
requested by the "g" parameter.

Cheers,
Brian

---

From: Brian Eaton <[email-masked]>
Date: Wed, 26 Jan 2011 17:38:01 -0800

Cheers,
Brian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 26 Jan 2011 20:22:17 -0700

So technically, this is not a token endpoint, per OAuth 2.0, but an endpoint where you can get tokens using some other parameters and headers. This is perfectly fine, but is using a different design.

EHL

> Sent: Wednesday, January 26, 2011 5:38 PM
> To: Eran Hammer-Lahav
> > Can you share what the actual request looks on the wire? How are you
> passing the Kerberos authentication in the request? What do you set the
> grant type to?
> 
> And the response includes a ticket that is basically an OAuth2 access token,
> for the specified scope, with some additional metadata requested by the "g"
> parameter.
> 
> Cheers,
> Brian