Invalid OAuth2 challenge-response authentication implementation

[CyExy]

Kong OAuth2 plugin doesn't follow standards specified in

• rfc2616 – HTTP/1.1
• rfc2617 – HTTP Authentication and
• rfc6750 – The OAuth 2.0 Authorization Framework: Bearer Token Usage.

The current OAuth2 plugin responses are forcing clients to implement hacks, and/or incorrect implementations for handling authentication challenges. This is especially problematic when using a generic client implementations that handle OAuth2 authentication challenges for services behind kong gateway.

Response to a request if it lacks any authentication information

Currently kong response is 403 Forbidden

The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated.
rfc2616#section-10.4.4

This response is misleading. It doesn't even contradict the 403 by having any other why of telling the client that the endpoint requires user authentication e.g. WWW-Authenticate. If the client was unaware that authentication is necessary it may interpret the response as an application error and think that the request was otherwise legal.

Correct response would be 401 Unauthorized with WWW-Authenticate: Bearer realm="example" header

The request requires user authentication. The response MUST include a
WWW-Authenticate header field ... The client MAY repeat the
request with a suitable Authorization header field
rfc2616#section-10.4.2

Response to a request with Authorization header containing the access token that is expired, revoked, malformed, or invalid for other reasons

Kong's response to expired token the is 400 Bad Request:

The request could not be understood by the server due to malformed
syntax. The client SHOULD NOT repeat the request without
modifications.
rfc2616#section-10.4.1

and in case of an invalid token it is 403 Forbidden. Both responses do not follow the standards.

rfc2617#section-1.2 gives a very clear description on how the server should respond in this case.

If the origin server does not wish to accept the credentials sent
with a request, it SHOULD return a 401 (Unauthorized) response. The
response MUST include a WWW-Authenticate header field containing at
least one (possibly new) challenge applicable to the requested
resource.

In addition rfc6750#section-3.1 clearifies the error codes and specifies appropriate HTTP status codes.

Correct response would again be in both cases 401 Unauthorized with WWW-Authenticate: Bearer realm="example", error="invalid_token", error_description="The access token expired/The access token invalid/etc"

PR

I'm willing work on a PR to fix the issues mentioned above to make the OAuth2 plugin follow the standards. I'm aware that changing the implementation without maintaining backward compatible could be an issue, but trying to maintain BC can be very painful and unnecessarily bloat the code.

Please let me know what you think and then lets take it from there.

[subnetmarco]

Hi @CyExy, thanks for the precious feedback. I can start working on this, but if you would like to push a PR that would certainly help.

trying to maintain BC can be very painful and unnecessarily bloat the code.

I agree.