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-boun...@ietf.org [mailto:oauth-boun...@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-boun...@ietf.org [mailto:oauth-boun...@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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
