> ## Documentation Index > Fetch the complete documentation index at: https://docs.devin.ai/llms.txt > Use this file to discover all available pages before exploring further. # Guia de onboarding do SSO > Guia completo para configurar o SSO, provisionar usuários e configurar grupos do IdP com Devin Enterprise. Este guia orienta administradores do Enterprise em todo o ciclo de vida do SSO com Devin — da configuração inicial à configuração de grupos do IdP — e explica suas opções de provisionamento de usuários. Para instruções de configuração específicas de cada provedor, consulte [Okta](/pt-BR/enterprise/security-access/sso/okta), [Microsoft Entra ID](/pt-BR/enterprise/security-access/sso/azure), [SAML](/pt-BR/enterprise/security-access/sso/saml) ou [OIDC genérico](/pt-BR/enterprise/security-access/sso/oidc). Para provisionamento automático, consulte [Configuração do SCIM](/pt-BR/enterprise/security-access/scim). ***

1. Configurando o SSO

Criando seu aplicativo de SSO

Crie um aplicativo no seu provedor de identidade (Okta, Microsoft Entra ID ou qualquer IdP compatível com SAML/OIDC) e compartilhe as seguintes credenciais com a sua equipe da Cognition: | Tipo de conexão | Protocolo | O que fornecer | | :- | :- | :- | | **Okta** | OIDC (Okta Workforce Identity) | domínio do Okta, ID do cliente, segredo do cliente, escopos | | **Microsoft Entra ID** | OIDC (Microsoft Entra ID) | domínio do Microsoft Entra ID, ID do cliente, segredo do cliente | | **SAML** | SAML 2.0 (qualquer IdP) | URL de login, certificado de assinatura X.509 | | **OIDC genérico** | OIDC | URL de descoberta, ID do cliente, segredo do cliente, escopos | Você também deve fornecer seus domínios de e-mail verificados para que o Devin saiba quais endereços de e-mail do seu IdP considerar confiáveis.

O que acontece após a configuração

Quando sua equipe da Cognition tiver as credenciais, ela configurará a conexão de SSO. Após a conclusão da configuração: 1. A conexão de SSO é vinculada ao seu ambiente Enterprise do Devin 2. **Associação automática ao fazer login** é ativada — qualquer usuário que se autenticar via SSO é adicionado automaticamente ao seu ambiente Enterprise 3. Seu(s) domínio(s) de e-mail são registrados como confiáveis — somente e-mails desses domínios são aceitos 4. **Atribuição de funções com base em grupos (RBAC)** é ativada — grupos do IdP enviados durante o login podem ser mapeados para funções no Devin Configurar o SSO não desativa, por si só, as conexões de login padrão (e-mail, GitHub, Google). Elas permanecem ativadas a menos que a opção **Disable default login connections** seja selecionada no momento da criação da conexão de SSO. Se o SSO precisar ser o único método de autenticação, peça à sua equipe da Cognition para selecionar essa opção ao configurar a conexão e, após a configuração, confirme com ela quais conexões de login continuam ativadas no seu ambiente Enterprise.

A experiência de login do usuário

1. O usuário acessa a URL do seu Devin 2. É redirecionado para o IdP configurado (Okta, Microsoft Entra ID etc.) 3. O usuário se autentica normalmente 4. O IdP envia ao Devin as informações do usuário e as associações a grupos 5. O Devin automaticamente: * Cria a conta do usuário se esse for o primeiro login dele (provisionamento just-in-time) * Atribui a ele a função padrão Enterprise Member * Sincroniza as associações a grupos do IdP — adiciona novos grupos e remove os obsoletos * Registra o login no log de auditoria do Enterprise ***

Administração self-service

Os itens a seguir estão disponíveis diretamente no webapp do Devin para os admins do Enterprise.

Gerenciamento de grupos do IdP

**Configurações → Enterprise → Associação**, na aba **Grupos (IdP)** * Visualize todos os grupos sincronizados a partir dos logins de usuários * Atribua um grupo a uma função no nível Enterprise (por exemplo, "Todos em `Engineering-Admins` recebem a função de Enterprise Admin") * Atribua um grupo a orgs específicas com funções específicas (por exemplo, "`Team-Backend` recebe acesso de Membro na org Backend") * Adicione/remova grupos em massa em várias orgs * Visualize em quantas orgs cada grupo está atribuído

Gerenciamento de membros

**Configurações → Enterprise → Associação**, na aba **Membros** * Visualize todos os membros do Enterprise, incluindo suas associações com grupos do IdP * Convide novos membros por e-mail * Atualize as funções dos membros * Remova membros

Funções personalizadas

**Configurações → Enterprise → Associação**, na aba **Funções** * Crie funções personalizadas com permissões granulares * Atribua funções personalizadas a usuários específicos ou a grupos do IdP Consulte [Funções personalizadas e RBAC](/pt-BR/enterprise/security-access/custom-roles) para mais detalhes.

API para automação

O Devin oferece uma [API V3](/pt-BR/api-reference/v3/overview) que você pode usar para automatizar o gerenciamento de membros e grupos: | Ação | Endpoint da API | | :- | :- | | Listar membros com funções atribuídas diretamente | [`GET /v3/enterprise/members/users`](/pt-BR/api-reference/v3/users/members-users) | | Listar membros cujas funções são atribuídas por grupos do IdP | [`GET /v3/enterprise/members/idp-users`](/pt-BR/api-reference/v3/users/members-idp-users) | | Convidar usuários por e-mail em massa | [`POST /v3/enterprise/members/users`](/pt-BR/api-reference/v3/users/post-members-users) | | Remover um membro | [`DELETE /v3/enterprise/members/users/{user_id}`](/pt-BR/api-reference/v3/users/delete-members-users) | | Atualizar a função Enterprise de um membro | [`PATCH /v3/enterprise/members/users/{user_id}`](/pt-BR/api-reference/v3/users/patch-members-users) | | Listar todas as funções | [`GET /v3/enterprise/roles`](/pt-BR/api-reference/v3/roles/roles) | | Registrar grupos do IdP antes do primeiro login | [`POST /v3/enterprise/idp-groups`](/pt-BR/api-reference/v3/idp-groups/post-enterprise-idp-groups) | | Listar grupos do IdP registrados | [`GET /v3/enterprise/idp-groups`](/pt-BR/api-reference/v3/idp-groups/enterprise-idp-groups) | | Listar grupos do IdP com suas atribuições de função | [`GET /v3/enterprise/members/idp-groups`](/pt-BR/api-reference/v3/idp-groups/members-idp-groups) | | Atribuir uma função Enterprise a um grupo | [`POST /v3/enterprise/members/idp-groups/{idp_group_name}`](/pt-BR/api-reference/v3/idp-groups/post-members-idp-groups) | | Atribuir uma função a um grupo em uma org | [`POST /v3/enterprise/organizations/{org_id}/members/idp-groups/{idp_group_name}`](/pt-BR/api-reference/v3/idp-groups/post-organizations-members-idp-groups) | V1 e V2 foram descontinuadas. Use a V3 para todas as novas automações — consulte o [guia de migração](/pt-BR/api-reference/getting-started/migration-guide). ***

2. Opções de provisionamento de usuário

O Devin oferece suporte a dois modelos de provisionamento.

Opção A: Provisionamento baseado em login

Sem SCIM, todo o gerenciamento de usuários e grupos acontece por meio de eventos de login via SSO e da UI/API do Devin: 1. **Provisionamento just-in-time** — os usuários são criados automaticamente no primeiro login via SSO com a função padrão do Enterprise 2. **Sincronização completa de grupos a cada login** — sempre que um usuário faz login, o Devin faz um diff completo dos grupos do IdP: adiciona os novos e remove os antigos 3. **RBAC baseado em grupos** — é possível mapear grupos do IdP para funções do Enterprise e acesso à org nas Configurações do Devin, com efeito no próximo login 4. **API V3 para automação** — convites, remoções e alterações de função podem ser automatizados por script para fechar a lacuna de provisionamento/desprovisionamento 5. **Logs de auditoria** — todo login é registrado, dando visibilidade sobre quem acessou o Devin Veja como o provisionamento baseado em login se compara ao SCIM na prática.

Provisionamento de usuário: somente no login

| | Com SCIM | Baseado em login | | :- | :- | :- | | **Como os usuários são criados** | O IdP cria o usuário no Devin imediatamente quando o app é atribuído ao usuário | O usuário só passa a existir no Devin após o primeiro login com SSO — ou após um convite manual pela UI ou API | | **Quando isso acontece** | O administrador atribui o app ao usuário → o usuário aparece em segundos | O administrador atribui o app ao usuário → nada acontece no Devin até ele fazer login | | **Pré-provisionamento** | A conta do usuário fica pronta antes mesmo de ele acessar o app | Não há pré-provisionamento, a menos que o administrador o convide explicitamente pela UI ou API do Devin | Ao integrar novos funcionários, o administrador pode convidá-los com antecedência (**Configurações → Enterprise → Associação → Membros → Convidar membros**, ou pela API) ou simplesmente deixar que sejam provisionados automaticamente no primeiro login.

Desprovisionamento de usuários: apenas manual

| | Com SCIM | Baseado em login | | :- | :- | :- | | **Como os usuários são removidos** | O IdP desativa/remove o usuário → o Devin remove imediatamente sua associação à Enterprise | Desativar/remover um usuário no IdP não faz nada no Devin | | **Desligamento** | O funcionário desligado perde a associação à Enterprise em minutos | O funcionário desligado mantém o acesso até ser removido manualmente do Devin e sua sessão expirar | | **Conformidade** | Conformidade automatizada — sem contas órfãs | Risco de contas órfãs, a menos que o administrador mantenha os dois sistemas | Esta é a maior lacuna operacional do provisionamento baseado em login. Ao desligar um funcionário, o administrador deve removê-lo separadamente do Devin (**Configurações → Enterprise → Associação → Membros**, selecione o membro e depois **Remover membros**, ou via API). Use o SCIM para automatizar isso.

Sincronização de grupos: apenas no login, não em tempo real

| | Com SCIM (Group Push) | Baseado em login | | :- | :- | :- | | **Momento da sincronização** | O IdP envia as alterações de associação a grupos em tempo real | Os grupos só são sincronizados quando o usuário faz login | | **Adicionar a um grupo** | O Admin adiciona o usuário ao grupo → Devin reflete isso imediatamente | O Admin adiciona o usuário ao grupo → Devin só fica sabendo no próximo login do usuário | | **Remover de um grupo** | O Admin remove o usuário do grupo → Devin reflete isso imediatamente | O Admin remove o usuário do grupo → Devin continua mostrando a associação antiga até o próximo login | | **Fonte de verdade** | O IdP é sempre a fonte de verdade | O IdP só é a fonte de verdade no momento do login — pode haver divergências entre logins | Se um admin alterar o grupo de alguém no IdP (p. ex., movê-lo de Engenharia para Vendas), Devin não refletirá essa mudança até que o usuário faça login novamente. Enquanto isso, o usuário mantém suas funções baseadas em grupo e o acesso antigo à org.

Opção B: Provisionamento SCIM

O Devin oferece suporte ao SCIM 2.0 para provisionamento automático e em tempo real pelo seu IdP: * **Pré-provisionamento** — os usuários são criados no Devin assim que são atribuídos ao app, antes do primeiro login * **Desprovisionamento automático** — desativar ou remover a atribuição de um usuário no IdP remove imediatamente sua associação à Enterprise * **Sincronização de grupos em tempo real** — as alterações na associação a grupos são enviadas assim que ocorrem, sem esperar pelo próximo login Consulte [Configuração do SCIM](/pt-BR/enterprise/security-access/scim) para ver as instruções de configuração. ***

3. Configuração de grupos gerenciados pelo IdP

Esta seção explica como funciona o modelo de grupos do Devin e como configurar corretamente seu IdP para a sincronização de grupos no login. Se você usa [SCIM](/pt-BR/enterprise/security-access/scim), os grupos são enviados pelo seu IdP, e essa configuração de declaração não é necessária.

Contexto: Como o Devin usa Grupos do IdP

