--- title: "Configurar SSO com Microsoft Entra ID" description: "Registre uma conexão SAML ou OIDC do Bird no Microsoft Entra ID, defina o formato de NameID que o Entra omite, preencha o atributo mail e entenda a atribuição de aplicativo." canonical: "https://bird.com/pt-br/documentacao/knowledge-base/account-security/sso-microsoft-entra-id" --- # Configurar SSO com Microsoft Entra ID Esta página cobre a parte do Entra em uma conexão SSO. A parte do Bird (verificar um domínio, testar, ativar e exigir SSO) é igual para todos os provedores e está em [SSO e provisionamento](/docs/knowledge-base/account-security/sso). Entra e Bird precisam de valores um do outro, então por onde você começa depende do protocolo. Mantenha os dois abertos enquanto trabalha. ## SAML Comece pelo Bird para SAML. O Entity ID e a Assertion Consumer Service URL de uma conexão SAML derivam da própria conexão, então crie-a com **I have not set up my provider yet**, registre os valores exibidos e volte para **Supply the details**. [Configurar SAML sem valores provisórios](/docs/knowledge-base/account-security/sso) descreve esse fluxo. Os nomes dos campos do Entra não correspondem aos do Bird: | No Bird, em **Register these with your identity provider** | No Microsoft Entra ID | | ---------------------------------------------------------- | ------------------------------------------ | | Assertion Consumer Service URL | Reply URL (Assertion Consumer Service URL) | | Entity ID | Identifier (Entity ID) | | Sign-in URL for this connection | Sign on URL | Preencher ou não o campo **Sign on URL** define o comportamento do bloco My Apps. Se você preenchê-lo, o bloco inicia o login no Bird, que então solicita uma asserção ao Entra. Se deixá-lo vazio, o bloco envia uma asserção diretamente para Bird. Bird aceita ambas as formas, desde que a conexão permita login iniciado pelo provedor de identidade. ### Defina o formato de NameID você mesmo Os metadados de federação do Entra não anunciam nenhum formato de NameID. O Bird lê o formato dos metadados quando o provedor publica um, então uma conexão com o Entra é vinculada a um identificador permanente por padrão, e o primeiro teste falha porque o formato que o Entra realmente envia não corresponde. Abra **Edit** na conexão e defina **Identify members by** como o endereço de e-mail do membro antes de executar o primeiro teste. No Entra, defina a claim **Unique User Identifier (Name ID)** como `user.mail`, com o formato do identificador de nome definido como Email address. Okta e Google anunciam um formato, então essa etapa é específica do Entra. ### Desative Sign SAML response Deixe **Sign SAML response** desativado para que o Entra assine a asserção em vez da resposta que a envolve. Com a assinatura de resposta ativada, a asserção interna fica sem assinatura e o Bird recusa todo login com um erro de assinatura que parece um problema de certificado. ### Validade da asserção e rotação de certificado O Entra assina asserções válidas de cinco minutos antes da emissão até 60 minutos depois, uma janela mais ampla que a do Okta ou do Google, que o Bird aceita. Faça a rotação com sobreposição. Adicione o novo certificado à conexão do Bird enquanto ela ainda contém o antigo, ative o novo certificado no Entra e então remova o antigo do Bird. Remover o certificado antigo antes de o Entra ter ativado o novo recusa todo login até que os dois estejam de acordo. Os client secrets e certificados de assinatura do Entra expiram. Anote as datas e planeje a substituição; um login com uma credencial expirada falha no mesmo dia. ## OIDC Comece pelo portal do Entra para OIDC. O Bird precisa do issuer, do client ID e do client secret para criar uma conexão OIDC, então registre o aplicativo no Entra primeiro. O **Redirect URI** do Bird é o mesmo para toda conexão e aparece em **Add connection** antes de você criar qualquer coisa, então você pode registrá-lo antecipadamente. Registre um aplicativo no Entra, adicione um client secret e copie o client ID e o secret para o Bird. Use o issuer **específico do tenant**, o issuer `v2.0` que contém o id do seu tenant. Não use o endpoint multi-tenant `common`: seu documento de descoberta descreve o issuer como um template em vez de um valor, e uma conexão construída a partir dele falha em todo login. Bird se autentica no endpoint de token com `client_secret_basic`. Registre o **Redirect URI** do Bird como um redirect URI no registro do aplicativo. ### Preencha o atributo mail de cada membro O Bird lê o endereço do membro a partir da claim `email` do ID token. O Entra emite essa claim apenas quando o atributo **mail** do usuário está preenchido, em Contact information no perfil do Entra. Um tenant cujos usuários não têm caixa de correio (uma organização usando outro provedor de e-mail) geralmente deixa esse campo vazio, e o teste do Bird reporta que nenhum endereço de e-mail chegou, mesmo que o nome principal do usuário seja um endereço perfeitamente válido. Preencha **mail** para cada membro que fará login pelo Bird. ### O bloco My Apps Para o bloco aparecer, defina o **Home page URL** do registro do aplicativo como o Initiate login URI da conexão no Bird, defina **Visible to users** como Yes e atribua o usuário. Sem um home page URL, o bloco fica oculto. ### A atribuição de aplicativo não restringe quem acessa o Bird Definir **Assignment required** no aplicativo do Entra não impede, por si só, que um membro não atribuído faça login no Bird via OIDC. O Bird solicita os escopos padrão `openid` e `email`, que o Entra trata como permissões do Microsoft Graph, então o Entra avalia a atribuição em relação ao Graph, e não em relação ao seu aplicativo Bird. Para que o Entra aplique a atribuição, e o acesso condicional com escopo de aplicativo junto, exponha um escopo no registro do aplicativo em **Expose an API** e peça ao Bird para solicitá-lo na conexão. Até lá, os membros que podem acessar sua organização por essa conexão são aqueles cujo endereço está em um dos domínios verificados. Isso se aplica ao caminho OIDC. Um aplicativo SAML é seu próprio recurso no Entra, então a atribuição é avaliada diretamente nele. ## Próximos passos - [SSO e provisionamento](/docs/knowledge-base/account-security/sso): verificar um domínio, testar a conexão e exigir SSO - [Configurar SSO com Okta](/docs/knowledge-base/account-security/sso-okta) - [Configurar SSO com Google Workspace](/docs/knowledge-base/account-security/sso-google-workspace) ## Related resources - [Should I use an API key or an OAuth token, and how do I rotate one?](/explained/platform/api-key-or-oauth-token-and-how-do-i-rotate-one) (answer) - [Authentication & API keys](/docs/guides/authentication) (docs) [Get an implementation brief](/learn/workspace?topic=account-access)