SSO

Single sign-on through id-orgn — OAuth 2.0 with PKCE across ORGN Studio, Gateway console, CDE, and Scanner. One identity, no credential silos.

All ORGN products authenticate humans through id-orgn — the shared identity provider at id.orgn.com. You sign in once at id-orgn (Sign in with GitHub is available, along with passkeys and other linked providers). There is no separate email/password account on individual ORGN products and no per-product credential silos.

GitHub repository access is an additional step when you need clone, push, or import permissions: the ORGN GitHub App grants those scopes. App tokens are issued and refreshed through id-orgn after you have a session. See Teams — GitHub integration.

One identity across the stack

Product	Sign-in surface	Session
ORGN Studio	cde.orgn.com — UNLOCK redirects to id-orgn	Browser cookie + refresh token
ORGN CDE	Desktop welcome screen — Continue with id-orgn	VS Code authentication provider (PKCE)
ORGN Gateway console	gateway.orgn.com — Sign in with Orgn SSO	Signed session cookie
ORGN Scanner	scanner.orgn.com — same SSO button	Signed session cookie

Programmatic Gateway access uses API keys (sk-ollm-*), not SSO. Console SSO and API keys are independent — see Gateway authentication.

PKCE flow

id-orgn uses OAuth 2.0 Authorization Code flow with PKCE (Proof Key for Code Exchange). PKCE prevents authorization-code interception on public clients like the CDE desktop app and browser-based Studio.

Authorization request

The product (Studio, CDE, Gateway console, or Scanner) generates a PKCE code_verifier and code_challenge, then redirects you to id-orgn with:

client_id for the requesting product
redirect_uri registered for that product
state to bind the callback to the pending sign-in attempt
code_challenge + code_challenge_method=S256

Authenticate at id-orgn

You complete sign-in at id-orgn (passkeys, linked identity providers, or org-configured methods). id-orgn never shares your raw credentials with ORGN products — it returns an authorization code to the registered redirect URI.

Token exchange

The product exchanges the code + code_verifier for:

Access token (short-lived JWT for API calls)
Refresh token (rotating, stored securely — HTTP-only cookie in browser products, OS keychain in CDE)

CDE matches the callback to the pending sign-in using the state parameter. A mismatch or expired attempt is rejected.

Session use

The access token identifies you for team membership, billing, and project authorization. Products refresh silently until you sign out or the refresh token is revoked.

Sign out from id-orgn or revoke sessions in id-orgn account settings to end access across all products. A product-local sign-out may not revoke refresh tokens held by other clients.

Environments

Environment	id-orgn base URL
Production	`https://id.orgn.com`
Development	`https://dev-id.orgn.com`

Product URLs (Studio, Gateway, Scanner, CDE) point at the matching id-orgn environment. Do not mix production identity with dev product endpoints.

What SSO does and does not cover

SSO proves who you are — team membership, role checks, and audit attribution.

SSO does not prove how inference ran. Execution assurance (TEE attestation, Trust Domain isolation) is separate. See the Trust model.

Signing in with GitHub at id-orgn proves your identity — it does not by itself grant the ORGN GitHub App access to private repositories. Connect the app from Studio or CDE settings when import, clone, or push operations require it. That flow also routes through id-orgn.

Enterprise identity

Enterprise customers can configure org-level identity requirements during sales onboarding (dedicated IdP federation, VPC-bound auth endpoints, session policies). Standard self-serve sign-up uses id-orgn directly. Contact the team via Enterprise for federation requirements.

Trust model — Identity boundary
Teams — membership, invitations, GitHub connection
CDE Quickstart — Sign in — desktop PKCE flow
Local vs confidential cloud — after sign-in
Gateway authentication — console SSO vs API keys

On this page