MCP server authentication overview
Choose how the gateway authenticates to each MCP server, when users sign in again, and how servers learn who's calling
After an agent signs in to the gateway, the gateway still has to authenticate to each MCP server it calls. You choose how, per server: on behalf of each user, through your SSO, on behalf of your organization, or with an API key. This is separate from agent authentication, which proves which agent is calling.
The options
| Option | Console label | Whose access the call runs with | The person signs in to the server |
|---|---|---|---|
| On behalf of each user (OAuth) | Users sign in themselves | Each person's own account | Once, the first time they need it |
| Enterprise-managed | Enterprise-managed | Each person's own account, through SSO | Never |
| On behalf of your organization (OAuth) | OAuth app | One app account that everyone shares | Never |
| API key | API key | One key that everyone shares | Never |
| No authentication | No authentication | No account | Never |
Pick the option when you add a custom server. A catalog server comes set up: most authenticate on behalf of each user, and a few public ones, such as Microsoft Learn, need no authentication.
With an option everyone shares, the server sees one account for everyone. Your rules still decide each call per person before it's sent, and Agent Trail still records who called.
On behalf of each user (OAuth)
The first time a person's agent calls a server they haven't connected, the gateway replies with a link, and they sign in once. After that the gateway calls the server with their own token, so they reach only what their account can. See Connections.
- Tokens refresh on their own. The gateway renews expiring tokens in the background, so a working connection keeps working.
- A revoked connection asks again. When the service cancels access, the next call returns the sign-in link.
Choose whose OAuth app starts the sign-in
Each person signs in through an OAuth app registered with the service. You choose whose app it is:
| Whose app | On a catalog server | On a custom server |
|---|---|---|
| SecureAuth's | Use SecureAuth's app | Not available |
| Registered for your org | Per-org dynamic registration | Register automatically |
| Your own | Bring your own app | Use your own app |
On a catalog server this choice is called the credential mode, and it's fixed once you install the server. See Credential modes.
Make people sign in again
For a sensitive server, you can make people sign in to it again, independently of their SSO session. On the server's Settings tab, set:
- Maximum age – expire the connection this long after the person connected, however often they use it.
- Idle timeout – expire it this long after their last call to that server.
When a connection expires, the next call returns the sign-in link. Reset deletes the stored tokens for the server, so the gateway gets new ones on the next call. See Connection lifetime.
Enterprise-managed
The gateway uses each person's SecureAuth Connect sign-in to get a token for the server, so people never see a sign-in link and still reach the server with their own account. It follows the MCP enterprise-managed authorization extension, built on the IETF ID-JAG draft. The server has to trust your SecureAuth Connect workspace and support the extension, and SecureAuth turns it on for your organization.
Maximum age, idle timeout and Reset delete only the gateway's copy of the token, so the next call quietly gets a new one through SSO. See Enterprise-managed authorization.
On behalf of your organization (OAuth)
The gateway signs in as its own OAuth app with client credentials, and every person's calls reach the server as that one app account. Enter the app's client ID, secret and scopes, and an issuer URL or token URL. Use it for a server whose data everyone may see, or that has no per-user accounts.
API key
The gateway sends the headers you set, such as an API key, with every request, and every person's calls reach the server as that key. The headers sit inside Authentication, because they carry the key. Use it for a server that offers only API keys.
No authentication
The gateway sends no credentials. Use it for a public server, or an internal one that trusts the network it runs on. To tell such a server who's calling, send user identity.
Tell an internal server who's calling
A server you run yourself often needs to know the person behind a call, to scope results or log the caller.
Switch on Send user identity on a custom server's Settings tab, and each call carries a signed token in the X-SecureAuth-Jwt-Assertion header:
- A JSON Web Token signed with ES256, valid for 5 minutes, with the person's ID, email, name and groups.
- Your server checks it against your workspace's public keys, so it can trust the identity without a separate login.
- If your server can't check a token, you can also send plain, unsigned headers.
The gateway sends identity only when a person calls through an agent, and only to an https server.
See User identity assertion for the claims and verification code, and User identity headers for the plain headers.
Custom servers can also take request headers, such as a tenant ID or a routing key. The gateway sends them with every call to the server, never to the OAuth endpoints. See Propagate request headers.
Next steps
You can now choose how the gateway authenticates to each MCP server, when people sign in again, and how an internal server learns who's calling. Next, set it on the server.
- Custom MCP server – authentication, headers and user identity settings
- Connections – what people see when they connect, and connection statuses