SSO Integration Patterns

1.OIDC code flow with PKCE

The default pattern. Redirect the user to your IdP, exchange the authorization code for an ID token, then hand that token to the Meridian session endpoint to mint a scoped API key. PKCE protects the front channel; the back channel never sees the client secret on the device.

POST https://llm.getnimbus.net/v1/sso/exchange
Authorization: Bearer <idp_id_token>
Content-Type: application/json

{
  "tenant": "acme",
  "scopes": ["chat", "embeddings"],
  "ttl_seconds": 3600
}

2.SAML 2.0 assertion bridge

For Okta, Azure AD, and Ping deployments where SAML is the source of truth. Point your IdP at the Meridian ACS URL, map NameID to the tenant user, and we issue a short-lived bearer keyed to the assertion lifetime. Group claims map directly to Meridian roles, so an engineering group grants the engineering rate-limit tier without a separate provisioning call.

3.JWT pass-through for machine clients

Service-to-service traffic skips the redirect dance entirely. Mint a JWT signed with your registered JWKS, set the audience to meridian-gateway, and include it as the bearer on every request. The gateway verifies the signature against your published keys, enforces tenant isolation from the tidclaim, and bills usage to the originating tenant. Rotate keys by publishing a new JWKS entry before retiring the old one.