FHIR Chat · HTTP error code for file request

Stream: bulk data

Topic: HTTP error code for file request

Yunwei Wang (Feb 27 2020 at 19:58):

In File Request, "If the requiresAccessToken field in the Complete Status body is set to true, the request SHALL include a valid access token." So if client does NOT include bearer token, or include an invalid token, should the error code be 400 (bad request) or 401(unauthorized)?
@Josh Mandel @Dan Gottlieb

Dan Gottlieb (Feb 27 2020 at 20:09):

Hmm, since it's a token related error, any reason it shouldn't be a 401?

Yunwei Wang (Feb 27 2020 at 20:12):

I think it should be 401 but I could not find anywhere (bulk-data, FHIR, OAuth, etc) says that it MUST/SHALL be 401.

Isaac Vetter (Feb 27 2020 at 20:13):

Yunwei - does HTTP say that it should be 401?

Josh Mandel (Feb 27 2020 at 20:15):

(Answered over at #implementers > HTTP code 400 or 401 as well as I could.)

Josh Mandel (Feb 27 2020 at 20:17):

I think if you control this server, then a 401 is probably a good way to communicate it -- but of course if requiresAccessToken is false, we're typically talking about a non-FHIR file server.

Josh Mandel (Feb 27 2020 at 20:19):

But when requiresAccessToken is true, the one strong thing we can say is that the error response must have a WWW-Authenticate header. That's from https://tools.ietf.org/html/rfc6750#section-3, which holds for any OAuth 2.0 bearer token-protected server.

Yunwei Wang (Feb 27 2020 at 20:22):

For a client, if it does NOT send bearer token, then it could get either 400 (less common), or 401 (more common). If the client sends invalid token, then it shall get 401. Is that understanding correct?

Josh Mandel (Feb 27 2020 at 20:24):

With an invalid token, the use of a 401 status is a SHOULD. See https://tools.ietf.org/html/rfc6750#section-3.1 which says:

   invalid_token
         The access token provided is expired, revoked, malformed, or
         invalid for other reasons.  The resource SHOULD respond with
         the HTTP 401 (Unauthorized) status code.  The client MAY
         request a new access token and retry the protected resource
         request.