Dev Stack Source

Answer : The exact satisfying one-time-for-all answer I found is: Short answer: 401 Unauthorized Description: While we know first is authentication (has the user logged-in or not?) and then we will go into authorization (does he have the needed privilege or not?), but here's the key that makes us mistake: But isn’t “401 Unauthorized” about authorization, not authentication? Back when the HTTP spec (RFC 2616) was written, the two words may not have been as widely understood to be distinct. It’s clear from the description and other supporting texts that 401 is about authentication. From HTTP Status Codes 401 Unauthorized and 403 Forbidden for Authentication and Authorization (and OAuth). So maybe, if we want to rewrite the standards! focusing enough on each words, we may refer to the following table: Status Code | Old foggy naming | New clear naming | Use case +++++++++++ | ++++++++++++++++ | ++++++++++++++++ | ++++++++++++++++++++++++++++++++++ 401 | Unaut...

Answer : A clear explanation from Daniel Irvine: There's a problem with 401 Unauthorized , the HTTP status code for authentication errors. And that’s just it: it’s for authentication, not authorization. Receiving a 401 response is the server telling you, “you aren’t authenticated–either not authenticated at all or authenticated incorrectly–but please reauthenticate and try again.” To help you out, it will always include a WWW-Authenticate header that describes how to authenticate. This is a response generally returned by your web server, not your web application. It’s also something very temporary; the server is asking you to try again. So, for authorization I use the 403 Forbidden response. It’s permanent, it’s tied to my application logic, and it’s a more concrete response than a 401. Receiving a 403 response is the server telling you, “I’m sorry. I know who you are–I believe who you say you are–but you just don’t have permi...