O IdP é a fonte de verdade. Os grupos são definidos no diretório do IdP, e as associações aos grupos são repassadas ao Devin por meio de claims SAML/OIDC no momento do login ou por envio de grupos via SCIM. O principal é garantir que os grupos corretos estejam sendo enviados pelo seu IdP e mapeados corretamente no Devin.

Etapa 1: Definir grupos no IdP

No console de administração do seu IdP (os exemplos abaixo usam o Okta): 1. Vá para **Directory → Groups** 2. Crie grupos que correspondam aos níveis de acesso do Devin (por exemplo, `Devin-Engineering`, `Devin-Admins`, `Devin-DataScience`) 3. Atribua usuários a esses grupos Esses são grupos nativos do IdP — seu IdP é a fonte de verdade sobre quem pertence a qual grupo.

Etapa 2: Configurar as claim de grupo no app do IdP

Os grupos devem ser incluídos na resposta de autenticação para que o Devin possa lê-los.

Para conexões SAML

1. Vá para **Applications → \[Devin App] → SAML Settings → Edit** 2. Em **Group Attribute Statements**, adicione: * **Name:** `groups` * **Filter:** "Starts with" → `Devin-` (ou use "Matches regex" para padrões mais complexos) 3. Isso instrui o IdP a incluir os nomes dos grupos correspondentes na asserção SAML

Para conexões OIDC

1. Vá para **Applications → \[Devin App] → Sign On → Edit** 2. Em **OpenID Connect ID Token → Groups claim type**, selecione "Filter" 3. Configure o filtro para corresponder aos grupos do Devin (por exemplo, "Starts with" → `Devin-`) Use um prefixo de filtro como `Devin-` para que apenas os grupos relevantes sejam enviados. Não é necessário enviar todos os grupos do IdP da organização.

Etapa 3: Mapear grupos para funções e org no Devin

Quando os grupos passarem a ser enviados no login, faça o mapeamento deles no Devin.

Na UI do Devin

1. **Configurações → Enterprise → Associação**, em seguida selecione a aba **Grupos (IdP)** 2. Os grupos aparecem automaticamente depois que qualquer membro do grupo faz login 3. Clique em um grupo → atribua a ele uma função no nível Enterprise (por exemplo, Enterprise Admin ou uma função personalizada) 4. Clique em um grupo → atribua-o a org específicas com funções específicas no nível da org

Pela API (para configuração prévia ou automação)

* Registre grupos antes que alguém faça login: [`POST /v3/enterprise/idp-groups`](/pt-BR/api-reference/v3/idp-groups/post-enterprise-idp-groups) * Atribua uma função Enterprise a um grupo registrado: [`POST /v3/enterprise/members/idp-groups/{idp_group_name}`](/pt-BR/api-reference/v3/idp-groups/post-members-idp-groups) * Atribua um grupo registrado a uma org com uma função no nível da org: [`POST /v3/enterprise/organizations/{org_id}/members/idp-groups/{idp_group_name}`](/pt-BR/api-reference/v3/idp-groups/post-organizations-members-idp-groups) * Liste os grupos e as funções atribuídas a eles: [`GET /v3/enterprise/members/idp-groups`](/pt-BR/api-reference/v3/idp-groups/members-idp-groups) Os nomes dos grupos devem corresponder exatamente aos nomes enviados pelo seu IdP na asserção de login; um grupo registrado só começa a conceder acesso quando um de seus membros faz login.

Etapa 4: Se estiver migrando de grupos SCIM em outros apps

