Return HTTP 401 Unauthorized for authorization errors.

[branlwyd]

Previously, we were returning 400 Bad Request, likely based on the following text from the DAP specification:

This document uses the verbs "abort" and "alert with [some error message]" to describe how protocol participants react to various error conditions. This implies HTTP status code 400 Bad Request unless explicitly specified otherwise.

...but the authorization section of the spec does not list an authorization error as an "abort", and 401 Unauthorized is a much more common response code for authorization errors.

[tgeoghegan]

I'm fine with using something more specific than 400 here. My concern though is whether we should use 401 or 403. In particular, RFC 9110 explains that if we respond with 401, we should have a WWW-Authenticate header with a challenge for the client to respond to. I'm not sure what kind of challenge is appropriate, but I know we're not issuing one.

I wonder if 403 Forbidden is better.

edit: my other concern is consistency with error codes. I'm very mildly concerned with the difference between 400, 401 and 403 providing a useful signal to an attacker (i.e. enabling some enumeration attack against tasks). I could have sworn we already use HTTP 403 elsewhere, but I can't find anything searching for "403" or "Forbidden" in Janus sources.

[branlwyd]

I'm fine with using something more specific than 400 here. My concern though is whether we should use 401 or 403. In particular, RFC 9110 explains that if we respond with 401, we should have a WWW-Authenticate header with a challenge for the client to respond to. I'm not sure what kind of challenge is appropriate, but I know we're not issuing one.

I wonder if 403 Forbidden is better.

You're right (of course) about the need for a WWW-Authenticate header if we return a 401 status code. IMO 401 is more semantically-correct than 403 here, but I stared at the Authentication: Bearer challenge type for a while and I don't think we can meaningfully adapt it to our uses, since we're not actually passing an OAuth token around. So, 403 Forbidden it is.

edit: my other concern is consistency with error codes. I'm very mildly concerned with the difference between 400, 401 and 403 providing a useful signal to an attacker (i.e. enabling some enumeration attack against tasks). I could have sworn we already use HTTP 403 elsewhere, but I can't find anything searching for "403" or "Forbidden" in Janus sources.

I'm not concerned about this: the problem document in the body already disambiguates between the different error types, so an attacker is just as able to enumerate tasks with this change as without. (And, I'm not so worried about enumeration attacks here: the task ID space is 256 bits, so an attacker can guess task IDs via enumeration as well as they might guess an AES-256 key by enumeration. A secondary bug which effectively reduces the size of the task ID space might change things here, of course.)