--- title: "Configurar SSO com o Google Workspace" description: "Registre uma conexão SAML ou OIDC do Bird no Google Workspace, desative a assinatura de resposta, habilite o acesso de usuários e leve em conta o atraso de configuração do Google." canonical: "https://bird.com/pt-br/documentacao/knowledge-base/account-security/sso-google-workspace" --- # Configurar SSO com o Google Workspace Esta página cobre a parte do Google Workspace de 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). O Google e o Bird precisam de valores um do outro, então por onde você começa depende do protocolo. Mantenha ambos abertos enquanto trabalha. Dois comportamentos do Google causam a maioria das falhas no primeiro teste, e nenhum deles reporta nada ao Bird: - **Ative o acesso de usuários antes de testar.** Um novo app SAML personalizado começa desativado para todos. Até você habilitá-lo para as pessoas que farão login, o Google recusa do próprio lado e a janela de teste não mostra nada. - **Aguarde alguns minutos após salvar.** O Google aplica alterações em um app SAML (assinatura de resposta, formato do Name ID, acesso de usuários) após um atraso de aproximadamente dois a quatro minutos. Um teste executado dentro dessa janela reporta a configuração anterior, o que parece ser um problema do Bird, mas não é. ## SAML Comece no 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 a **Supply the details**. [Configurar SAML sem valores provisórios](/docs/knowledge-base/account-security/sso) descreve esse fluxo. O Google não publica uma URL de metadados para um app SAML personalizado. Baixe o arquivo de metadados no console do Google Admin e cole o conteúdo em **Supply the details** na conexão do Bird, escolhendo a opção de documento de metadados. Os nomes dos campos do Google não correspondem aos do Bird: | No Bird, em **Register these with your identity provider** | No Google Workspace | | ---------------------------------------------------------- | -------------------- | | Assertion Consumer Service URL | ACS URL | | Entity ID | Entity ID | | Sign-in URL for this connection | Start URL (optional) | ### Desativar Signed response Deixe **Signed response** desmarcado. Com ele marcado, o Google assina a resposta e deixa a assertion interna sem assinatura, e o Bird verifica a assinatura da própria assertion, fazendo com que todo login seja recusado com um erro de assinatura que parece um problema de certificado. Ao desmarcar, a assertion volta a ser assinada e os logins funcionam. ### Identificar membros pelo endereço de e-mail Defina **Name ID format** como `EMAIL`. Os outros formatos do Google não funcionam com Bird: - `UNSPECIFIED` é recusado diretamente. - `PERSISTENT` é recusado porque o formato não corresponde ao esperado pela conexão. O Google envia o endereço de e-mail do membro como valor de qualquer forma, então não é o identificador opaco e nunca reatribuído que um formato persistente deveria carregar. O Google não oferece um identificador opaco para o NameID, então `EMAIL` é a única opção utilizável aqui. Isso torna o endereço permanente para qualquer pessoa que fizer login por essa conexão: se a sua organização reatribuir esse endereço, a próxima pessoa que o receber herda a conta do Bird. Leia [Como membros são identificados](/docs/knowledge-base/account-security/sso) antes de contar com isso. ### Validade da assertion e certificados O Google assina assertions válidas de cinco minutos antes da emissão até cinco minutos depois, o que o Bird aceita. O Google gerencia o certificado de assinatura e sua data de expiração, e não oferece controle de rotação em um app SAML personalizado. Anote a expiração exibida na conexão do Bird e planeje substituir os metadados antes que ela passe, porque todo login pela conexão falha no dia em que isso acontece. ## OIDC Comece no console do Google Cloud 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 Google primeiro. A **Redirect URI** do Bird é a mesma para toda conexão e é exibida em **Add connection** antes de você criar qualquer coisa, então você pode registrá-la antecipadamente. Crie credenciais de cliente OAuth no console do Google Cloud para o projeto que atende seus usuários do Workspace, e copie o client ID e o secret para o Bird com `https://accounts.google.com` como **Issuer**. O Bird lê o documento de descoberta a partir daí e se autentica no endpoint de token com `client_secret_basic`. Registre a **Redirect URI** do Bird como um redirect URI autorizado no client. O caminho OIDC do Google não tem etapa de tile de app: um client OAuth personalizado não aparece no launcher de apps do Google, então os membros começam pela página de login do Bird ou por um link que você forneça. ## 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 o Okta](/docs/knowledge-base/account-security/sso-okta) - [Configurar SSO com o Microsoft Entra ID](/docs/knowledge-base/account-security/sso-microsoft-entra-id) ## 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)