With SSO, your users sign in through your identity provider — Microsoft Entra, Okta, Auth0, Google, or any OIDC/SAML provider — and never hold an Orenda password. We federate your provider into the identity pool for your program, so what your app ends up holding is an ordinary set of Orenda tokens that work on every endpoint in these docs.
SSO is set up for you by the Orenda team. It is not self-service: your provider has to be registered against your program before any of this works. Contact the team to start.

​
How it differs from the standard flows

If you have read Authentication overview, most of it still applies — but the sign-in half is replaced: Everything after sign-in — accounts, payments, cards, webhooks — is exactly the same. The only endpoints you stop using are the ones under Register, Security setup, Password sign-in, and POST /v1/auth/refresh.

​
What Orenda gives you

These values are different for every program, and different again between sandbox and production. There is no shared endpoint you can hard-code — you receive your set from the Orenda team when your program’s SSO is configured.
Treat all of these as configuration, not constants. Programs are provisioned independently, so the URLs and client id you get for sandbox will not work in production, and another program’s values will never work for yours. Read them from config per environment.

​
Sandbox

Ask for a sandbox program alongside your production one. It gets its own authorization and token URLs and its own client id, and it can be pointed at a test tenant of your identity provider. On Orenda API calls, sandbox is selected the usual way:

​
Next steps

1

Get tokens

Sign in and get tokens — the authorization code exchange, what the token response contains, and how to refresh before it expires.
2

Set up passkeys for sensitive operations

Passkey step-up — signing in with SSO is not enough on its own for high-risk actions like adding a payee or viewing full card details. Read this before you build those screens.