Subject: [OAUTH-WG] misuse of status code: 400 Bad Request

From: Robert Sayre <[email-masked]>
Date: Tue, 20 Apr 2010 21:01:44 -0400

The OAuth 2.0 draft uses HTTP status code 400 for access token
requests that are denied.

Here is the definition of 400:

   The request could not be understood by the server due to malformed
   syntax.  The client SHOULD NOT repeat the request without
   modifications.

Status 400 should be used for malformed requests, not those that are
understood and rejected. 401 seems to be a better fit.

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 21 Apr 2010 07:48:50 +0200

+1

I would propose to use appropriate HTTP status codes where possible. 
Especially wrong parameters (violated precodition) and 
authentication/authorization related errors should be signaled 
differently. I think status code 400 is ok for the first category, 
status codes 401 and probably 403 are good candidates for the other. 
Status code 401 could be combined w/ WW-Authenticate header.

regards,
Torsten.

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 21 Apr 2010 02:09:28 -0400

+1, but why "where possible" (vs always)?

Igor

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 21 Apr 2010 08:11:11 -0700

The reason I used 400 in the flows (section 3) is that a 401 response requires returning a challenge [1]:

   The request requires user authentication.  The response MUST include
   a WWW-Authenticate header field.

and we don't have a suitable challenge to return. We can't use the Token auth scheme here because the flow endpoints are not OAuth-protected resources. They use a mix of client credentials, user credentials, and verification codes.

(Yes James, your proposal will solve this...)

So instead of using a 401 without the required WWW-Authenticate header, I opted to use 400.

EHL

[1] http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-09#section-2.1

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Robert Sayre
> Sent: Tuesday, April 20, 2010 6:02 PM
> To: [email-masked]
> Subject: [OAUTH-WG] misuse of status code: 400 Bad Request
> 
> The OAuth 2.0 draft uses HTTP status code 400 for access token requests that
> are denied.
>

---

From: Robert Sayre <[email-masked]>
Date: Wed, 21 Apr 2010 11:24:05 -0400

> and we don't have a suitable challenge to return. We can't use the Token auth scheme here because the flow endpoints are not OAuth-protected resources. They use a mix of client credentials, user cr…

Yes, well, what the spec calls "flows" look to me like authentication
schemes used to get a token. My (free) advice would be to move all of
the flows to their own specs, perhaps leaving one in the document that
works using only HTTP authentication headers. That way, you'll finish
a lot faster, and other flows can use the base OAuth 2.0 document as a
reference. I am willing to provide text to illustrate this point.

-- 

Robert Sayre

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 21 Apr 2010 08:30:21 -0700

We tried something like this approach before but the group consensus was that we should only have a single spec for now. I submitted a draft defining just the Token auth scheme with the expectation that another drafts define the flows, but the group didn't like this approach.

As for using Basic/Digest for flow authentication, that's a proposal made by James Manger which so far received little support (though no hard objections).

I don't have a strong preference either way.

EHL

> From: Robert Sayre [mailto:[email-masked]]
> Sent: Wednesday, April 21, 2010 8:24 AM
> To: Eran Hammer-Lahav
> Cc: [email-masked]
> Subject: Re: [OAUTH-WG] misuse of status code: 400 Bad Request
> 
> > and we don't have a suitable challenge to return. We can't use the Token
> auth scheme here because the flow endpoints are not OAuth-protected
> resources. They use a mix of client credentials, user credentials, and
> verification codes.
> 
> Yes, well, what the spec calls "flows" look to me like authentication schemes
> used to get a token. My (free) advice would be to move all of the flows to
> their own specs, perhaps leaving one in the document that works using only
> HTTP authentication headers. That way, you'll finish a lot faster, and other
> flows can use the base OAuth 2.0 document as a reference. I am willing to
> provide text to illustrate this point.
> 
> --
> 
> Robert Sayre
>

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 21 Apr 2010 09:16:36 -0700

+1

At first 401 may seem like the perfect status code in this case, but
because there is no real challenge response, it probably is a bad
choice.

Some HTTP libraries will try to automatically respond to a 401
challenge and if they are not configured to do so will generate noise
in the log files. I have seen Apache HttpClient doing that.

An alternative to 400 would be to return 200 and the OAuth 2 error
message. Would that work?

Marius

---

From: Robert Sayre <[email-masked]>
Date: Wed, 21 Apr 2010 12:31:22 -0400

On Wed, Apr 21, 2010 at 11:30 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> We tried something like this approach before but the group consensus was that we should only have a single spec for now.

Eran kindly pointed me at this survey:
http://www.ietf.org/mail-archive/web/oauth/current/msg01214.html

It doesn't look like very strong consensus to me, but I can see how
the desire of everyone to call their thing "OAuth" can be a powerful
motivator. :)

> I don't have a strong preference either way.

Well, regardless of how big the spec gets, this bit from 3.6.1.1. is a bug:

     HTTP/1.1 400 Bad Request
     Content-Type: application/x-www-form-urlencoded

     error=incorrect_credentials

If you imagine a client trying to do something special with OAuth
errors, there's nothing about this response that's self describing.
Something like this layers much better:

     HTTP/1.1 401 Unauthorized
     WWW-Authenticate: OAuthDelegatation
     Content-Type: application/x-www-form-urlencoded

     error=incorrect_credentials

> because there is no real challenge response, it probably is a bad

There certainly is, it just isn't an Authorization header. A client
receiving error=incorrect_credentials would change the creds and
respond, right?

> in the log files. I have seen Apache HttpClient doing that.

People will write buggy OAuth clients too. Don't design around lame
bugs in Apache HttpClient. :)

-- 

Robert Sayre

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 21 Apr 2010 09:38:07 -0700

How about Marius' suggestion to use a 200 response?

I'd rather not invent a new auth scheme that is used just to comply with HTTP requirements for a 401... I think we either keep this simple(r) by using a 400 or 200, or take another look at James' proposal for using Basic auth to send the client credentials. At that point a 401 will be used when the client credentials are wrong, and a 400 (or 200) when something else doesn't match in the request (verification code, username/password).

Can others voice their support/dislike for the various options?

EHL

> Sent: Wednesday, April 21, 2010 9:31 AM
> To: Eran Hammer-Lahav
> Cc: [email-masked]
> > We tried something like this approach before but the group consensus was
> that we should only have a single spec for now.
> 
> It doesn't look like very strong consensus to me, but I can see how the desire
> of everyone to call their thing "OAuth" can be a powerful motivator. :)
> 
> > As for using Basic/Digest for flow authentication, that's a proposal made by
> James Manger which so far received little support (though no hard
> objections).
> >
> If you imagine a client trying to do something special with OAuth errors,
> there's nothing about this response that's self describing.
> There certainly is, it just isn't an Authorization header. A client receiving
> error=incorrect_credentials would change the creds and respond, right?
> 
> >
> People will write buggy OAuth clients too. Don't design around lame bugs in
> Apache HttpClient. :)
> 
> --
> 
> Robert Sayre
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 21 Apr 2010 19:03:12 +0200

+1 pro James' proposal

---

From: John Kemp <[email-masked]>
Date: Wed, 21 Apr 2010 13:12:55 -0400

You all might want to take a look at Thomas Broyer's cookie-auth HTTP auth scheme: http://tools.ietf.org/html/draft-broyer-http-cookie-auth-00 for what he did to implement something reasonably similar.

I do think it would be nice if we don't abuse HTTP, which suggests we should define a new HTTP authentication scheme. So I would give a +1 to using HTTP 401 and doing some sort of a modification of the cookie-auth proposal to create the new scheme.

Regards,

- johnk

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 21 Apr 2010 10:16:06 -0700

> receiving error=incorrect_credentials would change the creds and

Respond yes, but not with a proper 401 response which requires the
"Authorization" header.

> bugs in Apache HttpClient. :)

I don't think this is a bug. HttpClient can probably be configured to
ignore the 401, not sure, but this just shows that a half baked 401 is
used.

Marius

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 21 Apr 2010 19:39:21 +0200

I agree, we should not abuse HTTP. Why not just use BASIC authentication?

More arguments pro HTTP authentication can be found in thread 
http://www.ietf.org/mail-archive/web/oauth/current/msg01952.html.

regards,
Torsten.

---

From: Robert Sayre <[email-masked]>
Date: Wed, 21 Apr 2010 15:50:34 -0400

> Respond yes, but not with a proper 401 response which requires the

I did address the lack of an Authorization header in my last message.
I don't see why propriety is an issue.

-- 

Robert Sayre