When working with a customer MCP server, you may want to integrate it with an existing authorization server rather than building your own from scratch. One option is to configure Auth0 as the authorization server.
This guide walks through the steps required to set up Auth0. Since MCP is still relatively new, there are a few Auth0-specific details you’ll need to handle for everything to work smoothly.
Prerequisites
You’ll need:
A running MCP server instance protected by TLS (Claude.ai only connects to MCP servers over HTTPS)
An Auth0 account
For examples in this guide, we’ll use the placeholder domain: mymcpserver.com
Step 1: Enable OIDC Dynamic Application Registration
MCP-compatible clients like Claude dynamically register themselves as OAuth applications. Without this feature, every client would have to be pre-registered in Auth0, which isn’t practical.
Log into your Auth0 dashboard.
Go to Settings → Advanced.
Enable OIDC Dynamic Application Registration.
Step 2: Set a Default Audience
By default, Claude (like other MCP clients) includes resource as a parameter in the OAuth authorization request but does not include audience. When Auth0 doesn’t receive an audience, it issues opaque (encrypted) tokens. These are difficult to validate in an MCP server, since decryption typically requires keypairs and support that may not exist.
Setting a default audience ensures Auth0 produces a standard JWT access token that your MCP server can validate.
⚠️ Treat this as a shortcut, it is best suited for demos or non-production setups.
In the Auth0 dashboard, go to APIs
Click on + Create API
Enter a friendly name under Name (for example, “My MCP Server”)
Enter https://mymcpserver.com/ under Identifier
Click Save
Closing Notes
With this setup, you now have:
An MCP server that enforces authentication using Auth0.
Auth0 acts as both an authorization server.
Google (or another provider) is enabled for user login.
This approach lets clients like Claude.ai interact securely with your MCP server using industry-standard OAuth 2.0 flows.
FAQ
You Have Questions?
We Have Answers.
What is workload identity and access management?
Workload identity and access management (WIAM) is a security approach that assigns unique identities to workloads and manages their access to resources based on defined policies. Unlike traditional methods that rely on static credentials, WIAM uses a variety of credential types including dynamic, short-lived credentials and real-time identity verification to ensure secure, policy-driven access control. The concept of attestation means that the identity of the workload is cryptographically verified using a 3rd party attestor. Conditional access policies enable Zero Trust controls to be enforced even when the end service doesn’t directly support them.
Most IAM vendors are focused on users, while Workload IAM are for non-user identities, sometimes called non-human or machine identities.
What is a workload?
A workload refers to any non-human entity—such as AI agents, applications, services, scripts, or containers—that is accessing a service or data. A client workload (the source) will be accessing a server workload (the destination). Your application running in your Kubernetes environment is an example of a client workload. The client workloads often need to communicate with server workloads inside and outside of your network, necessitating secure authentication and authorization mechanisms. Using Stripe for payment processing and AWS S3 buckets to store and access data are examples of server workloads.
I carefully manage secrets already. Isn't that good enough?
Traditional approaches often involve hardcoded credentials, shared secrets, or static API keys, which pose significant security risks. These methods are susceptible to breaches, lack scalability, and are challenging to maintain and audit. Aembit addresses these issues by eliminating the need for stored secrets, providing dynamic credential injection, and offering centralized policy management for improved security and compliance. Aembit’s secretless approach also means a better developer experience. Developers no longer need to store, access, and code for authentication.
Can you do zero trust for workloads?
Yes. Aembit applies zero trust principles to workloads by verifying the identity of each workload when it requests access in real-time, regardless of the workload’s location. This involves cryptographic identity verification, policy-based access controls, and the use of short-lived credentials, ensuring that only authorized workloads can access specific resources. Aembit also applies MFA for workloads, just like you do for users.
When your users are accessing your data and services, you can ensure that the system is secured using corporate issued software, verify their geo-location, and that they are connecting during business hours. You can now do the same for your workloads.