throwing AuthenticationError should set the response status to 401 Unauthorized

[dandv]

apollo-server correctly returns a a "400 (Bad request)" error if the query fails to validate, but if the code throws an AuthenticationError per the docs, the status remains 200.

https://launchpad.graphql.com/z5n9190vz7

[ruipaulo]

I have the same issue, but slightly different. I am using apollo-server-lambda and it returns status code 400 on throwing AuthenticationError. Instead, it should return 401.

[JakeDawkins]

@dandv thanks for opening this! How are you wanting to use the 401, specifically? Why wouldn't the errors extension be enough?

From a design perspective, I have a couple thoughts. Since AuthenticationErrors can be thrown at any level, within any resolver, it wouldn't be great to have the whole operation scrapped for a single field's sake. It would remove the ability for partially-valid operations.

Also, if we changed the status for AuthorizationErrors, I'd imagine we'd need to change codes for any other kinds of error as well.

[dandv]

How are you wanting to use the 401, specifically? Why wouldn't the errors extension be enough?

One use case is that some 3rd party GraphQL clients are tripped by the 200 OK and don't look in the response object for an errors property.

Also, if we changed the status for AuthorizationErrors, I'd imagine we'd need to change codes for any other kinds of error as well.

Agree. This would bring apollo-server in line with standard HTTP error codes returned by REST APIs.

it wouldn't be great to have the whole operation scrapped for a single field's sake. It would remove the ability for partially-valid operations

I haven't run into that use case yet, but for the more typical use case where an operation needs to be entirely denied if unauthenticated or unauthorized, I think the dev should have the option to throw a genuine (401/403) auth* error. For partial validations, perhaps pass a flag somehow, or don't throw but return an error property?

[abelsoares]

@JakeDawkins, what's the rational behind HTTP status codes in apollo-server?

Is it that errors thrown at a point (include execution) where partial responses (data field may be available) are possible should return status code 200? And errors that make impossible to have partial responses (before execution) should generate an HTTP error status code?

If that's the rational, i think it's ok and makes sense that AuthenticationErrors have a 200 status code.

By the way, any reason why the response when a query validation fails is in this form:

{
  "error": {
    "errors": [...]
  }
}

Shouldn't be:

{
    "errors": [...]
}

?

[MrLoh]

@JakeDawkins So in our case, we switched to using error extension codes, and I agree that apollo shouldn't generally handle all kinds if response codes. However our legacy app versions, still depend on a 401 being returned.

I think one valid improvement would be to at least return 401, where 400 is currently returned, when the context creation fails, since this is where global authentication logic lives, and it already returns 400, so apollo might as well return 401, if it knows that a authentication error occurred from the extension code.

apollo-server/packages/apollo-server-core/src/runHttpQuery.ts

Lines 126 to 142 in 34322a6

	if (typeof options.context === 'function') {
	try {
	(options.context as () => never)();
	} catch (e) {
	e.message = `Context creation failed: ${e.message}`;
	// For errors that are not internal, such as authentication, we
	// should provide a 400 response
	if (
	e.extensions &&
	e.extensions.code &&
	e.extensions.code !== 'INTERNAL_SERVER_ERROR'
	) {
	return throwHttpGraphQLError(400, [e], options);
	} else {
	return throwHttpGraphQLError(500, [e], options);
	}
	}

I created PR #2093, to give an idea, how this could work. It's not ready to merge, but I could provide tests etc., if this is something you would consider.

[pragone]

Thanks @MrLoh. I think your fix was what was needed. Saw thought that you didn't finish it up, so I took the baton and finished it up in PR #2269
Please review, I've added tests, signed the contributor agreement, yada, yada, yada....

[danilobuerger]

I don't think this is a great idea. As outlined by @JakeDawkins:

From a design perspective, I have a couple thoughts. Since AuthenticationErrors can be thrown at any level, within any resolver, it wouldn't be great to have the whole operation scrapped for a single field's sake. It would remove the ability for partially-valid operations.

If I request multiple fields and just one leads to an authentication error, it would be better to return the partial results instead of erroring the whole thing. This is in line with the GraphQL spec:

A response may contain both a partial response as well as encountered errors in the case that a field error occurred on a field which was replaced with null.

As per RFC 7235

The 401 (Unauthorized) status code indicates that the request has not
been applied because it lacks valid authentication credentials for
the target resource.

But it has been applied, just partially. So returning a 401 would be non-RFC compliant.

[pragone]

Hi @danilobuerger ... I get your point.
I agree that GraphQL is meant to return partial answers and errors as you indicate, what @MrLoh proposed though is a bit different, because it's not about returning 401 on any occasion that an AuthenticationError is thrown, but specifically in the case that it's thrown in the creation of the context. This is a per-request action, and throwing an error there, which is shown as an example in the documentation should deny access to the whole API... therefore I think a 401 is appropriate and would make it more compatible

Actually, this was a separate issue #2093. And in this issue, the problem was specific to just throwing an authentication error during context creation.
It seems to me that perhaps merging the two issues was a mistake. Perhaps #2093 should be re-opened and my PR would focus on fixing that issue, and this issue should be closed indicating that an AuthenticationError thrown anywhere that is not the context creation is not to return a 401.

Makes sense?

[pragone]

Sorry... it wasn't a separate issue... it was just a separate PR... I'll create a separate issue because I think that limiting the scope of the change is the right way to go about it.

[pragone]

Ok... I've created #2275 to reflect the reduced scope. I'd suggest this one is closed as it seems it shouldn't be accepted.

[MrLoh]

Exactly. This just throws a 401 where GraphQL already doesn’t return any data but just a 400