kong 401

techhadoop

A 401 Unauthorized error in Kong Gateway means that the client request is missing valid authentication credentials required by Kong or the upstream service. Here’s how to troubleshoot and resolve it depending on your setup:

🔍 Common Causes & Fixes

1. No Auth Plugin Configured, but Upstream Requires Auth

  • Cause: The upstream API needs an Authorization header, but it’s not provided.
  • Fix: Either:
    • Add the required header at the client level.
    • Use Kong plugins (like JWT, Key Auth, OIDC) to inject it.

2. Auth Plugin Enabled, But Credentials Missing or Invalid

  • Check for these plugins: key-auth, jwt, openid-connect, basic-auth, etc.
  • Fix:
    • Ensure the request includes the proper header (apikey, Authorization: Bearer, etc.).
    • Example:
      • For JWT: Authorization: Bearer <token>
      • For Key-Auth: apikey: <your-api-key>
    • Confirm the credentials exist in Kong (consumer, credential objects).

3. Token Expired or Malformed

  • Fix:
    • Verify the token is active and not expired.
    • Use tools like Postman or jwt.io to inspect token validity.

4. Consumer Not Mapped Correctly

  • Fix:
    • Run curl http://<admin-host>:8001/consumers to verify the consumer is created.
    • Confirm credentials are linked to that consumer.

5. RBAC Token Error (For Admin API)

If you’re accessing the Admin API and get 401:

  • Fix:
    • Use a valid RBAC token:
      curl -H "Authorization: Bearer <admin-token>" http://localhost:8001/routes
    • Ensure the user has the required roles.

🛠️ Diagnostic Tips

Run with -v or --include to see full request/response headers:

curl -v -H "Authorization: Bearer <token>" http://<kong-host>:8000/<route>

Enable debug logging in Kong:

log_level = debug  # in kong.conf

Want to Go Deeper?

If you share:

  • The plugin you’re using (JWT, Key-Auth, OIDC, etc.)
  • A sample request
  • Kong logs or error message body
    … I can provide a more specific fix.

Let me know how you’re authenticating.

F5

Yes — a 401 Unauthorized error in Kong can be caused by F5 if it’s modifying or stripping headers that Kong needs for authentication.

🧱 How F5 Can Cause 401 Errors in Kong

🔴 1. Missing Auth Header

F5 may be removing or rewriting headers like:

  • Authorization
  • apikey
  • X-Consumer-*

Kong relies on these headers when using:

  • key-auth
  • jwt
  • basic-auth
  • openid-connect

✅ Check in F5:

  • Are Authorization headers allowed in HTTP requests?
  • Are any “security policies” or “HTTP profile” stripping headers?

🔴 2. SSL Termination at F5

If F5 is terminating TLS, Kong may receive plain HTTP but your plugin expects HTTPS (especially with OIDC or JWT).

✅ In Kong, try setting:

KONG_TRUSTED_IPS=0.0.0.0/0
KONG_REAL_IP_HEADER=X-Forwarded-For

Also set X-Forwarded-Proto and X-Forwarded-Host in F5 to preserve the request context.

🔴 3. Incorrect or Missing Host Header

Some Kong routes match based on Host. If F5 doesn’t forward it properly, Kong can reject the request.

✅ Ensure F5 passes:

Host: your-api.domain.com

🧪 How to Confirm

Run the same request directly to Kong (bypassing F5):

curl http://<Kong-IP>:8000/your-api-path \
  -H "Authorization: Bearer <token>" \
  -H "Host: your-api.domain.com"

If it works → F5 is the problem.

✅ Fixes on F5

  • Disable header stripping in HTTP profile or iRules
  • Whitelist Authorization, apikey, X-* headers
  • Preserve Host, X-Forwarded-For, X-Forwarded-Proto

✅ Fixes on Kong

  • Add KONG_TRUSTED_IPS and KONG_REAL_IP_HEADER
  • If using RBAC: make sure the token is passed in full
  • Use Kong debug logs to verify header presence

If you’d like, I can help review your F5 virtual server config or Kong route/plugin setup. Just paste what you’re using.

Leave a comment