Se você estiver mudando sua estratégia geral de IdP de grupos gerenciados por SCIM para grupos gerenciados pelo IdP em todas as suas ferramentas (não apenas no Devin): 1. **Interrompa a importação de grupos via SCIM** nos outros apps: * No IdP: vá para a aba **Provisioning → Integration** do app → desmarque "Import Groups" * Isso faz com que o app de destino deixe de ser a fonte de verdade para os grupos 2. **Crie grupos correspondentes** no diretório do IdP: * Vá para **Directory → Groups** e crie grupos que espelhem o que existia no app de destino * Atribua usuários a esses grupos nativos do IdP 3. **Configure o Group Push** (para apps que oferecem suporte): * Na configuração de IdP do app: aba **Push Groups** → encontre os grupos pelo nome → vincule-os aos grupos existentes no app de destino * Isso faz com que o IdP sobrescreva a associação interna do app — o IdP passa a ser a única fonte de verdade * Para sincronização de grupos baseada em login, o Devin não precisa de Group Push porque lê os grupos diretamente da asserção de login. (Se você provisiona o Devin via [SCIM](/pt-BR/enterprise/security-access/scim), faça push dos grupos na aba **Push Groups**.) 4. **Desative a sincronização de grupos via SCIM** nos outros apps: * Garanta que "Import Groups" permaneça desativado para impedir que o app de destino volte a se afirmar como fonte de verdade Para o Devin especificamente, nenhuma migração é necessária. Apenas garanta que as Etapas 1–3 acima tenham sido concluídas (grupos definidos no seu IdP, claims configuradas e mapeamentos definidos no Devin). ***

Considerações principais

Para grupos sincronizados por login, uma renomeação é tratada como um novo grupo — os mapeamentos de função do grupo antigo não são transferidos automaticamente, e será necessário reconfigurar o novo nome do grupo nas Configurações do Devin. Os grupos renomeados via SCIM mantêm seus mapeamentos. Sem SCIM, um usuário adicionado a um grupo do IdP mapeado no Devin só terá esse acesso quando fizer login. Sem SCIM, remover um usuário de um grupo do IdP não revoga imediatamente seu acesso ao Devin. No próximo login, Devin sincroniza e remove a associação ao grupo obsoleta. Qualquer associação direta (atribuída fora dos grupos) não é afetada. O nome do grupo no IdP deve corresponder exatamente ao que Devin vê. Diferencia letras maiúsculas de minúsculas. Devin não oferece suporte a grupos aninhados/hierárquicos. Se o IdP enviar um grupo pai, os membros dos grupos filhos não serão incluídos automaticamente. Cada grupo deve ser atribuído explicitamente. *** Se não for possível usar o [SCIM](/pt-BR/enterprise/security-access/scim), siga esta abordagem para ter o maior controle possível: 1. Defina grupos: `Devin-Admins`, `Devin-Backend`, `Devin-Frontend`, etc. 2. Atribua usuários aos grupos 3. Configure claims de grupo SAML/OIDC filtradas por "Começa com: `Devin-`" Quando um usuário faz login via SSO, o Devin automaticamente: * Cria o usuário automaticamente, se ele for novo * Executa uma sincronização completa dos grupos (adiciona novos grupos e remove os obsoletos) * Aplica imediatamente os mapeamentos de grupo para função e de grupo para org Configure uma tarefa agendada para cobrir as lacunas do SCIM: 1. Leia os usuários ativos da API do seu IdP 2. Leia os membros do Devin em [`GET /v3/enterprise/members/users`](/pt-BR/api-reference/v3/users/members-users) 3. Convide novos funcionários via [`POST /v3/enterprise/members/users`](/pt-BR/api-reference/v3/users/post-members-users) 4. Remova funcionários desligados via [`DELETE /v3/enterprise/members/users/{user_id}`](/pt-BR/api-reference/v3/users/delete-members-users) Isso oferece provisionamento e desprovisionamento no modelo push sem SCIM.

O que isso proporciona

* Seu IdP como fonte única de verdade para a estrutura e a associação de grupos * Acesso automático baseado em grupos em todos os logins * Provisionamento/desprovisionamento via API para suprir a lacuna que o SCIM normalmente preencheria * Trilha de auditoria completa para todos os logins e alterações de associação

Limitações do provisionamento baseado em login

* **Sem sincronização de grupos em tempo real entre logins** — os grupos só são atualizados quando os usuários fazem login * **Sem desprovisionamento automático** — remover um usuário do IdP não tem efeito até que você o remova manualmente do Devin * **Sem eventos de ciclo de vida iniciados pelo IdP**, como suspensão/reativação Com o [SCIM](/pt-BR/enterprise/security-access/scim), as alterações nos grupos são sincronizadas em tempo real, e o desprovisionamento remove imediatamente a associação à Enterprise — sem esperar por um login. Em ambos os modelos, as sessões existentes permanecem ativas até expirarem. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.