Stream: argonaut
Topic: HTTP code 401
Yunwei Wang (Feb 27 2020 at 21:03):
US Core 7.1.1.1. The first section says
...Return the following response classes: ...(Status 401/4xx): unauthorized request.
The following security says
A server SHALL reject any unauthorized requests by returning an HTTP 401 unauthorized response code.
So what does 4xx codes mean where it first mentioned? And second question, if server returns 4xx for unauthorized request, is it valid or not?
@Eric Haas @Brett Marquard
Eric Haas (Feb 27 2020 at 21:12):
can you make a tracker. should only be 401
John Moehrke (Feb 27 2020 at 22:00):
You should NOT force 401. See http://build.fhir.org/security.html#AccessDenied
John Moehrke (Feb 27 2020 at 22:01):
by forcing 401 you enable an attacker to determine what exists vs what does not exist. Servers should have the ability to implement policy on what they do with access control failures
Josh Mandel (Feb 27 2020 at 22:41):
by forcing 401 you enable an attacker to determine what exists
I'm not arguing we should specify any more than we already have -- but if we did require the use of 401 for requests that lacked an Authorization header this would not enable an attacker to determine what exists vs what does not exist. The 401 would be used for all paths if an access token was omitted (based on the request, not based on what data existed in a server).
John Moehrke (Feb 27 2020 at 22:43):
I didn't understand it was specific to that exchange only. as you can imagine I get many people going from one specific to a general rule too quickly without considering the ramifications.
Yunwei Wang (Feb 27 2020 at 23:56):
There are three scenarios: 1) the client sends request with valid token, 2) the client sends request with invalid token, 3) the client sends request without a token. Both case 2) and 3) shall end with Access Denied. My question is what is the correct response code for these two situation. I used to think 401 SHALL be the correct code for both 2) and 3) till I recently found some servers send 400. So I started to look around but could not find any concrete answer.
Yunwei Wang (Feb 28 2020 at 00:02):
@John Moehrke I looked at http://build.fhir.org/security.html#AccessDenied. My understanding for that section is that the code SHALL be 401 "This communicates that user authentication was attempted and failed to be authenticated."
And what does this mean "by forcing 401 you enable an attacker to determine what exists vs what does not exist"?
Thanks
John Moehrke (Feb 28 2020 at 13:34):
to explain that, let me ask what you would return if the request situation was the same, but there was no data that matched the query parameters? Most will answer that should either be 200 that is empty, or a 404 not found. Well now I can tell if there is data that exists (does match my query parameter) but for which I don't have access rights to. I don't need access rights, I will just probe around with these query parameters until I can tell what the data is NOT, which tells me what the data is.
John Moehrke (Feb 28 2020 at 13:35):
so, the recommendation from many security professionals, we just quote them on the FHIR core security page, is that policy should choose what to return. When the data are very sensitive it can be best to return 200 with an empty bundle.
John Moehrke (Feb 28 2020 at 13:48):
There are cases, like what Josh indicated, where a specific error code is not going to lead to exposing data. Josh case is where a token is completely missing.
John Moehrke (Feb 28 2020 at 13:50):
I am not against having recommended codes for access control failure. What I am against is SHALL language. The reason I am against that is that it forbids a service from imposing policy. It can also lead a client to believe that that error code is the only failure-mode, and thus the client is fragile to servers imposing a different policy. -- so what I am asking for is to recognize that hackers are creative, and the data you are protecting is valuable. Think about Security Considerations, not just happy path.
Jenni Syed (Feb 28 2020 at 18:58):
The OAuth 2 specification actually defines a lot about the errors: https://tools.ietf.org/html/rfc6750#section-3.1
Jenni Syed (Feb 28 2020 at 18:58):
(this is the bearer token extension, which is the type of token SMART uses)
Jenni Syed (Feb 28 2020 at 19:01):
So 400, 401, 403 specifically called out for different types of errors
Jenni Syed (Feb 28 2020 at 19:02):
And if they're nice, hopefully the error code as well :)
Josh Mandel (Mar 02 2020 at 20:09):
Yeah, we talked through these -- but looked like only the header details are defined at a "SHALL" (MUST) level, and specific response codes were "SHOULD"s.
Last updated: Apr 12 2022 at 19:14 UTC
