Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-33069

remove requirement to use 401 only where authentication failed from capabiltystatement

    XMLWordPrintableJSON

Details

    • Change Request
    • Status: Published (View Workflow)
    • Medium
    • Resolution: Persuasive with Modification
    • US Core (FHIR)
    • 4.0.0
    • Cross-Group Projects
    • US Core Server CapabilityStatement
    • Capability Statements
    • Hide

      change:

      A server SHALL reject any unauthorized requests by returning an HTTP 401 unauthorized response code.

      to:

      A server SHALL reject any unauthorized requests by returning an HTTP 401 "Unauthorized", HTTP 403 "Forbidden", or HTTP 404 "Not Found" .

      Show
      change: A server SHALL reject any unauthorized requests by returning an HTTP 401 unauthorized response code. to: A server SHALL reject any unauthorized requests by returning an HTTP 401 "Unauthorized", HTTP 403  "Forbidden", or HTTP 404 "Not Found" .
    • Brett Marquard/Floyd Eisenberg: 12-0-3
    • Clarification
    • Compatible, substantive

    Description

      Christopher Marchand: This was my comment:

      On our FHIR Server, when an authenticated patient (eg. John Smith) requests a FHIR resource for another patient (eg. Doug Doe), our FHIR Server returns a 404 (Not Found) error. We have been asked to return a 401 (Unauthorized) error in these situations based on language in the US Core Specification here: https://www.hl7.org/fhir/us/core/CapabilityStatement-us-core-server.html#behavior), which explicitly states:
      ○ A server SHALL reject any unauthorized requests by returning an HTTP 401 unauthorized response code.

      The US Core IG section that is referenced has three statements about this:

      The first says “The US Core Server SHALL: 5) Return the following response classes … (Status 401/4xx): unauthorized request”. Here it clearly states that for unauthorized requests, you return a class of 401/4xx.

      The second says “See the General Security Considerations ( https://www.hl7.org/fhir/us/core/security.html) section for requirements and recommendations”, which references FHIR R4 specification.
      § The most relevant section that goes into the most detail is http://hl7.org/fhir/R4/security.html#AccessDenied

      The third is the very strange statement that then says that you should reject any unauthorized requests by returning a 401.

      It is the Access Denied Response Handling that we follow, because of concerns around data leakage. When you return a 401, you are telling the requester that the other resource actually exists. You can, for example, use it to discover information about another patient – whether they exist, whether they have other resources (eg. query for a lab result with HIV status). It is NEVER a good idea to let an unauthorized user know about resources. The FHIR R4 guide is explicit and recommends a 404 because it protects from data leakage. It recommends 401 only in the case where authentication failed, not authorization.

      Taken in its entirety, it’s our interpretation that the US Core IG mixes the use of the words “authorization” and “authentication”. When it uses the word “unauthorized”, it means to include both authentication and authorization. That is abundantly clear in the first statement. This interpretation makes sense out of the conflicting statements within the same paragraph.

      It is our position that returning a 401 instead of 404 reduces the security posture of ANY server in this situation (as the FHIR Security Recommendations indicate as well), and we highly discourage the use of 401 in this use case.

      Christopher Marchand: https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Data.20Leakage.20and.20US.20Core.20Error.20Guidance

      Attachments

        Activity

          People

            ehaas Eric Haas
            ehaas Eric Haas
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: