How to set up single sign-on (SAML or OIDC) for Runtime

An owner connects your identity provider on the Single sign-on page, proves the email domain with a DNS TXT record, and picks a role.

On Runtime single sign-on and SCIM directory sync are free on every account, not an enterprise add-on. Okta, Microsoft Entra ID and Google Workspace work from day one, and any SAML 2.0 or OpenID Connect provider works the same way. Deactivate someone in your directory and they lose access, with every key they made revoked, in the same step (checked 25 September 2026, single sign-on).

The three steps

Create an app in your identity provider. On Runtime's Single sign-on page, choose Connect your identity provider, pick your provider, choose SAML or OIDC and enter your email domain. The page shows the values to paste into your provider before you save anything.
Prove the domain. Add the TXT record the page shows, then choose Check DNS.
Choose who joins and how. Set the default role (developer unless you change it), and optionally tick Require single sign-on.

Only an owner changes single sign-on, and only on the website. No API key can.

What to paste into your provider (SAML)

Provider	Where to create it	Runtime value it needs
Okta	Applications > Create App Integration > SAML 2.0	Single sign-on URL (ACS), audience URI; Name ID EmailAddress
Microsoft Entra	Enterprise applications > New application > Create your own	Identifier (Entity ID) = audience URI; Reply URL = single sign-on URL
Google Workspace	Apps > Web and mobile apps > Add app > Add custom SAML app	ACS URL = single sign-on URL; Entity ID = audience URI; Name ID = primary email

Then give Runtime your provider's side: Okta's Metadata URL, Entra's App Federation Metadata Url, or Google's SSO URL, Entity ID and certificate (or its IdP metadata). Keep assertions signed; that is each provider's default.

Or use OIDC

Choose OIDC, give your provider the page's sign-in redirect URI, and enter the issuer URL, client ID and client secret. Runtime reads the discovery document for the rest, asks for openid, email and profile, and uses PKCE.

Provider	Issuer URL
Okta	`https://<your-company>.okta.com`
Microsoft Entra	`https://login.microsoftonline.com/<tenant-id>/v2.0`
Google Workspace	`https://accounts.google.com`

For Entra, add the email optional claim to the ID token. The client secret is shown once and never again; leave the field empty when you edit other settings and Runtime keeps it.

Prove the domain

Type	Name	Value
TXT	`_runtime-verify.company.com`	`runtime-verify=<token>`

A new record can take a few minutes to show. Once verified, the domain stays verified even if you delete the record. Only one Runtime account can hold a proven domain, so nobody else can sign in people from yours.

Add SCIM so your directory manages people

On the Single sign-on page, choose Make a SCIM token and copy it; it is shown once.
In your provider, turn on provisioning with base URL https://withruntime.com/scim/v2, a bearer token (the SCIM token) and userName (the email address) as the unique identifier.
Push groups, then choose on Runtime which role each group gives.

In Okta, use the app's Provisioning tab with Push New Users, Push Profile Updates, Push Groups and Deactivate Users. In Entra, set provisioning mode to Automatic with the base URL as Tenant URL. Google Workspace does not offer SCIM to custom apps, so there people join on first sign-in instead.

A person gets the highest role any of their groups gives: admin, then developer, then billing. A group never makes anyone an owner. An account holds at most two live SCIM tokens, so you can replace one without a gap.

Check it from code

A key made by an owner or admin reads the setup:

Terminalnpx withruntime sso

TypeScriptimport { Runtime } from "withruntime";const runtime = new Runtime();const { connections, scim } = await runtime.sso.get();for (const c of connections)  console.log(c.domain, c.domainVerifiedAt ? "verified" : "waiting for DNS");console.log(scim.users);

Over MCP it is the runtime_account_sso_get tool.

Mistakes and how Runtime handles them

A tile in the provider's app list that posts straight to Runtime. Runtime answers only sign-ins it started, so IdP-initiated SAML is refused. Point a bookmark app at the page's initiate login URI instead.
"Provider domain has not been verified". The TXT record is not visible yet. Choose Check DNS again.
An address outside the domain. Your provider sent an email that is not on the proven domain, and Runtime refuses it before any account is made. Check the NameID or email attribute (SAML) or the email claim (OIDC).
"Invalid SAML response". The certificate in Runtime no longer matches your provider's. Upload the current metadata again.
Requiring SSO and fearing a lockout. Owners are exempt and can still use Google or an email link, so a broken provider never locks you out.
Expecting Require single sign-on to stop API keys. A key is not a sign-in. Revoke the person's keys, or remove the person, to stop them.

How to invite your team for people outside your domain
How to read the audit log: every connection, domain check and SCIM change is recorded
Security and teams

Facts on this page were checked on 25 September 2026.