Subject: [OAUTH-WG] OAuth2 WWW-Authenticate scheme

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 16 Nov 2010 09:36:09 -0700

Bearer token can fail for more than one reason (section 5.2.1). Clients are allowed to try more than one authentication scheme. So if we allow clients to try more than one OAuth-related scheme, we need to provide an error that identifies which of the schemes provided by the client the server choked on. Or we can only allow a single scheme per request (which is fine by me but somewhat of a departure from HTTP).

We can say that an OAuth2 challenge is always included (fail or first time). Do we keep the current error reporting setup?

EHL

> -----Original Message-----
> From: Manger, James H
> Sent: Monday, November 15, 2010 10:52 PM

> > If the challenge uses the OAuth2 scheme, and the client tries
> > OAuth2-Bearer to authenticate and fails, which scheme should the
> > server use in its reply to include an error message?
> > OAuth2, OAuth2-Bearer, both?
>
> "WWW-Authenticate: OAuth2..." should be included in the response when
> an auth error occurs.
> "WWW-Authenticate: Bearer..." could be included if it might help, but
> probably isn't necessary.
>
> The Bearer scheme by itself probably doesn't have any error that the client
> app can correct. Either the opaque bearer token works or you need a new
> one. Getting a new one is an OAuth2 flow so the "WWW-Authenticate:
> OAuth2..." response is appropriate.
>
>
> > ...to include an error message
>
> Are you asking about which response header to include auth error info in, as
> opposed to which response header to return?
> I don't think it makes sense to include error messages that are specific to the
> OAuth2 delegation flow in a "WWW-Authenticate: Bearer..." response
> header -- just like it wouldn't make sense to include those details in a
> "WWW-Authenticate: BASIC..." response header.

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 17 Nov 2010 11:13:15 +1100

Eran,

> Clients are allowed to try more than one authentication scheme.

I don't think so -- at least not in a single request.
HTTP certainly allows a server to advertise multiple schemes in a *response* (via "WWW-Authenticate" headers). This is widely used.
However, HTTP does not allow multiple schemes in a request (ie it does not allow multiple "Authorization" headers).
The current httpbis draft says (draft-ietf-httpbis-p7-auth-12, section 2):
  "The user agent MUST choose to use *one* of the challenges
   with the strongest auth-scheme it understands"

> Or we can only allow a single scheme per request
> (which is fine by me but somewhat of a departure from HTTP).

I don't think this is a departure.
I can't think of any current systems that use multiple HTTP auth schemes in a single request.

> We can say that an OAuth2 challenge is always included (fail or first time).
> Do we keep the current error reporting setup?

It is clear (in my mind) that a server should use a "WWW-Authenticate: OAuth2..."
response header to say to the client:
  "Hey, you can get access to this resource (or better access)
   if you first run an OAuth flow: with these endpoints & parameters"

But there are a number of OAuth flows:
* user delegation
* swapping client credentials for a token (or swapping an assertion for a token)
* refreshing an existing token/delegation

The server needs to give the client enough information for it to know what it
can do next, eg which OAuth flow to perform.
A good approach would be for the "WWW-Authenticate: OAuth2..." response to
explicitly indicate which flows are possible *at this point*.
If a "WWW-Authenticate: OAuth2..." response includes a refresh=<uri> parameter,
for instance, then the client knows they can refresh their existing token.
If the "WWW-Authenticate: OAuth2..." response includes a user=<uri> parameter,
but no refresh parameter, then the client knows they can run a user-delegation
flow, but they cannot refresh their existing token.

--
James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 16 Nov 2010 18:25:08 -0700

WFM. I'll apply this to -11 and publish it shortly. This was the last open issue I had with the split. Looks like OAuth2 has consensus as the auth scheme name (I find it gross but lost all interest in any further discussions).

EHL

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Manger, James H
> Sent: Tuesday, November 16, 2010 4:13 PM
> To: OAuth WG
> Subject: Re: [OAUTH-WG] OAuth2 WWW-Authenticate scheme
> 
> Eran,
> 
> HTTP certainly allows a server to advertise multiple schemes in a *response*
> (via "WWW-Authenticate" headers). This is widely used.
> > Or we can only allow a single scheme per request (which is fine by me
> > but somewhat of a departure from HTTP).
> 
> A good approach would be for the "WWW-Authenticate: OAuth2..."
> response to explicitly indicate which flows are possible *at this point*.
> If a "WWW-Authenticate: OAuth2..." response includes a refresh=<uri>
> parameter, for instance, then the client knows they can refresh their existing
> token.
> If the "WWW-Authenticate: OAuth2..." response includes a user=<uri>
> parameter, but no refresh parameter, then the client knows they can run a
> user-delegation flow, but they cannot refresh their existing token.
> 
> 
> --
> James Manger
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth