SAML

Atlas speaks SAML in both directions.

Atlas as Service Provider (inbound SSO)

Your customers' IdPs sign users into your app. Configure the connection via SSO connections, hand the IdP the SP metadata, and users flow through:

POST /v1/client/sign_ins/saml            → begin: resolve a SAML connection by id or email domain, return the IdP AuthnRequest URL
POST /v1/sso/saml/acs                     → Assertion Consumer Service: verifies the signed assertion (audience, timestamps,
                                            XSW-hardened), JIT-provisions org membership, redirects back with a one-time ticket
GET  /v1/sso/saml/:connectionId/metadata → SP metadata XML (entityID + ACS URL) the customer registers with their IdP

Assertions are verified for a signed response, audience restriction, timestamp validity, and are hardened against XML Signature Wrapping (XSW). IdP-initiated flows are allowed only when the connection opts in (saml_allow_idp_initiated).

Atlas as Identity Provider (outbound)

Atlas can itself be the IdP for downstream SPs — your users sign into other SaaS with their Atlas identity.

GET  /v1/saml/idp/metadata   → Atlas-as-IdP metadata (entityId, signing certificate, SSO bindings) for a downstream SP to import
GET|POST /v1/saml/idp/sso    → the IdP SSO endpoint (session-gated): IdP-initiated (?sp=) or SP-initiated (SAMLRequest);
                               returns a signed SAML Response auto-POST form

OIDC enterprise SSO

For IdPs that speak OIDC instead of SAML, the equivalent inbound flow is:

POST /v1/client/sign_ins/sso   → begin (resolve OIDC connection by id or email domain), return the IdP authorization URL
GET  /v1/sso/callback          → IdP redirect target: verify the id_token, JIT-provision membership, redirect back with a ticket

DiscourseConnect

GET /discourse/sso   → DiscourseConnect provider endpoint: verifies the forum HMAC (constant-time),
                       authenticates via the hosted session, signs the identity payload back to the pinned return_sso_url