> ## Documentation Index
> Fetch the complete documentation index at: https://docs.operata.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Configure an OIDC identity provider for SSO

> For identity provider admins — register Operata as an OpenID Connect application so your team signs in with corporate credentials.

OpenID Connect (OIDC) single sign-on (SSO) signs your team in to the Operata Platform through your identity provider (IdP), such as Okta, Microsoft Entra ID, or PingFederate. This page is for the administrator of that IdP. You register Operata as an application, send Operata the connection details, and test sign-in with one user.

For a SAML 2.0 IdP, follow [Request SSO for your Operata account](/docs/guides-request-sso) instead.

## Before you start

* An [Operata account](https://app.operata.io) with admin permissions.
* Admin access to an OIDC IdP.
* The email domains your users sign in with, such as `acme.com`.
* The users who need access, and the Operata group each one belongs to.

Operata matches each SSO sign-in to an Operata user by email address. Your IdP must release the `email` claim. Release `email_verified` as well if your IdP supports it.

## Steps

### 1. Request SSO from Operata

Email [Operata Support](mailto:support@operata.com) or your Customer Success Manager. Include your email domains and the users, each with their Operata group.

### 2. Create a web application in your IdP

Create an OIDC web application with these settings:

| Setting | Value |
| - | - |
| Grant type | Authorization Code |
| Scopes | `openid profile email` |
| Sign-in redirect URIs | `https://login.operata.io/login/callback` and `https://prod-operata.au.auth0.com/login/callback` |
| Sign-out redirect URI (optional) | `https://login.operata.io` |

Register both sign-in redirect URIs. Assign the application to the users who need access.

### 3. Release the email claims

Configure the application to release `email`, and `email_verified` if available. The email must match the user's Operata account. Matching ignores case.

### 4. Send the connection details to Operata

Reply to the support thread with:

* Your issuer or discovery URL, such as `https://acme.okta.com/.well-known/openid-configuration`.
* The client ID and client secret.
* Confirmation that the application releases `email`, and whether it releases `email_verified`.

Operata creates the SSO connection and your users, then tells you when to test.

### 5. Test sign-in

Test with a user Operata has confirmed. Operata creates each user before their first SSO sign-in, so test only after Operata replies.

The user goes to `https://app.operata.io` and enters their work email. Operata redirects them to your IdP. After they authenticate, they land in their Operata account.

## Result

Users whose email matches one of your domains sign in at `https://app.operata.io` with their corporate credentials. Sign-in starts from that page. OIDC has no equivalent of SAML sign-in from a tile in your IdP dashboard.

## Troubleshooting

| Symptom | Cause | Fix |
| - | - | - |
| Entering an email shows a password field | Operata hasn't routed your email domain to your connection | Confirm the domain with Operata Support, then hard-refresh the sign-in page. |
| Your IdP returns a redirect error | A sign-in redirect URI isn't registered | Register both URIs from step 2. |
| The user signs in but sees no data | The email your IdP sent doesn't match an Operata user | Check the email your IdP releases, then contact Operata Support. |
| Sign-in fails with no email | The application doesn't release `email` or lacks the `email` scope | Release `email` and add the `email` scope. |

## Related

* [Request SSO for your Operata account](/docs/guides-request-sso) — SSO through a SAML 2.0 IdP.
* [Configure Okta as an SSO identity provider](/docs/guides-sso-okta) — SAML 2.0 setup in Okta.