On Runtime, single sign-on and SCIM directory sync are free on every account. They are not an enterprise add-on. Okta, Microsoft Entra ID and Google Workspace work from day one. Any SAML 2.0 or OpenID Connect provider works the same way. When you deactivate someone in your directory, they lose access. Every key they made is revoked in the same step (checked 26 October 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 and Resources > Applications > Create App Integration > SAML 2.0 | Single sign-on URL (ACS), audience URI; Name ID EmailAddress |
| Microsoft Entra | Enterprise apps > New application > Create your own application | 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 details. For Okta, give the Metadata URL. For Entra, give the App Federation Metadata Url. For Google, give the SSO URL, Entity ID and certificate, or the IdP metadata. Keep assertions signed. Each provider signs them by default.
Or use OIDC
Choose OIDC. Give your provider the page's sign-in redirect URI. Then
enter the issuer URL, client ID and client secret. Runtime reads the discovery
document for the rest. It asks for openid, email and profile, and it 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. When you edit other settings, leave the field empty. Runtime keeps the saved secret.
Prove the domain
| Type | Name | Value |
|---|---|---|
| TXT | _runtime-verify.company.com |
runtime-verify=<token> |
A new record can take a few minutes to appear. Once the domain is verified, it 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 your domain.
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. Use the base URL
https://withruntime.com/scim/v2, the SCIM token as the bearer token, anduserName(the email address) as the unique identifier. - Push groups. Then choose the role each group gives on Runtime.
In Okta, use the app's Provisioning tab. Turn on Push New Users, Push Profile Updates, Push Groups and Deactivate Users. In Entra, set provisioning mode to Automatic, and enter the base URL as the Tenant URL. Google Workspace does not offer SCIM for custom apps. So with Google Workspace, people join on their first sign-in instead.
A person gets the highest role that 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 ssoTypeScriptimport { 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, use the sso action of the runtime_account tool.
Mistakes and how Runtime handles them
- A tile in the provider's app list that posts straight to Runtime. Runtime accepts only sign-ins that 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 address that is
not on the proven domain. Runtime refuses it before any account is made. Check
the NameID or email attribute (SAML), or the
emailclaim (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. They can still sign in with 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.
Related
- 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 26 October 2026.