Skip to main content
Okta works with Runtime and MCP in two directions:

​
Sign in to the Runtime MCP with Okta

When a client connects to https://mcp.runtm.com/mcp, people sign in on Runtime’s login page. If your org has single sign-on with Okta, they click Continue with SSO, sign in through Okta, choose the workspace and allow access. Their connected app gets their Runtime role in that org, and no more.
1

Connect Okta to Runtime

An owner or admin adds Okta (OIDC) in Settings → Team → Single sign-on and verifies the email domain. See Single sign-on.
2

Connect the client

Each person adds https://mcp.runtm.com/mcp to their client (quick start) and picks Continue with SSO when the browser opens.

​
Connect an Okta-protected MCP server

Many internal MCP servers sit behind Okta. Okta doesn’t let apps register themselves, so Sign in with OAuth on such a server shows This server needs an OAuth app first. An org admin sets the app up once, and then everyone in the org signs in with their own Okta account.

​
Before you start

  • You’re an owner or admin of the Runtime org.
  • The MCP server is already added in Settings → Context → Tools & MCP. See Give it tools.
  • You can create app integrations in Okta, and you know which authorization server the MCP server trusts.
1

Open the OAuth app setup

In Runtime, open the MCP server and click Set up OAuth app. Choose Okta. Copy the Redirect URI shown in the dialog.
2

Create the app in Okta

In the Okta admin console, create an OIDC app integration of type Web Application, with the Authorization Code and Refresh Token grant types. Paste the redirect URI as a Sign-in redirect URI. Assign the people or groups who should connect.
3

Fill in the Okta preset

The issuer becomes https://<okta domain>/oauth2/<authorization server ID>. Use a custom authorization server: leaving the ID empty uses Okta’s org authorization server, whose tokens other servers can’t validate.
4

Save and sign in

Click Save. Runtime reads the issuer’s OAuth metadata and checks it matches before saving. Then click Sign in with OAuth on the MCP server and sign in through Okta.
5

Attach and rebuild

Attach the MCP server to the agent’s template and rebuild. At each session start, Runtime refreshes the token and passes it to the server.

​
Good to know

  • Keep offline_access. Okta only issues a refresh token when it’s requested. Without it, connections stop working when the access token expires.
  • One app per server URL. The app applies to every MCP server in the org with the same URL. Each connection still authorizes as the person who signs in.
  • The secret stays in Runtime. Members can see the issuer, client ID and scopes, never the secret. Only admins can change or remove the app.
  • Edit without retyping the secret. Leave Client secret blank to keep the stored one.
  • Removing the app sends sign-in back to automatic registration, and existing connections show an error on their next refresh.
  • Other providers. Choose Custom OAuth app and enter the issuer URL. It must use https.
  • Members can’t sign in to OAuth MCP servers yet. Today, only admins can create OAuth connections, and personal MCP servers can’t use OAuth.

​
If sign-in fails