Incorrect Client Secret Configured for oauth2-proxy

Knowledge Articles
1

Problem statement

oauth2-proxy is a reverse proxy and static file server that provides authentication using Providers (Google, GitHub, and others) to validate accounts by email, domain or group.

It is sometimes used in an Auth0 context to ‘front’ another application. A typical use-case would be where there is a requirement to host a third party application. If that application does not have any built-in support for authentication, it is desirable to add authentication and control access to the app. In this case, the proxy would work by redirecting any requests that do not have the auth cookie to a sign-in page. This would enable the enforcement of access control towards the Auth0 tenant.

However, if the proxy is not properly configured, the initial login may appear to be successful but then the requests will fail at the token exchange stage. The proxy logs may include this type of error message:

{"error": "access_denied","error_description": "Unauthorized"}

However, if the proxy is setup on a different machine, using a different IP address, everything works as expected, without any errors. What is the possible explanation for this behaviour?

Symptoms

Common symptoms are:

  • Proxy logs: may contain these types of error notices {“error”: “access_denied”,“error_description”: “Unauthorized”}
  • Tenant logs: may contain events of the type Failed Exchange ( feacft ) , ‘Failed to exchange authorization code for Access Token’
  • The errors may be associated with a specific IP address ( e.g. 172.10.1.10 ). This may lead to the suspicion that Auth0 is blocking login attempts from certain IP addresses, possibly as part of the Attack Protection feature set.
  • Setting the proxy up on a different machine (with a different IP address) will result in it working as expected (unless that new machine has been misconfigured in some way)

Steps to reproduce

  • This is difficult to reproduce exactly due to the very wide number of configuration options that are available.
  • Termination of TLS on the same machine may be achieved using a web server, such as Caddy.
  • If a working oauth2-proxy setup is available, try changing the client-secret in the configuration file and observe what error is produced.

Troubleshooting

The oauth2-proxy documentation describes the three different types of deployment options that may be used:

a) pre-built Binary or built from source code
b) pre-built Docker image
c) Kubernetes manifest (Helm)

The oauth2-proxy configuration file will look something like this:

client-id=YOUR_AUTH0_CLIENT_ID
client-secret=YOUR_AUTH0_CLIENT_SECRET
cookie-secret=YOUR_RANDOM_COOKIE_SECRET
provider=oidc
email-domain=*  # Set this to restrict logins to specific email domains if needed
redirect-url=https://your-oauth2-proxy-callback-url/callback
  • Check that these details are correct and that the match the details that are present in the configuration of the application on the Auth0 side
  • Configure logging on the proxy and inspect the log for errors. Note that this type of error is commonly associated with a client_secret mismatch between the Auth0 client application and the oauth2-proxy configuration:

{"error": "access_denied","error_description": "Unauthorized"}

  • Check the tenant logs for Failed Exchange (feacft) events that are associated with the Auth0 application that is being proxied
  • Install mitproxy on the VM that hosts the proxy and use it to capture network traffic between Auth0 and the proxy service
  • A HAR file of a login attempt may show a failure with description ‘500 Internal Server Error’, immediately after the call to the /authorize endpoint

Cause

Misconfiguration of the oauth2-proxy is a common cause of these types of errors.

Solution

Ensure that the settings in the oauth2-proxy configuration file match those those that have been configured in the Auth0 application settings for the app that is due to be proxied. Failure to do so will result in authentication failures.