Permita o login das pessoas com seu provedor de identidade

O que faz

• Uma conexão por organização. Um administrador da organização a configura em Configurações da organização do dashboard, em Login único.
• Seus domínios decidem quem o usa. A página de login pede o e-mail primeiro. Um endereço em um dos seus domínios verificados segue para o seu provedor.
• Seu provedor decide quem entra. Uma pessoa cujo endereço nenhuma conta tem é criada no primeiro login, a menos que você desative Create accounts at first sign-in na conexão. Uma pessoa nova não tem projeto até que um convite ou um grupo provisionado lhe dê um.
• Suas pessoas são membros. Uma pessoa que entra pelo seu provedor é membro da sua organização. Somente o seu provedor a remove.
• Require single sign-on recusa senhas e passkeys nos seus domínios.

Antes de começar

• Você é administrador da organização.
• A organização tem um domínio verificado. Em Configurações da organização, em Domínios verificados, informe-o em Adicionar um domínio, escolha Obter registro DNS, publique o registro TXT exibido e escolha Verificar example.com (seu próprio domínio no lugar). Mantenha o registro no lugar: o screenRIG o verifica diariamente e remove um domínio cujo registro fica ausente por 7 dias, e o login único deixa de funcionar para os endereços dele.
• As alterações na conexão pedem sua passkey ou senha. Uma sessão de login único conta, em vez disso, como login recente por 10 minutos, mas apenas quando o seu provedor informa quando a pessoa se autenticou (auth_time no OpenID Connect, AuthnInstant no SAML). Caso contrário, o screenRIG pede que a pessoa entre de novo no provedor antes da alteração.

Seu provedor pede estes valores:

Cada conexão tem seu próprio redirect URI, porque o ID da conexão faz parte do endereço. Depois de salvar uma conexão, as configurações de Login único em Configurações da organização mostram o valor exato de cada um em Valores para o seu provedor de identidade, com o ID da sua conexão já preenchido.

Microsoft Entra ID

A predefinição do Entra faz o login das pessoas de um único tenant por OpenID Connect.

1. No Microsoft Entra admin center, abra App registrations e escolha New registration. Dê um nome e escolha Accounts in this organizational directory only. Deixe o redirect URI vazio: a etapa 6 o adiciona.
2. Abra Certificates & secrets, crie um client secret e copie agora o Value dele, não o ID.
3. Abra Token configuration, escolha Add optional claim, escolha o tipo ID e adicione email e, ao lado dele, auth_time. Sem auth_time, o Entra não informa quando a pessoa se autenticou, e uma ação sensível envia a pessoa de volta ao Entra para entrar de novo (veja O que as pessoas veem).
4. Em Overview, copie o Application (client) ID e o Directory (tenant) ID.
5. Em Configurações da organização, em Login único, escolha Configurar login único e depois Microsoft Entra ID. Informe um Nome, que as pessoas veem na página de login, o ID do locatário, o ID do cliente e o Segredo do cliente e escolha Salvar conexão.
6. Em Valores para o seu provedor de identidade, copie o URI de redirecionamento, https://screenrig.ai/api/sso/oidc/CONNECTION_ID/callback com o ID da sua conexão. No Entra, abra Authentication, adicione a plataforma Web (não Single-page application: a troca do código é executada no nosso servidor) e informe o valor.
7. Execute um teste de login.

O screenRIG identifica uma pessoa pelo object ID dela no Entra, nunca pelo e-mail ou pelo user principal name, que os administradores do Entra podem editar: renomear um usuário mantém a conta dele. Tokens de qualquer outro tenant são recusados. O screenRIG lê o endereço do claim email e, para um tenant do Entra, recorre a preferred_username quando email está ausente; o claim opcional da etapa 3 faz dele o endereço de e-mail da pessoa. O Entra não envia email_verified, então o screenRIG aceita o endereço porque ele está em um domínio que você verificou. O Entra deixa todo usuário do tenant entrar, a menos que Assignment required do enterprise application seja Yes.

Okta e outros provedores OpenID Connect

Serve para Okta, Auth0, Keycloak e qualquer provedor com um documento de descoberta em /.well-known/openid-configuration.

1. No provedor, crie um aplicativo web que use o fluxo de código de autorização. No Okta, escolha Applications, Create App Integration, OIDC, Web Application. O provedor pode pedir um redirect URI antes de o screenRIG ter um para você: informe agora qualquer endereço https e substitua-o na etapa 4. Atribua as pessoas ou os grupos que podem entrar.
2. Copie o client ID, o client secret e o issuer, o endereço https que o documento de descoberta informa. Para o Okta, é a URL da organização, como https://example.okta.com, ou o endereço de um servidor de autorização personalizado.
3. Em Configurações da organização, em Login único, escolha Configurar login único e depois OpenID Connect. Informe um Nome, o Emissor, o ID do cliente e o Segredo do cliente e escolha Salvar conexão.
4. Em Valores para o seu provedor de identidade, copie o URI de redirecionamento, https://screenrig.ai/api/sso/oidc/CONNECTION_ID/callback com o ID da sua conexão, e informe-o como o redirect URI do aplicativo no provedor.
5. Execute um teste de login.

