Single Sign-On (SSO)

O Single Sign-On permite que seu time faça login no Studio pelo provedor de identidade da empresa, em vez de gerenciar senhas separadas. O Studio suporta OIDC e SAML 2.0.

Antes de começar

Verifique o seu domínio de e-mail primeiro. O SSO não pode ser salvo até o domínio aparecer como Verified, e mudanças de DNS levam tempo para propagar.

É o domínio verificado que autoriza o seu provedor de identidade. Removê-lo depois desabilita imediatamente o login por SSO para todos nesse domínio, até que ele seja verificado novamente.

Decida o seu Provider ID antes de configurar o provedor de identidade. Ele passa a fazer parte da URL de callback que você registra lá e é fixo depois de salvo — mudá-lo depois significa excluir o provedor e configurá-lo de novo.

Configuração

1. Abra as configurações de SSO

Vá em Settings → Security → Single sign-on nas configurações da sua organização.

2. Escolha um protocolo

ProtocoloUse quando
OIDCSeu IdP suporta OpenID Connect — Okta, Microsoft Entra ID, Auth0, Google Workspace
SAML 2.0Seu IdP é apenas SAML — ADFS, Shibboleth ou IdPs corporativos mais antigos

3. Preencha o formulário

Campos obrigatórios nos dois protocolos:

CampoO que informar
Provider IDUm slug curto que identifica esta conexão. Apenas letras, números e hífens. Precisa ser único entre todas as organizações do Studio, então inclua algo específico seu — azure-ad-acme, não azure-ad. Se o ID já estiver em uso, o Studio avisa e sugere um livre.
Issuer URLA URL do issuer do provedor de identidade. Precisa ser HTTPS.
DomainO domínio de e-mail da sua organização, por exemplo company.com. Usuários com esse domínio serão direcionados pelo SSO no login.

Campos adicionais do OIDC:

CampoO que informar
Client IDO client ID da aplicação no seu IdP.
Client SecretO client secret do seu IdP.
ScopesScopes OIDC separados por vírgula. Padrão: openid,profile,email.

No OIDC, o Studio busca automaticamente os endpoints (authorization_endpoint, token_endpoint, userinfo_endpoint, jwks_uri) no documento de descoberta /.well-known/openid-configuration do seu issuer. Você só precisa informar a URL do issuer.

Campos adicionais do SAML:

CampoO que informar
Entry Point URLA URL do serviço de SSO do IdP para onde o Studio envia as requisições de autenticação.
Identity Provider CertificateO certificado X.509 codificado em Base-64 do seu IdP, usado para verificar as assertions.

4. Copie a Callback URL

A Callback URL exibida no formulário é o endpoint para onde o seu provedor de identidade precisa redirecionar os usuários depois da autenticação. Copie-a e registre-a no seu IdP antes de salvar.

Provedores OIDC (Okta, Microsoft Entra ID, Google Workspace, Auth0):

https://agent-studio.seeyu.ai/api/auth/sso/callback/{provider-id}

Provedores SAML (ADFS, Shibboleth):

https://agent-studio.seeyu.ai/api/auth/sso/saml2/callback/{provider-id}

5. Salve e teste

Clique em Save. Para testar, saia da conta e use o botão Sign in with SSO na tela de login. Informe um endereço de e-mail no domínio configurado — o Studio vai redirecionar você para o seu provedor de identidade.

Guias por provedor

Okta (OIDC)

No Okta (documentação oficial):

  1. Vá em Applications → Create App Integration
  2. Selecione OIDC - OpenID Connect e depois Web Application
  3. Defina o Sign-in redirect URI como a sua callback URL do Studio: 
    https://agent-studio.seeyu.ai/api/auth/sso/callback/okta
  4. Em Assignments, dê acesso aos usuários ou grupos relevantes
  5. Copie o Client ID e o Client Secret na aba General do app
  6. O seu domínio Okta é o hostname do console de administração, por exemplo dev-1234567.okta.com

No Studio:

CampoValor
Provider TypeOIDC
Provider IDokta
Issuer URLhttps://dev-1234567.okta.com/oauth2/default
Domaincompany.com
Client IDDo app no Okta
Client SecretDo app no Okta

A issuer URL usa o authorization server padrão do Okta, que já vem configurado em toda org Okta. Se você criou um authorization server customizado, troque default pelo nome do seu server.

