Documentation

SSO & SCIM

Put the INFRO console behind SAML or OIDC single sign-on, sync members with SCIM group-to-role mapping, enforce MFA, and keep break-glass access.

SSO puts the console behind your identity provider. Members sign in through SAML 2.0 or OIDC instead of a password, SCIM 2.0 keeps the member list in sync with your directory, and IdP groups map onto INFRO roles — so joining, moving teams, and leaving the company grant, change, and remove access automatically.

Everything on this page is configured in the console under Organization → Single sign-on; there is no public API for SSO or SCIM settings. SSO governs console sign-in only — API requests keep authenticating with sk_infro_ keys exactly as described in Authentication, and nothing on the request path ever touches your IdP. SSO and SCIM are part of the enterprise plan — see /enterprise.

SAML 2.0

The console shows INFRO's service-provider values; your IdP gives you its metadata. Any SAML 2.0 IdP works — Okta, Microsoft Entra ID, and Google Workspace are the ones we test against — and the exchange is the same everywhere:

ACS URLINFRO → your IdP: https://console.infro.io/sso/saml/acs. Where your IdP posts signed assertions after authenticating a member.
Entity IDINFRO → your IdP: https://console.infro.io/sso/saml/metadata. INFRO's SP entity ID; the same URL serves SP metadata XML if your IdP can import it.
IdP metadatayour IdP → INFROrequired: Upload the IdP metadata XML, or paste the IdP entity ID, sign-in URL, and X.509 signing certificate individually. Assertions not signed with this certificate are rejected.
NameIDattributerequired: Must be the member's email address (emailAddress format). Email is the join key between the IdP identity and INFRO membership — a NameID that doesn't match the member's INFRO email won't link.
groupsattribute: Multi-valued attribute of group names. Only needed for group → role mapping (below); the attribute name is configurable and defaults to groups.

Both SP-initiated sign-in (the member starts at the console) and IdP-initiated sign-in (the member clicks the INFRO tile in the IdP) are supported.

OIDC

OIDC connections use the authorization code flow. Create a standard web application in your IdP and exchange these values:

Redirect URIINFRO → your IdP: https://console.infro.io/sso/oidc/callback.
Issuer URLyour IdP → INFROrequired: INFRO reads <issuer>/.well-known/openid-configuration to discover endpoints and signing keys, so the discovery document must be reachable.
Client ID and secretyour IdP → INFROrequired: Credentials for the application you created. The secret is stored encrypted and can be rotated in the console at any time.
Scopesconfig: openid email profile, plus your groups scope if role mapping is on. The email claim plays the same join-key role NameID plays in SAML.
Groups claimconfig: Name of the ID-token claim carrying group names. Defaults to groups.

Domain capture

Domain capture is what routes members to SSO in the first place. Verify ownership of your email domain by adding a TXT record, and every console sign-in with an email on that domain is sent to your IdP instead of the password form.

DNS TXT record on your domain

infro-verification=<token from the console>

A new connection starts in test mode: SSO works for anyone who chooses it, but passwords still work too — use this window to confirm attribute mapping before anyone can be locked out. Switching the domain to enforced disables password sign-in for every member on it, except accounts explicitly exempted for break-glass access (below). You can verify multiple domains; each is enforced independently.

SCIM provisioning

SCIM 2.0 keeps INFRO membership in sync with your directory so nobody has to remember to remove a leaver. Enabling SCIM in the console produces the two values your IdP's provisioning integration asks for:

Base URL — https://api.infro.io/scim/v2, serving standard SCIM 2.0 Users and Groups resources. It is IdP-facing only.
Bearer token — generated in the console, shown once, rotatable. It authenticates only the SCIM endpoint — it is not an sk_infro_ API key and cannot call the model API.

What syncs: assigning a user provisions an INFRO member with the role their groups map to; a group change updates the role; deactivating or deleting the user removes the member — console sessions end immediately and API keys they created are revoked. Invitations sent by hand via POST /v1/org/invites still work, but with SCIM connected the IdP is the source of truth: manual role edits on a SCIM-managed member are overwritten on the next sync.

Group → role mapping

Map IdP groups to the four INFRO roles in the console. Full role definitions are in Members & roles; a typical mapping:

IdP group (example)	INFRO role	Grants
`infro-owners`	`owner`	Everything, including billing, SSO settings, and member management. Map a small, named group — not a department.
`platform-eng`	`admin`	Member, key, and policy management across projects.
`engineering`	`developer`	Day-to-day building: projects, keys, API access.
`finance-bi`	`analyst`	Read-only: dashboards, usage, and exports. No keys, no API calls.

A member in several mapped groups gets the most privileged of their mapped roles.
A member in no mapped group gets the connection's default role, which ships as analyst — least privilege until you decide otherwise.
A sync that would leave the organization with no owner is rejected and surfaced as a provisioning error in the console, so a bad group change can't lock everyone out.

Enforced MFA

The Require MFA setting makes multi-factor authentication a condition of console access. For password sign-ins, INFRO enforces it directly: members without an enrolled authenticator are walked through enrollment at next sign-in. For SSO sign-ins, INFRO sees only the assertion your IdP produces — it cannot verify how the user actually authenticated — so MFA policy for SSO members belongs in the IdP. Enforce it there, per application if your IdP supports it.

Practical upshot: turn on Require MFA in INFRO to cover password accounts (break-glass included), and require MFA on the INFRO application in your IdP to cover everyone else. These controls feed the certifications listed on /security; EU customers should read EU compliance alongside this page.

Break-glass access

Keep at least one owner on password + MFA, exempt from SSO enforcement. If your IdP is down, misconfigured, or a signing certificate expires, SSO sign-in fails for everyone at once — the break-glass owner is how you get back into the console to fix or disable the connection.

Use a dedicated account (sso-breakglass@yourco.com style), not somebody's daily login.
Store the password and MFA seed in your secrets vault with tightly restricted access.
Its sign-ins appear in the audit log like any other — alert on them. A break-glass sign-in should always be an event somebody expected.

The console refuses to switch a domain to enforced until at least one exempt password+MFA owner exists.

What SSO does not change

API keys keep working. SSO governs console sign-in; requests authenticate with Authorization: Bearer keys as before — see Authentication. No API request ever waits on your IdP.
Existing keys survive an SSO rollout. Turning on SSO, enforcement, or SCIM revokes nothing by itself.
Deprovisioning is the exception. When SCIM removes a member, keys they created are revoked. Keep production traffic on keys created for the service under a shared project, not on the personal key of whoever originally set it up.
Spend controls and allowlists are orthogonal. Spend limits and model allowlists apply the same way regardless of how a member signs in.

Audit trail

Every change on this page lands in the audit log: SSO and SCIM configuration edits as policy.updated; SCIM-driven membership changes as member.invited, member.role_changed, and member.removed with scim as the actor; and deprovisioning key revocations as key.revoked. Entries are retained for 12 months and are readable by owners and admins.