27

HTTP defines the status 401 Unauthorized for missing authentication, but this status only applies to HTTP authentication. What status should I return with a session cookie based system, when an unauthorized request happens?

deamon
  • 89,107
  • 111
  • 320
  • 448

2 Answers2

32

Formally, 403 Forbidden is the right response. It's defined as

Authorization will not help and the request SHOULD NOT be repeated.

The confusing part may be "Authorization will not help", but they really mean "HTTP authentication" (WWW-Authenticate)

Martin v. Löwis
  • 124,830
  • 17
  • 198
  • 235
  • 4
    This means the user should not EVER attempt the request again. This is not appropriate. – Erik Philips Nov 29 '10 at 08:20
  • 2
    Technically, I believe you are correct. In the case of practical implementation, I believe a 200 with an HTML based error message or 302 redirecting to another page where session based login can occur is more common (and perhaps arguably more useful). – userx Nov 29 '10 at 08:21
  • 8
    @Erik Philips - This is correct, the request shouldn't be. Once the headers of the request are altered to have a correct session cookie (hence not the SAME request), access will be granted. – userx Nov 29 '10 at 08:22
  • 3
    I don't know if it's not misleading to strongly reference the authorization METHOD. IMO it doesn't matter if the authorization is transferred over cookies or header field, the critical information of the status code is if the reason of the failure is due to unauthorized request (token expired/not specified – 401) or if the user is not approved to access this resource and there is no way to change it with his "account" (403). – JakubKnejzlik Jul 22 '14 at 23:29
  • See also [403 Forbidden vs 401 Unauthorized HTTP responses](https://stackoverflow.com/q/3297048/1048572) – Bergi Sep 14 '20 at 13:49
5

403 I believe is technically correct (and probably most effective if you are implementing a custom API / protocol).

401 is not appropriate as it refers to authorization with a WWW-Authenticate header, which a session cookie is not.

If this is a public facing website where you are trying to deny access based on a session cookie, 200 with an appropriate body to indicate that log in is needed or a 302 temporary redirect to a log in page is often best.

userx
  • 3,769
  • 1
  • 23
  • 33
  • This would be fixable my actually defining a cookie-based HTTP authentication scheme. – Julian Reschke Nov 29 '10 at 08:35
  • @Julian Reschke - Well cookies don't by definition have much to do with authentication; primarily, they are adding some amount of "state" to a "state-less" protocol, HTTP. Cookies themselves don't authenticate anything. They are simply information being sent to a server which that server previously asked the browser to save. Yes, that information can be used for determining if you previously were authenticated as a user (typically via HTTP POST / GET). It also can simply be used to indicate whether you've seen a particular ad before, or visited that site before and when, etc. – userx Nov 29 '10 at 08:39