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 your program’s identity pool. What your app ends up with is an ordinary set of Orenda tokens that work on every endpoint in these docs.
SSO is set up by the Orenda team, not self-service. Your provider has to be registered against your program before any of this works. Contact the team to start.

​
What changes, and what doesn’t

Only the sign-in half changes. Everything after you have tokens is identical. You stop using the registration, security setup, password sign-in, and refresh endpoints. Accounts, payments, cards: all the same.

​
What Orenda gives you

Every program gets its own set of these, and sandbox gets a different set from production. There is no shared endpoint to hard-code. You receive yours from the Orenda team when your SSO is configured.
Treat these as configuration, not constants. Sandbox values won’t work in production, and another program’s values will never work for yours. Read them from config per environment.

​
What your identity provider must send

When a user signs in, we read the claims from the ID token your provider issues and use them to create the Orenda user.
No email, no sign-in. If your provider doesn’t return an email claim, we refuse the sign-in rather than create the account. An Orenda user without an email can’t verify their identity, can’t register a passkey, and can’t be contacted about their money. There is no way to opt out of this.
We read the ID token only. We don’t call your provider’s userinfo endpoint, so a claim that’s only available there won’t reach us. Request openid email at minimum, and check a real decoded token rather than assuming.
Microsoft Entra ID doesn’t send email by default. You have to add it as an optional claim on the app registration (Token configuration → Add optional claim → ID → email), and the user in your directory needs a mail address populated. This is the most common cause of a failed first sign-in. Auth0, Okta, and Google send email with the email scope and no extra setup.
If a user reaches us without an email, their first sign-in fails and the half-created account has to be cleared before they can retry, even after you fix the provider. Contact support with the affected user and we’ll reset it. Testing one user end to end in sandbox first is the cheapest way to avoid this.

​
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 point at a test tenant of your identity provider. On Orenda API calls, select sandbox 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 isn’t enough on its own for high-risk actions like adding a payee or viewing full card details. Read this before you build those screens.