Re: [OAUTH-WG] Call for Consensus on Document Split

Bearer token can fail for more than one reason [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

[1] http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5.2.1

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Manger, James H
> Sent: Monday, November 15, 2010 10:52 PM
> To: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Call for Consensus on Document Split
> 
> Eran,
> 
> > 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.
> 
> 
> --
> James Manger
> 
> 
> > -----Original Message-----
> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> > Of Manger, James H
> > Sent: Thursday, October 14, 2010 10:10 PM
> > To: oauth@ietf.org
> > Subject: Re: [OAUTH-WG] Call for Consensus on Document Split
> >
> > Eran,
> >
> > > How would you suggest we define a general purpose www-authenticate
> > > header that does not have a matching request header?
> >
> > Why would that be a problem?
> > We define what a "WWW-Authenticate: OAuth2 ..." response header
> means,
> > but don't define any meaning for a "Authorization: OAuth2 ..."
> > request header.
> > No other scheme should define a meaning for "Authorization: OAuth2 ...".
> > Consequently, the bearer token spec need to choose a different scheme
> > name (eg "BEARER" or "TOKEN" or "EXTERNAL") so it can define request &
> > response headers.
> >
> > There is even some precedent for this. draft-broyer-http-cookie-auth
> > defines "WWW-Authenticate: COOKIE ...", without any matching request
> > header.
> > I think there have also been ideas to define something like "WWW-
> > Authenticate: TLS ..." to indicate when authentication at a lower
> > layer (TLS,
> > IPsec) is required. Again there was no matching "Authorization: TLS ..."
> > header.
> >
> > --
> > James Manger
> >
> > _______________________________________________
> > 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