# MCP Authentication > Details on the OAuth flow the Lev MCP server uses, which scopes are granted, how tokens are refreshed, and how to switch between accounts during a session. Source: https://www.lev.com/docs/build/mcp/auth Last updated: May 2026 --- ## Auth model Every tool call to the Lev MCP server is validated against an Auth0-issued RS256 JWT. When you install the server via Claude Code, Claude Desktop, or Cursor, OAuth is already wired up — you sign in once and the client handles tokens from there. ## The OAuth flow The first tool call triggers a standards-compliant OAuth 2.0 authorization-code flow. Clients discover the server's authorization metadata — you never configure it by hand. The client fetches `/.well-known/oauth-authorization-server` to learn the authorize, token, and JWKS endpoints. The client opens the browser to Auth0's hosted login page with a PKCE challenge and a redirect URI that points back at the client. After the user signs in, Auth0 redirects back to the client with an authorization code. The client trades the code for an RS256-signed access token and a refresh token. Every subsequent MCP request includes `Authorization: Bearer ` — the server validates the signature, expiry, audience, and issuer against the JWKS it discovered from Auth0. When the access token expires, the client uses the refresh token to get a new one. No user action required. You should now have a client that can call Lev MCP tools without ever prompting you for credentials again. Your MCP client handles discovery, code exchange, storage, and refresh. Do not set `Authorization` headers manually. ## Programmatic session provisioning Some trusted service integrations can provision MCP access server-side without sending a user through the interactive OAuth prompt. This flow is not part of the public API surface and is not available with standard user API keys or JWTs. Contact Lev if your integration needs server-side MCP provisioning. We will review the deployment model, account scoping, permissions, audit requirements, and key rotation plan before enabling access. ## Scopes and permissions The OAuth flow requests two scopes from Auth0: **OAuth scopes** - **openid:** Identifies the signed-in user so the server can pull the Auth0 subject claim. - **email:** Allows Lev to correlate the Auth0 identity with your Lev user record by email. The scopes above are what the **server asks Auth0 for**. What tools you can actually call depends on your **Lev account permissions**. The MCP server never elevates privileges — every call downstream to lev-backend is scoped to your live role. That means: - A `403` on a tool means your Lev user does not have access to the resource, not that the MCP server misrouted the call. - A role change in Lev takes effect on the next tool call. The server does not cache authorization decisions. To see what a given session actually has access to, call `get_my_profile`. It returns your user record, active account, available accounts, subscription status, and any platform-level scopes granted to the session. ## Headers sent to Lev Every call the MCP server makes to lev-backend carries a predictable header set. You do not need to set these — they are listed so you can spot them in traces and logs. **Upstream headers** - **Authorization: Bearer :** Forwarded from the MCP client. - **X-Origin-App: mcp:** Identifies requests as coming from the MCP server so backend analytics can segment traffic. - **X-Request-Id: :** Generated per tool call. Useful for correlating MCP activity with backend logs. - **Content-Type: application/json:** Standard on all requests. The MCP server does not pass an `X-Active-Account` header. When you call `switch_account`, the server issues a `PATCH /me/active-account` to lev-backend, which persists your active-account preference. Every subsequent request (from any client using the same credentials) is automatically scoped to that account until you switch again. ## Switching accounts Some Lev users belong to more than one account — a brokerage and a lender, for example. The MCP server supports switching between them without ending the session. How to switch Ask the client in plain language, for example: *"Switch my Lev account to Broker Magicians."* The client calls the `switch_account` tool with the name or slug, which persists your active-account preference server-side via `PATCH /me/active-account`. Subsequent tool calls scope to that account automatically. List available accounts Call `list_available_accounts` to return every account you can switch to. Use this when you are not sure of the exact slug to pass to `switch_account`. The Lev MCP server is designed to be paired with a per-user MCP client — Claude Desktop, Cursor, Claude Code, etc. Running it as a shared multi-tenant service is not supported. If you need service-to-service access, use the [REST API](/build/api-overview) with an [API key](/build/api-keys) instead. **Next:** [MCP Errors & Limits](/build/mcp/errors-limits) — error codes, rate limits, and known gaps at the tool layer.