Single Sign-On (SSO)
Let invited clients sign in to your white label portal with their company login from providers like Auth0, Okta, or Azure AD.
What it does
Single sign-on (SSO) lets people you invite open your white label portal with their company login instead of only an email and password. You connect one identity provider under Agency > SSO. When it is enabled, the portal shows a Sign in with SSO button on both Log in and Create account. You can optionally turn on Require SSO so email and password sign-in are hidden and everyone must use SSO.
SSO only appears on your white label portal domain. Day-to-day work on the main platform still uses email (and Google when available there). Google sign-in is not offered on the white label portal. Your agency owner, joined Clients, and joined Team members can use Sign in with SSO on that portal when the email from their provider matches their account.
Before you start
Stay on the Agency plan.
Add White Label Client Portal under Agency > Domain and finish setup until that hostname is active. You cannot enable SSO until a client portal hostname exists, and people need that address to reach the portal.
Invite each person before they try SSO. Use Agency > Clients (or a project member invite) for outside clients, or Agency > Team for coworkers. Only invited people, people who already joined, and your agency owner may use the portal this way.
How to use it
Connect your identity provider
In your identity provider (for example Auth0, Okta, or Azure AD), create a public or single-page application for browser sign-in. Do not use a confidential server app that requires a client secret.
Open Agency in the console header, then click SSO.
Set Let clients sign in with SSO to Enabled. The Issuer URL, Client ID, Redirect URI, and Require SSO fields appear.
Copy the Redirect URI shown on the page and paste it into your identity provider’s allowed callback or redirect settings. Use that value exactly as shown. Do not replace it with your portal hostname.
From the provider, copy the Issuer URL and Client ID.
Paste them into the matching fields on Agency > SSO.
Optionally set Require SSO to Enabled if you want the portal to accept only SSO (no email and password forms).
Click Save.
If the Redirect URI in your provider does not match the value on this page, sign-in fails before people return to your portal.
What your clients do
Open your White Label Client Portal address (the hostname you verified under Domain).
Click Sign in with SSO on Log in, or open Create account and click Sign in with SSO if they still need to finish joining after an invite.
Complete sign-in with their company login provider.
Return to your portal and continue into the projects you assigned.
When Require SSO is Disabled, email and password stay available on the same screens. When Require SSO is Enabled, only Sign in with SSO appears. Password recovery for that login happens with their company identity provider, not through the portal.
If SSO stops working while Require SSO is on, sign in on the main platform (not your portal), open Agency > SSO, and set Require SSO (or SSO itself) to Disabled, then click Save.
What to expect
After a successful Save, the portal shows Sign in with SSO when SSO is enabled and both Issuer URL and Client ID are filled in.
With Require SSO set to Enabled, the email and password fields and the Forgot Password link are hidden on your portal. People must use Sign in with SSO.
People who were never invited cannot create a portal account through SSO alone. They see an error and stay on the sign-in or signup screen.
Joined Clients and Team members can use SSO on later visits as long as the email from their provider matches the account you invited.
Turning Let clients sign in with SSO back to Disabled and clicking Save hides the SSO button until you enable it again. Your issuer and client values stay saved for when you turn it back on. Require SSO also turns off when SSO is disabled.
If a client’s company already uses a shared login tool, SSO usually feels faster than creating yet another password for your portal.
Tips & common questions
Issuer URL should look like a normal website address for your provider (often starting with https://). If you paste a value without that prefix, the product adds it for you when you save.
Your identity provider must send the user’s email during sign-in, and that email should match the address you invited. If email is missing or different, SSO will fail.
SSO does not replace invitations. Send or resend invites from Clients or Team first, then ask people to use Sign in with SSO on your portal.
If Save fails with a message about adding a client portal CNAME, finish White Label Client Portal under Domain, wait until it is active, then try SSO again.
Turn on Require SSO only after you have confirmed that invited people can already complete Sign in with SSO. Otherwise they have no other way to enter your portal.
Choose a public or single-page application type in your identity provider. Confidential apps that require a client secret will not work with this sign-in flow.
Last updated