Pular para o conteúdo principal
A Autenticação é nova. A Didit ativa o produto para a sua aplicação. Até lá, todas as rotas de runtime dessa aplicação retornam 404. Os pacotes do SDK de Autenticação ainda não foram publicados, então use o fluxo hospedado e o contrato HTTP destas páginas.
A Autenticação permite que seus clientes façam login na sua aplicação. Ela é separada do login no console da Didit e da criação de uma conta de desenvolvedor na Didit. Também é separada da verificação da identidade de uma pessoa. Use a Autenticação sozinha ou combine-a com a Verificação de identidade e o Monitoramento de transações. Fazer login não aprova uma verificação nem autoriza um pagamento. O seu backend toma essas decisões com base no resultado de cada produto.

​
Como funciona

Cada aplicação tem a sua própria origem de login e o seu próprio emissor de tokens. Aplicações de produção e de sandbox são separadas: elas têm origens, configurações e identidades separadas. O fluxo é OAuth 2.0 authorization code com PKCE (somente S256):
  1. A sua aplicação abre {origin}/sign-in com redirect_uri, state, code_challenge e code_challenge_method=S256.
  2. A página hospedada permite que a pessoa faça login ou se cadastre com os métodos que você ativou, incluindo qualquer segundo fator exigido.
  3. O navegador volta para o seu redirect_uri com code e state.
  4. A sua aplicação troca o código no endpoint POST {origin}/token/ por um access token, um ID token e um refresh token.
Consulte tokens e JWKS para o contrato de tokens e métodos de login para cada método.

​
Escolha a sua plataforma

JavaScript

Login hospedado, callback, sessão e logout.

React

Estado do cliente e telas protegidas da aplicação.

Next.js

Sessões no servidor, rotas de callback e cookies.

iOS

Navegador do sistema e armazenamento seguro de tokens.

Android

Autorização pelo navegador e callbacks do app.

React Native

Preparação do wrapper nativo de autenticação.

Flutter

Preparação do wrapper nativo de autenticação.

​
Prepare a sua aplicação

  1. Peça à Didit que ative a Autenticação para a sua aplicação. Teste primeiro em uma aplicação de sandbox.
  2. Registre as suas URLs de redirecionamento exatas (até 50) e as allowed_origins do navegador (até 50) que chamam a API de runtime.
  3. Ative os métodos de login que você quer oferecer. A Didit ID Wallet está sempre ativa.
  4. Escolha as suas configurações de sessão e de senha (veja abaixo).
  5. Teste cadastro, login, recuperação de senha, MFA, expiração de sessão e logout antes de entrar em produção.
Uma passkey pertence à sua origem. Se depois você ativar um domínio personalizado, as pessoas precisarão cadastrar as suas passkeys novamente.

​
URLs de redirecionamento

A Didit só redireciona uma pessoa para um endereço que você registrou. Registre os seus no console, em Authentication > Security and sessions > Redirect URLs and allowed origins. O redirect_uri de uma requisição de login deve corresponder a uma URL registrada caractere por caractere: esquema, host, porta, caminho e query. Uma porta diferente, uma barra final ou uma diferença entre maiúsculas e minúsculas é um endereço diferente. Curingas, fragmentos, credenciais na URL e esquemas personalizados são rejeitados. Quando o endereço não está registrado, a Didit nunca redireciona para ele. {origin}/sign-in responde 400 com uma página que diz o que registrar e onde, e POST {origin}/authorize/ responde 400 {"error": "invalid_redirect_uri"}.

​
Desenvolvimento local

Teste na sua própria máquina com a sua aplicação de sandbox:
  1. Registre o seu callback com a porta, por exemplo http://localhost:3000/auth/callback.
  2. Se o código do navegador chamar a API de runtime, por exemplo para trocar o código em POST {origin}/token/, adicione a origem também em Origens permitidas: http://localhost:3000, sem caminho e sem barra final.
  3. Inicie o login na sua origem de sandbox, https://<slug>.sandbox.auth.didit.me, com a sua chave pk_test_....
localhost, 127.0.0.1 e [::1] são endereços separados, assim como cada porta. Registre cada um que você usar. Aplicações de produção nunca aceitam http://. Antes de entrar em produção, registre o seu callback https:// de produção na sua aplicação de produção.

​
Configurações da aplicação

Você gerencia essas configurações no console ou com uma sessão autorizada do console que tenha write:authentication.

​
Mantenha uma única pessoa entre os produtos

Toda identidade tem um valor vendor_data. Ele é o external_id que você informou ao importar a pessoa ou, caso contrário, o ID de identidade da Didit. Ele aparece no token de acesso, no token de ID e em GET session/. Use o mesmo valor como vendor_data ao criar sessões de verificação e enviar transações. Assim, os eventos de autenticação ficam vinculados à mesma pessoa no console, junto com suas verificações e transações. Consulte eventos e webhooks. Obtenha o vendor_data no seu backend a partir de um token verificado, nunca de um campo do navegador não validado. Use o prompt de integração compartilhado para qualquer combinação. Leia proteção contra bots para conhecer as políticas aplicadas no login.
Última modificação em 1 de novembro de 2026