O provedor deve ter suporte a PKCE com S256, ao modo de resposta form_post e a ID tokens assinados com um algoritmo assimétrico, e deve permitir os escopos openid, email e profile. Seu ID token deve conter um claim email: só um tenant do Entra recorre a outro claim. Um claim email_verified, quando enviado, deve ser true. Envie um claim auth_time onde o provedor puder: é assim que o screenRIG descobre quando a pessoa se autenticou.

SAML 2.0

Serve para um enterprise application do Entra, Okta, Google Workspace e qualquer outro provedor SAML 2.0. Comece no provedor e depois informe os metadados dele no screenRIG, que mostra os valores de que o provedor precisa.

O screenRIG exige que cada resposta atenda a estas condições:

• A resposta contém exatamente uma asserção, e ela não é criptografada.
• A própria asserção é assinada com RSA ou ECDSA e SHA-256 ou mais forte. SHA-1 é recusado, assim como uma resposta assinada em volta de uma asserção não assinada.
• O issuer da asserção é o entity ID do seu provedor, e a audience restriction dela indica o entity ID do screenRIG.
• O login começa no screenRIG. Um ícone no portal de aplicativos do seu provedor (login iniciado pelo IdP) é recusado; as pessoas começam pela página de login do screenRIG.
• Os relógios diferem em no máximo 3 minutos, e cada asserção é usada uma só vez.
• O NameID está presente, no formato persistent, endereço de e-mail ou unspecified. Um NameID transient, ou qualquer outro formato, é recusado. O NameID é o identificador da pessoa no screenRIG; no Entra, é o atributo object ID.
• O e-mail chega como o atributo email, mail, urn:oid:0.9.2342.19200300.100.1.3, http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress ou http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn, ou como um NameID em formato de e-mail.

Entra ID

1. Abra 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 escolha SAML. Em SAML Certificates, baixe o Federation Metadata XML e defina Signing Option como Sign SAML assertion ou Sign SAML response and assertion.
3. Em Configurações da organização, em Login único, escolha Configurar login único e depois SAML 2.0. Informe um Nome, cole o XML de metadados em Documento de metadados e escolha Salvar conexão. Valores para o seu provedor de identidade mostra então o ID da entidade e o Endereço do serviço consumidor de asserção (ACS).
4. No Entra, edite Basic SAML Configuration: o Identifier é o entity ID e o Reply URL é o endereço ACS.
5. Deixe os claims padrão: eles trazem o object ID e o endereço de e-mail da pessoa. Verifique se as pessoas que você atribui têm um endereço de e-mail.
6. Atribua as pessoas em Users and groups e depois execute um teste de login.

As pessoas que já entraram por OpenID Connect mantêm as contas quando um tenant passa para SAML, e vice-versa: os dois protocolos identificam uma pessoa pelo tenant e pelo object ID do Entra. A resposta SAML deve conter o claim object identifier, que os claims padrão do Entra incluem. Sem ele, o screenRIG recorre ao NameID, e uma conta vinculada por OpenID Connect deixa de corresponder (subject_mismatch).

Okta

1. Escolha Applications, Create App Integration, SAML 2.0. O Okta pede Single sign-on URL e Audience URI antes de mostrar os metadados: informe agora qualquer endereço https para ambos.
2. Defina Name ID format como Persistent e Application username como Email e adicione o attribute statement email com o valor user.email. Em Show Advanced Settings, deixe Assertion Signature em Signed com Signature Algorithm RSA-SHA256 e Digest Algorithm SHA256, e Assertion Encryption desativado.
3. Escolha Finish, abra a guia Sign On e copie o Identity Provider metadata.
4. Em Configurações da organização, em Login único, escolha Configurar login único e depois SAML 2.0. Informe um Nome, cole os metadados em Documento de metadados e escolha Salvar conexão. Copie o ID da entidade e o Endereço do serviço consumidor de asserção (ACS) de Valores para o seu provedor de identidade.
5. No Okta, edite SAML Settings: o Single sign-on URL é o endereço ACS e o Audience URI é o entity ID.
6. Atribua as pessoas e depois execute um teste de login.

Google Workspace

1. No Admin console, abra Apps, Web and mobile apps, Add app e escolha Add custom SAML app. Dê um nome a ele.
2. Baixe os metadados do Google Identity Provider e continue.
3. Em Configurações da organização, em Login único, escolha Configurar login único e depois SAML 2.0. Informe um Nome, cole os metadados em Documento de metadados e escolha Salvar conexão. Copie o ID da entidade e o Endereço do serviço consumidor de asserção (ACS) de Valores para o seu provedor de identidade.
4. No Google, informe o endereço ACS e o entity ID. Defina Name ID format como PERSISTENT e Name ID como Basic Information, Primary email. Deixe Signed response desmarcado: o Google então assina a asserção, o que o screenRIG exige.
5. Mapeie o atributo Primary email do Google Directory para o atributo do aplicativo email.
6. Abra o User access do aplicativo e ative-o para as pessoas que entram, depois execute um teste de login.

