> ## Documentation Index
> Fetch the complete documentation index at: https://docs.requesty.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Single Sign-On (SSO)
> Sign in to Requesty with your corporate identity provider. Works with Microsoft Entra ID, Okta, and any OIDC or SAML provider.
Requesty supports enterprise SSO so your team can sign in to [app.requesty.ai](https://app.requesty.ai) with the same credentials they already use. Users you provision in your IdP get access automatically, and users you remove lose access on their next session.
**[Configure SSO](https://app.requesty.ai/settings)** in the Requesty Console.
SSO is included on enterprise plans. Email [support@requesty.ai](mailto:support@requesty.ai) (or talk to your account team) and we will turn it on for your organization. Most customers are live the same day.
## Supported identity providers
Formerly Azure AD. SAML 2.0, with enterprise applications, attribute mappings, and Conditional Access.
SAML 2.0 via an Okta Workforce application.
Google Workspace, JumpCloud, OneLogin, Ping Identity, Auth0, Keycloak, ADFS, or any other IdP that supports SAML 2.0 or OIDC.
## How it works
```mermaid theme={"dark"}
graph LR
A[User opens app.requesty.ai] --> B{Email domain
matches your org?}
B -->|Yes| C[Redirect to your IdP]
C --> D[User authenticates]
D --> E[Land in Requesty
signed in as org member]
B -->|No| F[Standard sign-in]
style C fill:#4F46E5,color:#fff
style D fill:#4F46E5,color:#fff
style E fill:#059669,color:#fff
```
* **Domain based routing.** Once we have linked one or more email domains (for example `acme.com`) to your IdP, anyone signing in with an `@acme.com` address is automatically redirected to your IdP.
* **Just in time provisioning.** The first time a user signs in via SSO, they join your Requesty organization automatically. No manual invite needed.
* **Existing accounts are linked.** If someone in your domain already had a Requesty account before SSO, their account is linked to the SSO connection on first sign-in. No data is lost.
* **No passwords to manage.** Users do not set a Requesty password. Access is controlled entirely by your IdP, so disabling the IdP account revokes Requesty dashboard access on the next session.
* **Existing groups and policies still apply.** SSO users land in your organization's default [group](/features/groups) and inherit its [approved models](/features/approved-models), [access lists](/features/access-lists), and budgets. You can move them between groups at any time.
## How setup works
Setup is a short back and forth between your IdP admin and the Requesty team. You do not need to deploy anything.
Email [support@requesty.ai](mailto:support@requesty.ai) with:
* Your identity provider (Entra ID, Okta, or which OIDC / SAML product).
* The email domain(s) you want to route through SSO (for example `acme.com`, `acme.co.uk`).
* The Requesty organization you want the connection attached to.
We create the connection on our side and reply with the values your IdP needs:
* **SAML**: an **Identifier (Entity ID)** and a **Reply URL (Assertion Consumer Service URL)**.
* **OIDC**: an **Authorized redirect URI**.
Use the values we sent to register Requesty in your IdP. Pick the tab for your provider below.
1. **Create a new enterprise application in Microsoft**
1. Navigate to the [Microsoft Azure portal](https://portal.azure.com) and sign in.
2. Under *Azure Services*, find and select *Enterprise applications*. You may have to go to *All services* and scroll down to *Identity* to find it.
3. Select *New application > Create your own application*.
4. In the modal, give the app a name (for example `Requesty SSO`), select *Integrate any other application you don't find in the gallery (Non-gallery)*, then select *Create*.
2. **Assign users or groups**
1. In the *Getting Started* section, select *Assign users and groups > Add user/group*.
2. Select the *None Selected* link, pick the users or groups who should have access, then select *Select* and *Assign*.
3. **Set Basic SAML Configuration**
1. In the navigation sidebar, open *Manage > Single sign-on*.
2. In *Select a single sign-on method*, select *SAML*.
3. In *Basic SAML Configuration*, select *Edit* and paste the values we sent:
* **Identifier (Entity ID)**: the Entity ID from Requesty.
* **Reply URL (Assertion Consumer Service URL)**: the ACS URL from Requesty.
4. Select *Save* and close the panel.
4. **Verify Attributes & Claims**
Your SAML responses must include these attributes. They are the Entra defaults, so you usually do not need to change anything. Many SAML errors come from incorrect attribute mappings, so it is worth double checking.
| Claim name | Value | Required |
| -------------------------------------------------------------------- | ---------------- | -------- |
| `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress` | `user.mail` | Required |
| `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname` | `user.givenname` | Optional |
| `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname` | `user.surname` | Optional |
5. **Share the App Federation Metadata URL with Requesty**
1. On the *Set up Single Sign-On with SAML* page, find the *SAML Certificates* section.
2. Copy the **App Federation Metadata Url** and send it to us.
Once we paste it on our side, the connection is ready to test.
1. **Create a new enterprise app in Okta**
1. Sign in to Okta and select *Admin* in the top right corner.
2. In the sidebar, open *Applications > Applications*, then select *Create App Integration*.
3. In the modal, select *SAML 2.0* and *Next*.
4. In *General Settings*, give the app a name (for example `Requesty SSO`) and select *Next*.
2. **Configure SAML**
On the *Configure SAML* page, paste the values we sent:
* **Single sign-on URL**: the ACS URL from Requesty.
* **Audience URI (SP Entity ID)**: the Entity ID from Requesty.
3. **Verify Attribute Statements**
Your SAML responses must include these attributes. They are the Okta defaults.
| Name | Value | Required |
| ----------- | ---------------- | -------- |
| `email` | `user.email` | Required |
| `firstName` | `user.firstName` | Optional |
| `lastName` | `user.lastName` | Optional |
4. **Assign users or groups**
In the application's *Assignments* tab, assign the people or groups who should have access.
5. **Share the Metadata URL with Requesty**
1. Open the application's *Sign On* tab.
2. Under *SAML Setup*, copy the **Identity Provider Metadata URL** (sometimes shown as *Metadata URL*) and send it to us.
Once we paste it on our side, the connection is ready to test.
The flow is the same for any IdP that speaks OIDC or SAML 2.0:
1. Create a new application or client in your IdP.
2. Use the values we sent:
* **OIDC**: paste our **Authorized redirect URI** into the IdP's allowed redirect URLs.
* **SAML**: paste our **Reply URL (ACS URL)** and **Entity ID** into the IdP's SAML configuration.
3. Make sure the standard user attributes are mapped:
* **OIDC**: `email`, `email_verified`, `given_name`, `family_name` (these are the OIDC standard claims).
* **SAML**: `email` (required), first name, last name.
4. For OIDC, allow at minimum the scopes `openid`, `email`, and `profile`.
5. Send us back:
* **OIDC**: your **Discovery (well-known) endpoint**, **Client ID**, and **Client Secret**.
* **SAML**: your **IdP metadata URL** (or the metadata XML).
If your IdP has a quirk (Keycloak realms, ADFS claims rules, OIDC without a discovery endpoint, missing `email_verified` claim), tell us in the same email and we will work through it with you.
Once you send back the metadata URL (SAML) or the discovery endpoint plus client credentials (OIDC), we plug them into the connection, run a test sign-in with one of your users, and enable the connection for the domains you listed.
At that point, anyone with a matching email domain is redirected to your IdP at sign-in and sign-up.
Want to test SSO before rolling it out org wide? Send us a test email domain or a single test user. We can enable SSO for just that subset first, then expand once you are happy. We also recommend coordinating the cutover at an off peak time, so that anyone affected can re-test if there is a misconfiguration.
By default, SSO matches the **exact** email domain you give us. A connection on `acme.com` does not match `john@sales.acme.com`. If you need subdomain matching, tell us when you email and we will enable it on the connection.
## Group sync (optional)
You can have your IdP send a `groups` claim and we will route each user into a matching Requesty [group](/features/groups), so their [approved models](/features/approved-models), [access lists](/features/access-lists), and budgets are inherited automatically.
To enable it:
1. In your IdP, add a `groups` claim or attribute to the Requesty application.
2. Tell us the IdP group names you want mapped, and which Requesty group each should land in.
If you do not send a `groups` claim, new SSO users land in your organization's default group.
## What SSO does and does not change
No. SSO controls **who can sign in to the Requesty dashboard**. API requests to `router.requesty.ai` still authenticate with your [API keys](/api-reference/management-apis) and [service accounts](/features/service-accounts). That is intentional, so your production agents keep working even if a user leaves the company.
To rotate access for a departing employee:
* Disable them in your IdP. They lose dashboard access on the next session.
* Revoke or transfer any API keys they personally owned (the Admin Panel shows API keys per user).
Yes. Once a connection is enabled for your domain, all users with a matching email address are redirected to your IdP at sign-in and sign-up. Email or social sign-in is no longer an option for those users, so people cannot bypass your IdP.
Their account is reused. The next time they sign in, they are redirected to your IdP, and once they authenticate the existing account is linked to the SSO connection. Email verification on the IdP side counts as verification on our side, so password prompts are skipped. No data is lost.
Yes. SSO is independent of [EU routing](/features/eu-routing). You can sign in via your IdP and still send API traffic through `router.eu.requesty.ai` to keep request processing in the EU.
The users created via SSO are not deleted, so your app keeps working. They will need to sign in with another method (email code, social) the next time they come back.
Yes. Self hosted Requesty supports SSO via Microsoft Entra ID (MSAL) or any OIDC provider (Google, Okta, GitHub, GitLab, generic OIDC) through the bundled SSO handler. Contact us for the self hosted setup guide.
## Need help?
Email [support@requesty.ai](mailto:support@requesty.ai) with your IdP and email domain(s), or ping your account team. We will guide you end to end and most customers are live the same day.