9

I have a web application with a Javascript part running on the browser. That frontend uses several HTTP endpoints (more or less REST). The frontend must be able to distinguish between 401 and 403 responses and must not receive the 3xx redirects usually used for human users.

Authorization is done with a plain form login (no Javascript involved there), then a session cookie is used (for both "REST" and normal requests).

What would be a correct value for the WWW-Authenticate header value?

See also:

Community
  • 1
  • 1
Gustave
  • 3,359
  • 4
  • 31
  • 64

4 Answers4

6

What would be a correct value for the WWW-Authenticate header value?

There's no point in returning 401 and WWW-Authenticate when you are not using HTTP Authentication as described in the RFC 7235. In HTTP Authentication, the client is expected to send the credentials in the Authorization header of the request with an authentication scheme token.

If you want to send the credentials in the request payload using POST, the 403 status code you be more suitable to indicate that the server has refused the request.

Community
  • 1
  • 1
cassiomolin
  • 124,154
  • 35
  • 280
  • 359
4

Since there is no standard challenge for this type of authentication, you are (as you predicted yourself) inventing your own.

I don't think there is a standard mechanism for specifying vendor tokens here, so I think the best thing you can do is use a token that's unlikely to clash with anything else.

Amazon has done this with AWS, and there's many others. My recommendation would be to use something like productname-schemename, for example acme-webauth.

Evert
  • 93,428
  • 18
  • 118
  • 189
1

In theory you should respond

HTTP/1.x 401 Unauthorized
WWW-Authenticate: cookie; cookie-name=my-session-cookie-name

However, real world internet browsers (user agents) do not really support this and in my experience the least bad option is to use HTTP status 403 for all of "Access Denied", "Unauthorized" or "Not allowed". If you have a REST service that's accessed with non-browser user-agents only, you could just follow the spec and return the above headers.

Also note that as described in RFC 7231 section 6.5.4 (https://www.rfc-editor.org/rfc/rfc7231#section-6.5.4) the server can respond with 404 for both "Access Denied" and "Not Found" so following should be okay for all user agents (browsers and standalone clients):

403 Unauthorized or Not allowed

404 Access Denied or Not Found

Or, you can just use 400 for any case because that should cause browser do fallback to generic error handling case. The HTTP status code 401 is especially problematic because it historically meant (at least in practice) that Basic Realm authentication is in use and the submitted HTTP header Authorization was not accepted. Because you cannot submit the session cookie via that header with commonly available browsers, those browsers have trouble handling 401 correctly when you use cookies for authentication. (According to the spec, HTTP 401 MUST include header WWW-Authenticate which should be used to figure out correct handling by the user agent but this doesn't seem to happen in reality with browsers.)

Mikko Rantalainen
  • 14,132
  • 10
  • 74
  • 112
0

There is no HTTP authentication scheme for form based authentication. Browsers implement basic, digest, etc. by showing a pop up where you can enter credentials.

spaceone
  • 121
  • 3
  • That's basically what I said with "The Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry does not list any scheme for form-based authentication.", isn't it? And now, should I just invent a scheme? I guess I am not the first one with this problem. Browsers host Javascript apps and those may understand more things than the browser itself. So, if no formal spec, maybe a best practice? – Gustave Jan 23 '18 at 18:41
  • `WWW-Authenticate` is not used with Form-based authentication - period. You will have to use 403 instead of 401 – Remy Lebeau Jan 23 '18 at 19:46
  • If you "invent" your "FormBased" scheme you have still the problem that you are sending e.g. a POST request with some application/x-www-form-urlencoded credentials which is wrong and not expected. You must use the WWW-Authenticate request header to provide credentials and you have to send them along with each following request as in HTTP the communication must be stateless. – spaceone Jan 23 '18 at 21:39
  • @spaceone I don't think RFC7235 states that a WWW-Authenticate header requires authentication to be done with the Authorization header. I couldn't find any language supporting this. – Evert Jan 23 '18 at 21:47
  • From my point of view the WWW-Autentication header just indicates authentication is required, and there's a token indicating what protocol should be used. The authentication semantics depend on the token. – Evert Jan 23 '18 at 21:48
  • Reading RFC further, it actually specifically states that the Authorization header is "usually, but not necessarily", but let me know if your interpretation is different. – Evert Jan 23 '18 at 21:51