Runtime includes single sign-on over SAML or OIDC, and SCIM directory sync. Both are free on every account. Your directory adds people, gives them roles through groups, and removes them immediately when they leave. An owner can require single sign-on for everyone whose email is on your domain (single sign-on).
How it works
The application trusts the identity provider instead of keeping passwords. At sign-in, the application sends the person to the provider. The provider checks the person and applies its own rules, such as multi-factor authentication. It then sends back a signed statement of who the person is. Two standards carry that statement:
| Standard | What it is | Since |
|---|---|---|
| SAML 2.0 | "An XML-based framework for describing and exchanging security information", in OASIS's words | 2005 |
| OIDC | "A simple identity layer on top of the OAuth 2.0 protocol", returning a signed JSON ID Token | 2014 |
Sign-in is half of the job. The other half is removing access. SCIM lets the directory create, update and deactivate accounts in the application automatically. A person who leaves the company loses access everywhere at the same time.
Why it matters for a cloud account
A cloud account holds keys that spend money and reach data. With SSO, access follows the company's directory instead of a list of personal passwords. An audit can then show who had access on a given day. Many providers sell SSO only on an enterprise plan. Runtime does not charge for it.
On Runtime
- Okta, Microsoft Entra ID and Google Workspace are supported from the start. Any SAML 2.0 or OpenID Connect provider works the same way.
- You prove your email domain with a DNS record before SSO applies to it.
- Directory groups map to Runtime roles, and SCIM keeps them current (directory sync).
- Agents keep their own keys. Connecting an agent still takes one browser approval.
Related
- How to set up single sign-on
- What is workload identity?
- Least-privilege API keys
- What is a spending limit?
Sources
Checked 25 October 2026.