Single sign-on (SSO)

One /v1 endpoint for every provider. Point your OpenAI client at a new base URL and key, bring your own provider keys, and pay 0% markup on tokens.

Single sign-on lets your team sign in to Autonomous Relay Agents with your company’s identity provider instead of a separate account. When someone leaves, you disable them in one place. It works with Okta, Microsoft Entra ID (Azure AD), Google Workspace and any identity provider that supports OpenID Connect or SAML 2.0.

Single sign-on is part of the Enterprise plan. Setting it up takes about 20 minutes. You need to be an Owner or Admin of your Autonomous Relay organisation, an administrator of your identity provider, and access to your domain’s DNS records.

Overview

  • Step 1. Copy your redirect URL from Autonomous Relay.
  • Step 2. Create an app in your identity provider.
  • Step 3. Connect the app in Autonomous Relay.
  • Step 4. Verify your email domain with a DNS record.
  • Step 5. Run a test sign-in.
  • Step 6. Activate single sign-on.
  • Step 7 (optional). Require single sign-on for everyone at your domain.

Step 1: Copy your redirect URL

In the dashboard, open Settings and find the Single sign-on card. Copy the Sign-in redirect URL. It is always:

text
https://autonomousrelay.com/v1/auth/sso/callback

Your identity provider sends people back to this address after they sign in. It must be entered exactly, with no trailing slash.

Step 2: Create an app in your identity provider

Follow the section for your provider. At the end you will have three values: an issuer URL, a client ID and a client secret.

Okta

  • In the Okta Admin Console, go to Applications → Applications and select Create App Integration.
  • Choose OIDC - OpenID Connect, then Web Application, and select Next.
  • Name it Autonomous Relay. Leave Authorization Code selected as the grant type.
  • Under Sign-in redirect URIs, remove the example and paste your redirect URL from step 1.
  • Under Assignments, choose who may use the app (for example, a group), then select Save.
  • On the app’s General tab, copy the Client ID and the Client secret. Leave client authentication set to Client secret.
  • Your issuer URL is your Okta address, such as https://acme.okta.com.

Microsoft Entra ID

  • In the Microsoft Entra admin center, go to Identity → Applications → App registrations and select New registration.
  • Name it Autonomous Relay and choose Accounts in this organizational directory only.
  • Under Redirect URI, choose the Web platform and paste your redirect URL from step 1. Select Register.
  • On the Overview page, copy the Application (client) ID and the Directory (tenant) ID.
  • Go to Certificates & secrets → Client secrets → New client secret. Copy the secret’s Value right away (not the Secret ID); it is shown only once. Note its expiry date.
  • Your issuer URL is https://login.microsoftonline.com/<directory-tenant-id>/v2.0, with your Directory (tenant) ID in place.
  • To control who can sign in, open Enterprise applications → Autonomous Relay → Properties, set Assignment required to Yes, and assign users or groups.

Google Workspace

  • In the Google Cloud console, signed in as a Workspace administrator, select or create a project that belongs to your organisation.
  • Go to APIs & Services → OAuth consent screen and choose the user type Internal, so only people in your Workspace can sign in. Fill in the app name and contact email.
  • Go to APIs & Services → Credentials → Create credentials → OAuth client ID and choose Web application.
  • Under Authorized redirect URIs, paste your redirect URL from step 1 and select Create.
  • Copy the Client ID and the Client secret.
  • Your issuer URL is https://accounts.google.com.

Other OpenID Connect providers

Create a confidential web application using the authorization code flow, with your redirect URL from step 1. Autonomous Relay requests the scopes openid email profile, uses PKCE, and sends the client secret with HTTP Basic authentication (client_secret_basic). The issuer must publish its discovery document at <issuer>/.well-known/openid-configuration over https, and the ID token must carry the person’s email in email or preferred_username.

Using SAML 2.0 instead

If your security team requires SAML, use it in place of steps 2 and 3. Steps 4 to 7 are the same. In Settings → Single sign-on, choose SAML 2.0 as the protocol; you then see the two values your identity provider needs:

  • Entity ID (also called audience or identifier): https://autonomousrelay.com/v1/auth/sso/saml/metadata
  • ACS URL (also called reply URL or single sign-on URL): https://autonomousrelay.com/v1/auth/sso/saml/acs

Okta (SAML)

  • In Applications → Create App Integration, choose SAML 2.0 and name it Autonomous Relay.
  • Set Single sign-on URL to the ACS URL and Audience URI (SP Entity ID) to the Entity ID. Set Name ID format to EmailAddress and Application username to Email.
  • Under Attribute Statements, add email → user.email. Finish, then assign people or groups.
  • On the Sign On tab, open Metadata URL and save the XML file.

Microsoft Entra ID (SAML)

  • In Enterprise applications → New application → Create your own application, choose Non-gallery and name it Autonomous Relay.
  • Open Single sign-on → SAML. In Basic SAML Configuration, set Identifier (Entity ID) to the Entity ID and Reply URL (Assertion Consumer Service URL) to the ACS URL.
  • Keep the default Attributes & Claims (the email address claim is included).
  • Under SAML Certificates, download Federation Metadata XML. Assign users or groups on Users and groups.

