---
title: Single sign-on
url: https://platform.claude.com/docs/pt-BR/managed-agents/self-hosted/configure
description: Permita que pessoas e serviços chamem o seu servidor do Claude Managed Agents auto-hospedado com tokens do seu provedor de identidade.
---

<Note>
  Para solicitar acesso ao Claude Managed Agents auto-hospedado, entre em contato com a equipe da sua conta na Anthropic.
</Note>

Por padrão, o seu servidor aceita uma chave compartilhada, a [chave de API do servidor](https://platform.claude.com/docs/pt-BR/managed-agents/self-hosted#the-three-credentials). Com single sign-on, cada pessoa ou serviço também pode chamar o servidor com um token do seu provedor de identidade OpenID Connect (OIDC). O servidor atribui ao chamador uma função a partir dos grupos no token. A chave de API do servidor continua funcionando como credencial de administrador.

Esta página mostra como adicionar o seu provedor de identidade, o que cada função pode fazer e como permitir que desenvolvedores façam login a partir de um terminal.

## Adicione o seu provedor de identidade

<Steps>
  <Step title="Registre o servidor no seu provedor de identidade">
    Registre o servidor como uma API com um identificador como `api://cma-server` e faça com que os clientes solicitem tokens para ele.
  </Step>

  <Step title="Liste o provedor de identidade no arquivo de configurações">
    Adicione uma entrada em `auth.issuers` no [arquivo de configurações](https://platform.claude.com/docs/pt-BR/managed-agents/self-hosted/configuration-reference#where-settings-go):

    ```yaml
    auth:
      issuers:
        - name: okta
          issuer_url: https://login.example.com/oauth2/default
          audiences: [api://cma-server]
          roles:
            - group: cma-admins
              role: admin
            - group: "eng-*"
              role: developer
    ```

    * `name` rotula o emissor nas linhas de log, e o servidor o registra como parte do criador de cada recurso. Não o altere depois que as pessoas tiverem criado recursos.
    * `issuer_url` precisa ser igual à claim `iss` dos seus tokens.
    * `audiences` lista os valores que a claim `aud` de um token pode conter, como o identificador da primeira etapa.
    * `roles` mapeia um grupo para `admin`, `developer` ou `user`. A função mais alta correspondente prevalece.

    Para os outros campos, consulte [Entradas de emissor](https://platform.claude.com/docs/pt-BR/managed-agents/self-hosted/configuration-reference#issuer-entries). Se o seu provedor for o Microsoft Entra ID, consulte também [Microsoft Entra ID](https://platform.claude.com/docs/pt-BR/managed-agents/self-hosted/configure#microsoft-entra-id).
  </Step>

  <Step title="Reinicie o servidor e verifique o login">
    Reinicie o servidor. Um chamador envia o token como `Authorization: Bearer <token>`, em qualquer rota que aceite a chave de API do servidor.

    Para toda requisição que um token autenticou, o servidor registra em log `auth=oidc`, o `name` do emissor e o subject do chamador (`sub=`).
  </Step>
</Steps>

### Se o login falhar

| Resposta                                        | Causa                                                            | A linha de log do servidor contém |
| ----------------------------------------------- | ---------------------------------------------------------------- | --------------------------------- |
| `401`, o mesmo que para uma chave de API errada | O token falhou em uma verificação. A linha de log traz o motivo. | `oidc token`                      |
| `403`                                           | Os grupos do token não correspondem a nenhuma entrada de `roles` | `token holds no role`             |

### Microsoft Entra ID

O Entra ID difere de outros provedores de duas maneiras. Ambas as configurações ficam na entrada do emissor:

* **A pessoa:** O Entra ID dá a uma pessoa um `sub` diferente em cada aplicação cliente, então o padrão registraria uma pessoa como vários criadores. Defina `subject_claim: oid`.
* **Os grupos:** O Entra ID deixa a claim `groups` de fora de um token se a pessoa pertencer a muitos grupos. Essa pessoa então não corresponde a nenhuma entrada de `roles`. Para evitar isso, faça com que o Entra ID emita apenas os grupos atribuídos à aplicação. Ou atribua funções de aplicativo às pessoas no Entra ID e defina `groups_claim: roles` para que o servidor leia as funções de aplicativo no lugar dos grupos.

## O que cada função pode fazer

| Função                               | Agentes, skills, sessões, vaults e memory stores | Ambientes                                               |
| ------------------------------------ | ------------------------------------------------ | ------------------------------------------------------- |
| `admin` e a chave de API do servidor | Vê e altera tudo                                 | Cria, altera e exclui ambientes, e cria as chaves deles |
| `developer` ou `user`                | Vê e altera apenas o que esse chamador criou     | Lista, lê e executa sessões neles                       |

`developer` e `user` têm o mesmo acesso. Um chamador com qualquer uma dessas funções:

* **Não pode ver um recurso que outra pessoa criou.** O recurso não aparece nas listas, e uma requisição pelo seu ID recebe a mesma resposta que uma requisição por um ID desconhecido. Isso inclui tudo o que foi criado com a chave de API do servidor antes de você ativar o single sign-on.
* **Não pode compartilhar um recurso** com outro chamador ou com um grupo.

Mapeie `admin` para nomes de grupo exatos. Um administrador também pode iniciar uma sessão que usa o vault de qualquer usuário. Então atribua a função apenas a grupos a quem você confiaria os tokens MCP de todos os usuários.

## Permita que desenvolvedores façam login a partir de um terminal

Os desenvolvedores podem fazer login pelo seu provedor de identidade e depois usar a CLI `ant` com a própria identidade, sem a chave de API do servidor. Você executa as duas primeiras etapas, e cada desenvolvedor executa a terceira.

<Steps>
  <Step title="Registre uma aplicação no seu provedor de identidade">
    Registre uma aplicação nativa (“pública”) que tenha:

    * Nenhum client secret
    * A concessão de código de autorização com PKCE
    * O URI de redirecionamento `http://127.0.0.1/callback`

    Alguns provedores precisam de um dos [outros URIs de redirecionamento](https://platform.claude.com/docs/pt-BR/managed-agents/self-hosted/configure#other-redirect-uris).
  </Step>

  <Step title="Adicione a aplicação à entrada do emissor">
    Adicione `login_client_id` e `login_scopes` à entrada do emissor e reinicie o servidor:

    ```yaml
    login_client_id: 0oa1b2c3d4e5f6g7h8i9
    login_scopes: [openid, cma-server.access]
    ```

    `login_scopes` lista os escopos de que o seu provedor precisa para emitir um token cuja claim `aud` esteja na lista `audiences` da entrada do emissor.
  </Step>

  <Step title="Faça login">
    Cada desenvolvedor executa o login a partir do nível superior do arquivo compactado extraído:

    ```bash
    ./cma-server-admin login https://cma.example.com
    ```

    A URL do servidor precisa ser `https://`, ou `http://` para `localhost`, `127.0.0.1` ou `::1`. Com um dos [outros URIs de redirecionamento](https://platform.claude.com/docs/pt-BR/managed-agents/self-hosted/configure#other-redirect-uris), adicione a flag correspondente ao comando.

    O comando abre a página de login do provedor em um navegador e depois grava um perfil da CLI `ant` chamado `cma-server`. Passe `--profile cma-server` para qualquer comando `ant`, ou execute `ant profile activate cma-server` para tornar o perfil o padrão.
  </Step>
</Steps>

Quando o token expirar, o desenvolvedor executa `login` novamente. Para que a CLI `ant` renove o token em vez disso, adicione `offline_access` a `login_scopes`.

### Outros URIs de redirecionamento

| Provedor                                        | URI de redirecionamento a registrar                              | Flag que os desenvolvedores adicionam ao comando `login` |
| ----------------------------------------------- | ---------------------------------------------------------------- | -------------------------------------------------------- |
| Microsoft Entra ID                              | `http://localhost/callback`                                      | `-listen localhost:0`                                    |
| Um que exige a porta no URI de redirecionamento | Um URI com uma porta fixa, como `http://127.0.0.1:8123/callback` | `-listen 127.0.0.1:8123`                                 |

Para listar as outras flags, adicione `-h` ao comando `login`.

## Permita que as pessoas façam login no console do seu servidor

O console do seu servidor faz o login das pessoas pela aplicação que você registrou para o [login pelo terminal](https://platform.claude.com/docs/pt-BR/managed-agents/self-hosted/configure#let-developers-log-in-from-a-terminal). Para concluir a configuração dele, consulte [Configurar o login](https://platform.claude.com/docs/pt-BR/managed-agents/self-hosted/console#set-up-sign-in).