Missing response body for 401 response in resource server

[ofir-popowski]

When trying to access any protected endpoint without including an access token in the header, the response code is 401 (which is expected), but there's no response body, unlike older OAuth2 resource server.

The older versions of OAuth2 using @EnableResourceServer used to return 401 with the following body:

{
    "error": "unauthorized",
    "error_description": "Full authentication is required to access this resource"
}

Now it just returns an empty string.

This is easily testable when adding the following test to OAuth2ResourceServerApplicationITests.java

@Test
public void performWithoutTokenThenUnauthorized()
        throws Exception {

    this.mvc.perform(get("/"))
            .andExpect(status().isUnauthorized())
            .andExpect(content().string(containsString("")));
}

Using version 5.1.1.RELEASE like so:

<dependency>
    <groupId>org.springframework.security</groupId>
    <artifactId>spring-security-oauth2-resource-server</artifactId>
    <version>5.1.1.RELEASE</version>
</dependency>

[jgrandja]

@ofir-popowski Thanks for the report. As defined in OAuth 2.0 Authorization Framework: Bearer Token Usage:

If the protected resource request does not include authentication
credentials or does not contain an access token that enables access
to the protected resource, the resource server MUST include the HTTP
"WWW-Authenticate" response header field

The expected behaviour is to return the WWW-Authenticate response header and not a response body. Can you please confirm the WWW-Authenticate response header is returned?

[ofir-popowski]

@jgrandja Both the previous and the new one return a WWW-Authenticate response header, but a bit differently:
old version: WWW-Authenticate: Bearer realm="oauth2-resource", error="unauthorized", error_description="Full authentication is required to access this resource"
new version: WWW-Authenticate: Bearer

edit: I'd like to point out that if token is expired, the header provides detailed explanation:
WWW-Authenticate: Bearer error="invalid_token", error_description="An error occurred while attempting to decode the Jwt: Jwt expired at 2018-10-17T13:39:36Z", error_uri="https://tools.ietf.org/html/rfc6750#section-3.1"

It would be nice to have a more descriptive header in case token is missing, like expired token one

[jgrandja]

@ofir-popowski

It would be nice to have a more descriptive header in case token is missing

I think this makes sense. @jzheaux What are your thoughts?

[jzheaux]

@ofir-popowski Good observation. Here are two things that may help:

First, you may already know that you can customize this behavior in the DSL by wiring your own AuthenticationEntryPoint. The existing one only adds error details if they are provided in the accompanying exception, but an implementation that has some kind of default error message wouldn't be tricky.

This is the same answer for the body. If a body is helpful in your situation, then you can wire your own custom AuthenticationEntryPoint, delegating to BearerTokenAuthenticationEntryPoint for the header, with your implementation adding a body.

Second, the spec, as I read it, disallows a default error message:

If the request lacks any authentication information (e.g., the client
was unaware that authentication is necessary or attempted using an
unsupported authentication method), the resource server SHOULD NOT
include an error code or other error information.

For example:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"

However, I think that error handling is something pretty nuanced, and so the goal is to make sure that you have the right hooks to be able to deviate from the spec, should the need arise.

One piece of boilerplate that we could probably remove is the actual formatting of the error message. Right now, potential support for that is encased in a private method and it might helpful to extract that.

[sepanniemi]

My observation is that currently authentication endpoint is not customizable, because web filter is initialized with a hard coded endpoint object in the jwt spec in resource server security config. Setting a custom authorization endpoint via exceptionHandling of ServerHttpSecurity does not have the desired result due to that.

https://github.com/spring-projects/spring-security/blob/master/config/src/main/java/org/springframework/security/config/web/server/ServerHttpSecurity.java#L884

https://github.com/spring-projects/spring-security/blob/master/config/src/main/java/org/springframework/security/config/web/server/ServerHttpSecurity.java#L988

Or am I missing something? I would also need this customization, because we would like to avoid breaking changes due to changes in error responses in our APIs when migrating to a new version of Spring Boot.

[jzheaux]

@sepanniemi The file you are linking to is for Spring Security WebFlux. You are correct that the error handling in WebFlux Resource Server is not yet customizable. However, it should work fine with servlet-based Spring Security.

Though, now that you mention it, I've created a task to close that gap.

[sepanniemi]

Yes, I have been doing with WebFlux myself and didn't notice this was servlet based issue. Thanks for creating the task.

[ofir-popowski]

Thank you very much for your detailed answer @jzheaux :). Seeing as that was specified by the spec, I will avoid trying to customize that header myself

[jzheaux]

Good deal, @ofir-popowski. Since it looks like we are on the same page now, I'll go ahead and close this.

[bcalmac]

@jzheaux

Second, the spec, as I read it, disallows a default error message:

If the request lacks any authentication information (e.g., the client
was unaware that authentication is necessary or attempted using an
unsupported authentication method), the resource server SHOULD NOT
include an error code or other error information.
For example:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"

I don't think the spec you referenced talks about the response body, it specifies when one of the (invalid_request, invalid_token, insufficient_scope) error codes should be included in the WWW-Authenticate response header. Then it wraps up by saying that when the request lacks any authentication information then none of those 3 error codes should be included in the WWW-Authenticate header and provides the following example:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example" 

Indeed, this is different than the previous example where an error code was included:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example",
                       error="invalid_token",
                       error_description="The access token expired"

Here is the full text for context:

[3.1](https://datatracker.ietf.org/doc/html/rfc6750#section-3.1).  Error Codes

   When a request fails, the resource server responds using the
   appropriate HTTP status code (typically, 400, 401, 403, or 405) and
   includes one of the following error codes in the response:

   invalid_request
         The request is missing a required parameter, includes an
         unsupported parameter or parameter value, repeats the same
         parameter, uses more than one method for including an access
         token, or is otherwise malformed.  The resource server SHOULD
         respond with the HTTP 400 (Bad Request) status code.

   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.

   insufficient_scope
         The request requires higher privileges than provided by the
         access token.  The resource server SHOULD respond with the HTTP
         403 (Forbidden) status code and MAY include the "scope"
         attribute with the scope necessary to access the protected
         resource.

   If the request lacks any authentication information (e.g., the client
   was unaware that authentication is necessary or attempted using an
   unsupported authentication method), the resource server SHOULD NOT
   include an error code or other error information.

   For example:

     HTTP/1.1 401 Unauthorized
     WWW-Authenticate: Bearer realm="example"

I think it makes 100% sense for the response body to match the standard spring-boot error response JSON. The OAuth2 RFC mentions nothing about the error response body, this is up to the implementation. Also, think about it in terms of consistency. How would a client be able to process errors if different conditions result in wildly different error response bodies? Sure, it's possible to have different responses for each HTTP error status, but I would submit to you that it doesn't make a for good design.