Google Workspace (SAML)

  • In the Google Admin console, go to Apps → Web and mobile apps → Add app → Add custom SAML app and name it Autonomous Relay.
  • Download the IdP metadata file, then select Continue.
  • Set ACS URL to the ACS URL and Entity ID to the Entity ID. Set Name ID format to EMAIL and Name ID to Basic Information → Primary email.
  • Finish, then turn the app On for your users.

Connect it

Back in Settings, upload the metadata file (or paste its XML) and select Save. We read your entity ID, sign-on URL and signing certificate from it. Assertions must be signed. When your identity provider renews its certificate, upload the new metadata; single sign-on stays active. Then continue with step 4.

Step 3: Connect the app in Autonomous Relay

  • In Settings → Single sign-on, enter the Issuer URL, Client ID and Client secret from step 2.
  • Select Save. We read your provider’s discovery document straight away; if the issuer URL is wrong, you see why and nothing is saved.
  • The status now reads Not active yet. Nobody can sign in through it until you finish steps 4 to 6.

The client secret is encrypted when stored and is never shown again. To replace it later, type the new one and save; leave the field empty to keep the current one.

Step 4: Verify your email domain

This proves your organisation owns the domain in your team’s email addresses, for example acme.com.

  • Under Email domains, type your domain and select Add domain.
  • Copy the TXT record shown. Its name is your domain itself (many DNS providers write this as @), and its value looks like autonomousrelay-verification=AbC123….
  • At your DNS provider (for example Cloudflare, GoDaddy, Route 53 or Google Domains), add a new TXT record with that name and value. Keep any TXT records you already have.
  • Back in Settings, select Check now. New records can take up to an hour to appear; if the check fails, wait and try again.
  • Repeat for each domain your team uses (up to 20). You can remove the TXT record after the domain shows Verified, but leaving it does no harm.
A domain can be verified by only one Autonomous Relay organisation. If yours is already taken, contact us.

Step 5: Run a test sign-in

  • Select Run a test sign-in. You are sent to your identity provider; sign in there as yourself.
  • You come back to Settings with Test sign-in succeeded as you@acme.com.
  • The test signs nobody in and changes nothing else. The email your provider returns must be at a domain you verified in step 4.

If the test fails, the message says what your identity provider answered. The common causes are listed under Troubleshooting below.

Step 6: Activate single sign-on

Select Activate. It is available once a test sign-in has succeeded and at least one domain is verified. From now on, anyone at your verified domains can choose Sign in with SSO on the sign-in page.

Step 7 (optional): Require single sign-on

Turn on Require single sign-on to make it the only way in for people at your verified domains. Google, GitHub and wallet sign-in are then refused for them, and so is switching into your organisation from another one. Anyone it applies to who is signed in right now is signed out and must sign in again with SSO.

Owners are exempt. They keep their usual sign-in method as a fallback, so an outage at your identity provider can never lock your whole organisation out. Keep at least one Owner whose email is at your domain.

How your team signs in

  • On the sign-in page, choose Sign in with SSO and enter a work email.
  • They are sent to your identity provider, sign in there, and arrive in your organisation.
  • The first time someone signs in, they get a Developer seat that is limited to workspaces: they see nothing until they are given access. An Owner gives it under Members, by changing What they can see to Whole organisation or by changing their role. To give access to particular workspaces only, open Clients, select People on a workspace and add them as a Member or Workspace admin.
  • People who already have a seat keep their role and scope.

Removing someone

  • Disable or unassign them in your identity provider: they can no longer sign in with SSO.
  • A dashboard session lasts up to 12 hours. To end their access at once, also remove them under Members; that ends their sessions immediately, and a removed seat is not given back by a later SSO sign-in.
  • Automatic provisioning and removal from your directory (SCIM) is not available yet.

Changing or turning off single sign-on

  • Rotating the client secret (for example before an Entra secret expires): enter the new secret and save. Single sign-on stays active.
  • Changing the issuer or client ID (a new app or identity provider): the connection returns to Not active yet and Require single sign-on is turned off. Run a test sign-in and activate again.
  • Turn off stops single sign-on at once and turns off the requirement. People sign in with their other methods.

Troubleshooting

  • “The discovery document names issuer …”: paste the issuer exactly as your identity provider shows it. For Entra, use the /v2.0 address with your tenant ID.
  • “No TXT record … found”: the record is not visible yet, or was added to a subdomain. Check its name is your domain itself (@), wait up to an hour, and try again.
  • Redirect URI mismatch at your provider: the redirect URL in your app must be exactly https://autonomousrelay.com/v1/auth/sso/callback.
  • “invalid_client”: the client secret is wrong or has expired. Create a new one and save it in Settings.
  • “…an email address your organisation has not verified”: the person’s email in your identity provider is at a domain you have not verified. Verify that domain too, or correct their email.
  • “Your access to this organisation was removed”: their seat was removed under Members. An Owner can invite them again.
  • “Single sign-on is not set up for that email address”: the domain is not verified, or single sign-on is not active yet.

Everything in this guide can also be done through the API: see the SSO section of the API reference.