Microsoft Entra ID (OIDC)

No Azure (documentação oficial):

  1. Vá em Microsoft Entra ID → App registrations → New registration
  2. Em Redirect URI, selecione Web e informe a sua callback URL do Studio, usando o Provider ID que você escolheu: 
    https://agent-studio.seeyu.ai/api/auth/sso/callback/azure-ad-acme
  3. Depois do registro, vá em Certificates & secrets → New client secret e copie o valor imediatamente — ele não será exibido novamente
  4. Vá em Overview e copie o Application (client) ID e o Directory (tenant) ID
  5. Vá em Token configuration → Add optional claim, escolha ID e adicione email. Sem essa claim, o Entra omite o endereço de e-mail de usuários gerenciados, e o login falha com um erro de informação de usuário ausente
  6. Se Enterprise applications → Studio → Properties → Assignment required estiver como Yes, atribua os usuários ou grupos que devem poder fazer login. A Microsoft rejeita usuários não atribuídos antes que eles cheguem ao Studio

No Studio:

CampoValor
Provider TypeOIDC
Provider IDazure-ad-acme (precisa ser globalmente único)
Issuer URLhttps://login.microsoftonline.com/{tenant-id}/v2.0
Domaincompany.com
Client IDApplication (client) ID
Client SecretValor do secret

Microsoft Entra ID (SAML 2.0)

Use esta opção quando o seu tenant está configurado para SAML em vez de OIDC. Os dois são suportados; o OIDC é mais simples, se você puder escolher.

No Azure (documentação oficial):

  1. Vá em Enterprise applications → New application → Create your own application e escolha Integrate any other application you don't find in the gallery
  2. Abra Single sign-on e selecione SAML
  3. Edite Basic SAML Configuration e defina os dois valores a partir da página de configurações de SSO do Studio:
    • Identifier (Entity ID) — o campo SP Entity ID
    • Reply URL (Assertion Consumer Service URL) — o campo ACS URL
  4. Em Attributes & Claims, confirme que as claims padrão estão presentes. O Studio lê as URIs de claim do schema padrão para e-mail, nome e identificador de nome
  5. Em SAML Certificates, baixe o Certificate (Base64). O conteúdo dele vai no campo Certificate do Studio, que é obrigatório. Opcionalmente, você também pode baixar o Federation Metadata XML e colá-lo no campo IDP Metadata XML do Studio, em Advanced Options — ele não substitui o certificado
  6. No painel Set up da sua aplicação, copie a Login URL e o Microsoft Entra Identifier
  7. Em Users and groups, atribua as pessoas que devem poder fazer login — a Microsoft rejeita usuários não atribuídos antes que eles cheguem ao Studio

No Studio:

CampoValor
Provider TypeSAML
Provider IDazure-ad-acme (precisa ser globalmente único)
Issuer URLMicrosoft Entra Identifier, por exemplo https://sts.windows.net/{tenant-id}/
Domaincompany.com
Entry Point URLLogin URL do Entra
CertificateConteúdo do certificado Base64

O Identifier (Entity ID) que você define no Entra é o valor contra o qual o Studio valida a audience da assertion. Se ele não coincidir exatamente com o SP Entity ID exibido no Studio, o login falha com um erro de audience incompatível.

Google Workspace (OIDC)

No Google Cloud Console (documentação oficial):

  1. Vá em APIs & Services → Credentials → Create Credentials → OAuth 2.0 Client ID
  2. Defina o tipo de aplicação como Web application
  3. Adicione a sua callback URL do Studio em Authorized redirect URIs: 
    https://agent-studio.seeyu.ai/api/auth/sso/callback/google-workspace
  4. Copie o Client ID e o Client Secret

No Studio:

CampoValor
Provider TypeOIDC
Provider IDgoogle-workspace
Issuer URLhttps://accounts.google.com
Domaincompany.com
Client IDDo Google Cloud Console
Client SecretDo Google Cloud Console

Para restringir o login ao domínio do seu Google Workspace, configure a tela de consentimento OAuth e garanta que o app esteja definido como Internal (apenas usuários do Workspace) em User type. Definir o app como Internal limita o acesso a usuários da sua organização no Google Workspace.

ADFS (SAML 2.0)

