Central de ajuda › Conta e cobrança
SSO com SAML/OIDC
Login único com Entra ID (Azure AD), Google Workspace ou Okta: domínio verificado, criação automática de usuários e "Exigir SSO".
Disponível no plano Business (ou por contrato). Quem configura é o dono da conta, em Configurações → SSO. Lá estão os valores exatos da sua empresa (o ID-DA-EMPRESA abaixo é o identificador dela).
1. Verifique o domínio de e-mail
Adicione o domínio (ex.: suaempresa.com.br) e crie no DNS o registro TXT mostrado no painel:
| Nome | Valor |
|---|---|
_access-consent-sso.suaempresa.com.br | access-consent-sso=<token do painel> |
Clique em Verificar. Só e-mails de domínios verificados entram pelo SSO, e um domínio verificado pertence a uma conta só. Domínios de e-mail gratuitos (gmail.com, outlook.com…) não são aceitos.
2. Valores do Access Consent para colar no provedor
| Campo no provedor | Valor |
|---|---|
| Identificador (Entity ID / Audience URI) | https://consent.accesssecurity.com.br/v1/sso/ID-DA-EMPRESA/saml/metadata |
| URL de resposta (ACS / Single sign-on URL) | https://consent.accesssecurity.com.br/v1/sso/ID-DA-EMPRESA/saml/acs |
| Metadados do provedor de serviço (importar por URL) | https://consent.accesssecurity.com.br/v1/sso/ID-DA-EMPRESA/saml/metadata |
| URI de redirecionamento (OIDC) | https://consent.accesssecurity.com.br/v1/sso/ID-DA-EMPRESA/oidc/callback |
| Formato do NameID (SAML) | urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress |
3a. Microsoft Entra ID (Azure AD)
SAML: Entra ID → Aplicativos empresariais → Novo aplicativo → Criar seu próprio aplicativo (fora da galeria) → Logon único → SAML. Em “Configuração básica de SAML” cole o Identificador e a URL de resposta. Em “Atributos e declarações” mantenha o e-mail (user.mail) e, se quiser papel por grupo, adicione a declaração de grupos. Copie a URL de metadados de federação do aplicativo e importe no painel (Importar metadados por URL). Atribua usuários/grupos ao aplicativo.
OIDC: Registros de aplicativo → Novo registro → URI de redirecionamento (Web) = a URI de redirecionamento acima. Crie um segredo do cliente. No painel: Emissor https://login.microsoftonline.com/<ID do locatário>/v2.0, Client ID (ID do aplicativo) e Client secret. Para grupos, em “Configuração de token” adicione a declaração groups e use groups como atributo de grupos (vêm os IDs dos grupos).
3b. Google Workspace
SAML: Admin Console → Apps → Apps da Web e para dispositivos móveis → Adicionar app → Adicionar app SAML personalizado. Baixe os metadados do IdP (ou copie URL de SSO, ID da entidade e certificado) e importe no painel. Em “Detalhes do provedor de serviços” cole a URL do ACS e o ID da entidade, formato de ID de nome EMAIL, ID de nome Basic Information > Primary email. Ative o app para as unidades organizacionais desejadas.
OIDC: Google Cloud Console → APIs e serviços → Credenciais → ID do cliente OAuth (Aplicativo da Web) com a URI de redirecionamento acima. No painel: Emissor https://accounts.google.com, Client ID e Client secret. O Google não envia grupos no OIDC: use o papel padrão.
3c. Okta
SAML: Applications → Create App Integration → SAML 2.0. Single sign-on URL = ACS; Audience URI = Identificador; Name ID format = EmailAddress; Application username = Email. Para grupos, em “Group Attribute Statements” crie groups (filtro conforme seus grupos). Copie a URL “Metadata URL” e importe no painel.
OIDC: Applications → Create App Integration → OIDC → Web Application; Sign-in redirect URI = a URI de redirecionamento acima. No painel: Emissor https://<sua-org>.okta.com (ou …/oauth2/default), Client ID e Client secret; para grupos, inclua o escopo/claim groups.
4. Usuários, papéis e "Exigir SSO"
- Criação automática (JIT): no primeiro login, a pessoa ganha acesso com o papel padrão (Leitor, se nada for configurado). Desligue para só entrar quem já foi cadastrado em Usuários.
- Papel por grupo: informe o atributo/claim de grupos e as regras grupo → Administrador ou Leitor. O papel é atualizado a cada login. Dono nunca vem do provedor e nunca é alterado pelo SSO.
- Exigir SSO: quem tem e-mail de um domínio verificado deixa de entrar por senha nesta empresa. Acesso de emergência: o(s) dono(s) continuam podendo entrar com senha (e código por e-mail, quando ligado) — use se o provedor sair do ar; esse login aparece na trilha marcado como emergência. Mantenha ao menos um dono com senha forte.
- A sessão aberta pelo SSO vale só para a empresa do provedor (para outra empresa, saia e entre de novo) e não dá acesso à área da equipe Access.
Segurança
- SAML: asserção assinada obrigatória, conferência de emissor, público (audience), destinatário (Recipient), prazo com tolerância de 2 minutos, InResponseTo do pedido deste navegador e proteção contra reenvio (cada asserção vale uma vez). O pedido ao provedor é assinado com a chave da sua empresa (certificado nos metadados). Login iniciado pelo provedor (pelo portal do Entra/Okta) fica desligado por padrão: ligue só se precisar.
- OIDC: authorization code com PKCE, state e nonce; o ID token é validado (assinatura, emissor, audiência, validade). E-mail marcado como não verificado pelo provedor é recusado.
- O Client secret e a chave privada do provedor de serviço ficam cifrados no banco.
- Toda alteração de configuração e todo login (sucesso ou falha, com o motivo) vão para a trilha de auditoria.
SCIM (provisionamento e desativação automáticos a partir do provedor) ainda não está disponível. Para remover o acesso de alguém, tire a pessoa do aplicativo no provedor e remova o usuário em Usuários.
Entrar
Na tela de login, clique em Entrar com SSO e informe seu e-mail: o Access Consent encontra a sua empresa pelo domínio e leva você ao provedor.