request authorization with grpc (failure status code)

bmacphee nginx-forum at
Tue Jul 2 15:19:54 UTC 2019

I have an nginx configuration that passes gRPC API requests to other
services an authorization endpoint that is used in conjunction.

This works great when authorization is successful (my HTTP1 authorization
endpoint returns HTTP 2xx status codes).

When authorization fails (it returns 401), the gRPC connection initiated by
the client receives a gRPC Cancelled(1) status code, rather than what would
be ideal for the client - an Unauthorized (16) status code.  The status
message appears to be populated by nginx indicating the 401 failure.

Is there a way to control the status code returned to the gRPC channel
during failed auth?

I tried and failed at doing this with the below configuration.  Any non-200
code returned by the auth failure handling results in the same cancelled
status code even after trying to set the status code manually.  If I
override the return with a 200 series code, it treats authorization as
successful (which it also bad).

server {
  location /some_grpc_api {

    grpc_pass grpc://internal_service:50051;
    grpc_set_header x-grpc-user $auth_resp_x_grpc_user;

  # send all requests to the `/validate` endpoint for authorization
  auth_request /validate;
  auth_request_set $auth_resp_x_grpc_user $upstream_http_x_grpc_user;

  location = /validate {
    proxy_pass http://auth:5000;

    # the auth service acts only on the request headers
    proxy_pass_request_body off;
    proxy_set_header Content-Length "";
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    # attempt to customize grpc error code
    proxy_intercept_errors on;
    error_page 401 /grpc_auth_fail_page;

  # attempt to customize grpc error code
  location = /grpc_auth_fail_page {
    grpc_set_header grpc-status 16;
    grpc_set_header grpc-message "Unauthorized";
    return 401;

Posted at Nginx Forum:,284718,284718#msg-284718

More information about the nginx mailing list