No ADFS (documentação oficial):

  1. Abra AD FS Management → Relying Party Trusts → Add Relying Party Trust
  2. Escolha Claims aware e depois Enter data about the relying party manually
  3. Defina o Relying party identifier (Entity ID) como o SP Entity ID exibido nas configurações de SSO do Studio. O SAML compara a audience da assertion com esse valor, então ele precisa coincidir exatamente: 
    https://agent-studio.seeyu.ai
  4. Adicione um endpoint: SAML Assertion Consumer Service (HTTP POST) com a URL: 
    https://agent-studio.seeyu.ai/api/auth/sso/saml2/callback/adfs
  5. Exporte o Token-signing certificate em Certificates: clique com o botão direito → View Certificate → Details → Copy to File e escolha Base-64 encoded X.509 (.CER). O arquivo .cer está codificado em PEM — renomeie-o para .pem antes de colar o conteúdo no Studio.
  6. Anote a ADFS Federation Service endpoint URL (por exemplo, https://adfs.company.com/adfs/ls)

No Studio:

CampoValor
Provider TypeSAML
Provider IDadfs
Issuer URLhttps://adfs.company.com/adfs/services/trust (o Federation Service identifier do ADFS)
Domaincompany.com
Entry Point URLhttps://adfs.company.com/adfs/ls
CertificateConteúdo do arquivo .pem

A Issuer URL é o identificador do próprio provedor de identidade, encontrado no ADFS em Service → Federation Service Properties → Federation Service identifier. Ela não é a URL do Studio — o identificador do Studio é o SP Entity ID exibido nas configurações de SSO, que você registra no ADFS como relying party identifier.

O Studio exige que esse campo use https. O ADFS costuma definir seu Federation Service identifier com uma URI http:// por padrão; se for o seu caso, mude para https no ADFS para que os dois lados concordem.

Como o login funciona depois da configuração

Com o SSO configurado, usuários do seu domínio (company.com) podem fazer login pelo seu provedor de identidade:

  1. O usuário acessa agent-studio.seeyu.ai e clica em Sign in with SSO
  2. Ele informa o e-mail corporativo (por exemplo, alice@company.com)
  3. O Studio redireciona para o seu provedor de identidade
  4. Depois de autenticar, ele volta para o Studio e é adicionado à sua organização automaticamente
  5. Ele cai no workspace

Usuários que fazem login por SSO pela primeira vez são provisionados automaticamente e adicionados à sua organização — sem convite manual.

O login precisa começar no Studio. Iniciar pelo portal de aplicações do seu provedor de identidade (o My Apps da Microsoft, o bloco no dashboard do Okta) envia uma assertion não solicitada, que o Studio rejeita. Isso é deliberado — aceitá-las permitiria que qualquer pessoa reproduzisse uma assertion no seu tenant — mas significa que um teste iniciado pelo IdP falha mesmo com a configuração correta.

O provisionamento por SSO cria membros internos da organização. Membros externos de workspace são diferentes: eles são convidados para um workspace específico, sem entrar na sua organização nem consumir um dos seus assentos.

O login por senha continua disponível. Obrigar todos os membros da organização a usar exclusivamente o SSO ainda não é suportado.

Common Questions

Qualquer provedor de identidade que suporte OIDC ou SAML 2.0. Isso inclui Okta, Microsoft Entra ID (Azure AD), Google Workspace, Auth0, OneLogin, JumpCloud, Ping Identity, ADFS, Shibboleth e outros.
O domínio (por exemplo, company.com) é como o Studio direciona os usuários ao provedor de identidade correto. Quando um usuário informa o e-mail na tela de login por SSO, o Studio compara o domínio do e-mail com um provedor de SSO registrado e redireciona o usuário para lá.
Não. Para provedores OIDC, o Studio busca automaticamente os endpoints de authorization, token e JWKS no documento de descoberta em {issuer}/.well-known/openid-configuration. Você só precisa informar a URL do issuer.
O Studio cria uma conta para ele automaticamente e o adiciona à sua organização. Nenhum convite manual é necessário. Por padrão, ele recebe o papel de membro. Membros externos de workspace não são provisionados na sua organização via SSO; eles são convidados diretamente para um workspace e permanecem fora da lista de membros da sua org.
Sim. Habilitar o SSO não desativa o login por senha. Os usuários ainda podem entrar com e-mail e senha, se tiverem uma. O SSO obrigatório (exigir que todos os usuários do domínio usem SSO) ainda não é suportado.
O Studio vincula a identidade de SSO a essa conta automaticamente. A vinculação é autorizada pelo seu domínio verificado: como você comprovou a propriedade do domínio antes de configurar o SSO, o Studio trata o seu provedor de identidade como autoritativo para os endereços de e-mail nesse domínio. Isso funciona igual para OIDC e SAML e não depende de o seu IdP enviar uma claim email_verified — o Microsoft Entra, por exemplo, nunca envia. A correspondência é feita pelo endereço de e-mail, então o endereço que o seu IdP informa precisa ser idêntico ao da conta existente. Se ele for diferente — uma variante privilegiada ou administrativa, como p-alice@company.com, ou outro alias — o Studio trata como uma pessoa nova e cria uma conta separada em vez de vincular.
Proprietários e administradores da organização podem configurar o SSO. É necessário estar no plano Enterprise.
A Callback URL (também chamada de Redirect URI ou ACS URL) é o endpoint no Studio que recebe a resposta de autenticação do seu provedor de identidade. Para provedores OIDC, ela segue o formato: https://agent-studio.seeyu.ai/api/auth/sso/callback/{provider-id}. Para provedores SAML, é: https://agent-studio.seeyu.ai/api/auth/sso/saml2/callback/{provider-id}. Você precisa registrar essa URL no seu provedor de identidade para o SSO funcionar.
Abra Settings → Security → Single sign-on e clique em Edit. Atualize os campos e salve. A configuração do provedor existente é substituída.

Configuração em auto-hospedagem

Deployments auto-hospedados usam variáveis de ambiente em vez da verificação de plano/cobrança.

Variáveis de ambiente

# Required
SSO_ENABLED=true
NEXT_PUBLIC_SSO_ENABLED=true

# Required if you want users auto-added to your organization on first SSO sign-in
ORGANIZATIONS_ENABLED=true
NEXT_PUBLIC_ORGANIZATIONS_ENABLED=true

# Optional: comma-separated provider IDs to trust for automatic account linking.
# This applies to non-SSO providers only — SSO linking is authorized by the
# verified domain on the provider itself, not by this list.
SSO_TRUSTED_PROVIDER_IDS=custom-oidc,partner-saml

Quando alguém faz login por SSO e já existe uma conta com o mesmo e-mail (por exemplo, a pessoa se cadastrou antes com e-mail e senha), o Studio vincula a identidade de SSO a essa conta automaticamente. Essa vinculação é autorizada pelo domínio verificado associado ao provedor, então funciona tanto para OIDC quanto para SAML e não depende de o seu IdP informar email_verified.

Você pode registrar provedores pela interface de Settings (igual à nuvem) ou executando o script de registro diretamente no seu banco de dados.

Registro por script

Use isso quando precisar registrar um provedor de SSO sem passar pela interface — por exemplo, durante o deploy inicial ou em automação de CI/CD.

# OIDC example (Okta)
SSO_ENABLED=true \
NEXT_PUBLIC_APP_URL=https://your-instance.com \
SSO_PROVIDER_TYPE=oidc \
SSO_PROVIDER_ID=okta \
SSO_ISSUER=https://dev-1234567.okta.com/oauth2/default \
SSO_DOMAIN=company.com \
SSO_USER_EMAIL=admin@company.com \
SSO_OIDC_CLIENT_ID=your-client-id \
SSO_OIDC_CLIENT_SECRET=your-client-secret \
bun run packages/db/scripts/register-sso-provider.ts
# SAML example (ADFS)
SSO_ENABLED=true \
NEXT_PUBLIC_APP_URL=https://your-instance.com \
SSO_PROVIDER_TYPE=saml \
SSO_PROVIDER_ID=adfs \
SSO_ISSUER=https://your-instance.com \
SSO_DOMAIN=company.com \
SSO_USER_EMAIL=admin@company.com \
SSO_SAML_ENTRY_POINT=https://adfs.company.com/adfs/ls \
SSO_SAML_CERT="-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----" \
bun run packages/db/scripts/register-sso-provider.ts

O script imprime a callback URL para configurar no seu IdP quando termina.

Para remover um provedor:

SSO_USER_EMAIL=admin@company.com \
bun run packages/db/scripts/deregister-sso-provider.ts
Enterprise em auto-hospedagemDomínios verificados