> For the complete documentation index, see [llms.txt](https://docs.moregoodreviews.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.moregoodreviews.com/agencies/single-sign-on.md).

# Single Sign-On (SSO)

## 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.

{% hint style="info" %}
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.
{% endhint %}

***

## Before you start

1. Stay on the **Agency** plan.
2. 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.
3. 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

1. 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.
2. Open **Agency** in the console header, then click **SSO**.
3. Set **Let clients sign in with SSO** to **Enabled**. The **Issuer URL**, **Client ID**, **Redirect URI**, and **Require SSO** fields appear.
4. 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.
5. From the provider, copy the **Issuer URL** and **Client ID**.
6. Paste them into the matching fields on **Agency** > **SSO**.
7. Optionally set **Require SSO** to **Enabled** if you want the portal to accept only SSO (no email and password forms).
8. Click **Save**.

{% hint style="warning" %}
If the **Redirect URI** in your provider does not match the value on this page, sign-in fails before people return to your portal.
{% endhint %}

### What your clients do

1. Open your **White Label Client Portal** address (the hostname you verified under **Domain**).
2. 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.
3. Complete sign-in with their company login provider.
4. 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.

{% hint style="warning" %}
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**.
{% endhint %}

***

## 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.

{% hint style="success" %}
If a client’s company already uses a shared login tool, SSO usually feels faster than creating yet another password for your portal.
{% endhint %}

***

## Tips & common questions

{% hint style="info" %}
**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.
{% endhint %}

{% hint style="warning" %}
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.
{% endhint %}

{% hint style="warning" %}
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.
{% endhint %}

{% hint style="warning" %}
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.
{% endhint %}

{% hint style="warning" %}
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.
{% endhint %}

{% hint style="info" %}
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.
{% endhint %}