Add WWW-Authenticate header for 401 and 403 requests

[jimmyjames]

Changes

As raised in #47, the WWW-Authenticate headers should be sent on the response when the request is rejected due to a missing or invalid access token. This is specified by RFC 6750.

Scenarios

• Requests to a resource that require authorization that are rejected with a 401 due to an invalid or missing access token will have a WWW-Authenticate header included on the response.
• Requests to a resource that are rejected with a 403 due to insufficient scopes will have a WWW-Authenticate header included on the response.

WWW-Authenticate header value

RFC 6750 does not require any specific attributes of the WWW-Authenticate header to be set. This PR simply includes an error attribute, with the following values:

• "Invalid token" for a 401 resulting from a missing or invalid access token
• "Insufficient scope" for a 403 resulting from a token with insufficient scopes

A couple notes on what could be added in the future, but is not included here as this change is focused on complying with RFC 6750 and enables future changes to the header attributes:

• In the case of 401 errors, we could unwrap the AuthenticationException and use the underlying exception cause to return a more specific error (e.g., invalid signature, expired token, etc).
• In the case of 403 errors, we might be able to included the required scopes for the resource, as was added to express-jwt-authz. That would require some more thought, since we'd need to be able to hook into the required scopes as configured by the application developer.
• We could include attributes such as the realm or authorization_uri, if those prove to be useful for callers.

Again, those possible additions are not included in this PR for the purposes of simplicity and compliance, but we can consider them going forward.

References

• RFC 6750
• Unauthorized and Forbidden responses should set WWW-Authenticate header #50
• Add WWW-Authenticate header. #47

Testing

Please describe how this can be tested by reviewers. Be specific about anything not tested and reasons why. If this library has unit and/or integration testing, tests should be added for new functionality and existing tests should complete without errors.

• This change adds unit test coverage
• This change adds integration test coverage
• This change has been tested on the latest version of the platform/language or why not

Checklist

• I have read the Auth0 general contribution guidelines
• I have read the Auth0 Code of Conduct
• All existing and new tests complete without errors

[jimmyjames]

AccessDeniedHandler specifies that handle must be public, which is why the class as package-private but the method as public

[jimmyjames]

Codecov checks failing because of the lack of coverage around the configure() method of JwtWebSecurityConfigurer. There's not a great way to test this, as HttpSecurity is final (can't be mocked) and would probably require a spring integration test, which would require some type of controller under test.