How do you let an MCP server authenticate to Entra with OIDC/SSO while keeping every request observable and controllable?
Why the problem matters
Entra (Azure AD) is often the source of OIDC tokens for service accounts and AI‑driven workloads. An MCP server that talks to internal APIs or databases needs a token to prove its identity, but the token alone does not give you any guardrails. Without a dedicated access gateway each request goes straight to the target service, exposing credentials, bypassing approval workflows, and leaving no reliable audit trail. The result is a blind spot for security teams and a high‑risk surface for lateral movement.
What the identity layer actually provides
The first piece of the puzzle is the setup. Entra issues an OIDC token for the MCP server’s service principal. The token proves who the request is and whether the principal is allowed to start a session. This verification happens before any network traffic is sent. This step is necessary – it blocks unauthenticated actors – but it is not sufficient to enforce fine‑grained policies, mask sensitive data, or record what the server does once the connection is established.
The missing enforcement point
Even after a valid token, the request reaches the target directly. At that point there is no place to:
- Require a human approver before a dangerous command runs.
- Mask credit‑card numbers or personal identifiers that appear in responses.
- Record the full command stream for replay during an investigation.
- Block operations that violate a policy defined by your security team.
Those capabilities only appear when a data‑path component sits between the MCP server and the infrastructure it talks to.
hoop.dev as the identity‑aware gateway
Enter hoop.dev. It is a Layer 7 gateway that proxies the connection, validates the OIDC token against Entra’s JWKS, and then applies a set of guardrails before the traffic reaches the target. Because hoop.dev is the only point where the request is inspected, it can enforce every policy you need.
How it works at a high level:
- Deploy the hoop.dev gateway in the same network segment as the resources the MCP server will access. A quick‑start Docker Compose file gets you up and running in minutes.
- Register Entra as an OIDC provider in hoop.dev’s configuration. The gateway will fetch the public keys, validate signatures, and extract group membership from each token.
- Define a connection for the internal service (for example, an HTTP API or a PostgreSQL database). hoop.dev holds the credential, keeping it hidden from the MCP server.
- Set policies on the connection: require just‑in‑time approval for write operations, mask fields named ssn or credit_card, and enable session recording.
- When the MCP server initiates a request, it presents its Entra OIDC token to hoop.dev. hoop.dev validates the token, checks the policies, and then proxies the traffic to the target.
Because hoop.dev is the active component in the data path, it records each session, masks sensitive fields, blocks disallowed commands, and routes risky operations to a human approver. The MCP server never handles raw credentials, and every action is captured for audit.
Benefits of the gateway approach
- Centralized policy enforcement: All guardrails live in one place, reducing configuration drift across dozens of services.
- Audit‑ready evidence: hoop.dev’s session logs provide a replayable record that satisfies SOC 2 evidence requirements.
- Reduced blast radius: If a token is compromised, hoop.dev can instantly revoke access or require additional approval before any destructive command runs.
- Data protection at runtime: Inline masking ensures that sensitive values never leave the gateway in clear text.
Next steps
To get hands‑on, follow the getting‑started guide. It walks you through deploying the gateway, adding Entra as an OIDC provider, and creating a connection for your MCP server. The repository on GitHub contains the Docker Compose file and all configuration templates you’ll need.
All of the detailed YAML snippets, credential handling instructions, and policy‑definition syntax live in the official documentation and the source code. By following those references you can replace the ad‑hoc token handling you currently have with a strong, auditable, and policy‑driven flow.
FAQ
Do I need to modify the MCP server code?
No. The server only needs to point its client library at the hoop.dev endpoint and present the Entra OIDC token it already obtains. hoop.dev handles the rest.
How does hoop.dev validate the OIDC token?
hoop.dev fetches the JSON Web Key Set (JWKS) from Entra, verifies the token signature, checks expiration, and extracts group claims. The validation happens before any traffic is forwarded.
Where are session recordings stored?
hoop.dev writes session logs to its configured storage backend. The storage location and retention policy are defined in the gateway configuration; see the learn section for options.
Get involved
Explore the open‑source code, raise issues, or contribute new guardrails on GitHub: hoop.dev GitHub repository.
