Runtime

What is single sign-on?

Single sign-on (SSO) lets people sign in to many applications with one account at their company's identity provider.

Runtime includes single sign-on over SAML or OIDC, and SCIM directory sync, free on every account. Your directory adds people, gives them roles through groups, and removes them the moment they leave, and 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 it sends the person to the provider, which checks them, applies its own rules such as multi-factor authentication, and sends back a signed statement of who they are. 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 the job. The other half is leaving: SCIM lets the directory create, update and deactivate accounts in the application automatically, so a person who leaves the company loses access everywhere at once.

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 rather than a list of personal passwords, and an audit can answer 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 day one, and 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 one is still a single browser approval.

Sources

Checked 27 September 2026.