Rotacionar um certificado

Uma conexão confia em até quatro certificados de assinatura, então uma rotação não deixa intervalo. Cole o novo certificado ao lado do antigo (ou cole os novos metadados do provedor, que listam os dois) e salve, troque o provedor para o novo certificado e depois remova o antigo.

Test sign-in

Pressione Teste de entrada em Configurações da organização. Você entra no seu provedor e volta ao dashboard, que mostra o endereço que o provedor enviou e se ele enviou um identificador estável. Um teste não faz login de ninguém. Um teste com falha mostra a mensagem de um dos códigos de erro. O endereço deve estar em um domínio verificado.

Um teste bem-sucedido, ou um login real, pelo provedor, tenant, entity ID e protocolo atuais da conexão é o que permite exigir login único.

Require single sign-on

Escolha Exigir login único em Configurações da organização após um teste bem-sucedido, selecione os administradores de emergência (break-glass) e confirme. Para todos nos seus domínios verificados:

• A página de login oferece apenas o seu provedor. Uma senha ou uma passkey é recusada com sso_required. As senhas e passkeys permanecem na conta, sem uso, e voltam a funcionar se você desativar a exigência.
• O primeiro login único abre a conta existente cujo endereço verificado está no seu domínio, quaisquer que sejam os métodos de login que ela tenha, e a conta mantém seus projetos. Sua organização passa então a gerenciá-la: o e-mail dela acompanha o do seu provedor a cada login, e a pessoa não pode alterá-lo.
• Administradores de emergência (break-glass). Escolha até dois administradores da organização que tenham uma passkey. Eles mantêm o login com passkey para o dia em que seu provedor estiver fora do ar, e cada login desse tipo é registrado. Alterar administradores de emergência altera a escolha depois.
• Enquanto a exigência está ativa, o issuer, o tenant ID, o entity ID e o protocolo da conexão não podem mudar e a conexão não pode ser removida. Os certificados e o client secret podem ser rotacionados.

Desativar a exigência leva 72 horas. Escolha Turn off requirement: a exigência continua em vigor até lá, todo administrador recebe um e-mail e qualquer administrador pode escolher Cancel removal.

O que as pessoas veem

• A página de login pede o e-mail primeiro e segue para o seu provedor. A resposta depende apenas do domínio, então não revela se uma pessoa tem uma conta.
• Uma sessão dura 24 horas a partir do login no screenRIG, e o uso não a prolonga. Após 12 horas, o dashboard a renova silenciosamente na página seguinte, e a pessoa entra de novo da mesma forma depois que uma sessão termina. Um início silencioso não envia nenhum login hint, então o provedor responde pela conta para a qual mantém uma sessão; se for outra pessoa, a renovação falha com subject_mismatch. Uma pessoa cuja sessão no provedor está ativa não digita nada; caso contrário, ela entra de novo.
• Uma ação que pede uma passkey ou senha, como alterar a conexão, aceita em vez disso uma sessão de login único, que conta como login recente por 10 minutos. Ela só conta quando o seu provedor informa quando a pessoa se autenticou: o horário do próprio provedor (auth_time no OpenID Connect, AuthnInstant no SAML), não o horário do login no screenRIG. Quando o provedor não informa nenhum horário, ou informa um com mais de 10 minutos, o screenRIG pede que a pessoa entre de novo no provedor: o dashboard envia a pessoa pelo provedor para uma nova autenticação e a leva de volta ao ponto em que estava.
• Uma pessoa que seu provedor desativa perde o acesso em até 24 horas, e imediatamente com o provisionamento de usuários. Os agentes e os grants OAuth que uma pessoa aprovou continuam funcionando até que ela seja desativada, pelo provisionamento de usuários ou pela equipe do screenRIG: exigir login único e desativar a pessoa no seu provedor não os encerram.

Vincular uma conta existente

Uma pessoa no seu domínio verificado que já tem uma conta screenRIG com senha ou passkey não entra nessa conta no primeiro login único (account_exists), a menos que você exija login único. Ela entra como antes, abre Perfil e entrada em https://screenrig.ai/dashboard/me, escolhe Vincular login único e entra no provedor. A partir daí, o login único abre a mesma conta, que mantém seus próprios métodos de login. Perfil e entrada oferece o vínculo a toda pessoa com sessão iniciada no seu domínio que ainda não vinculou.

Solução de problemas

Um login com falha volta para a página de login com o código no endereço (#sso_error=CODE). Um teste com falha mostra na conexão a mensagem correspondente ao seu código.

Relacionado

• Provisionamento de usuários: crie, atualize e remova pessoas a partir do seu provedor e dê aos grupos acesso a projetos.
• Autenticação: como os agentes entram e como o acesso é aprovado.
• Referência da API: as rotas de conexão, política e login.