Saltar para o conteúdo principal
A Autenticação é nova. A Didit ativa o produto na sua aplicação. Até lá, todas as rotas de execução dessa aplicação devolvem 404. Os pacotes do SDK de Autenticação ainda não estão publicados, por isso use o fluxo alojado e o contrato HTTP descritos nestas páginas.
A Autenticação inicia sessão dos seus clientes na sua aplicação. É separada de iniciar sessão na consola da Didit ou de criar uma conta de programador 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 a Monitorização de transações. Iniciar sessão não aprova uma verificação nem autoriza um pagamento. O seu backend toma essas decisões a partir do resultado de cada produto.

​
Como funciona

Cada aplicação tem a sua própria origem de início de sessão e o seu próprio emissor de tokens. As aplicações de produção e de sandbox são separadas: têm origens, definições e identidades distintas. O fluxo utiliza o código de autorização OAuth 2.0 com PKCE (apenas 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 alojada inicia sessão ou cria a conta da pessoa com os métodos que ativou, incluindo qualquer segundo fator obrigatório.
  3. O navegador regressa ao seu redirect_uri com code e state.
  4. A sua aplicação troca o código em POST {origin}/token/ por um token de acesso, um token de ID e um token de atualização.
Veja tokens e JWKS para o contrato dos tokens e métodos de início de sessão para cada método.

​
Escolha a sua plataforma

JavaScript

Início de sessão alojado, retorno, sessão e terminar sessão.

React

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

Next.js

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

iOS

Navegador do sistema e armazenamento seguro de tokens.

Android

Autorização no navegador e retornos da aplicação.

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 para ativar a Autenticação na sua aplicação. Teste primeiro numa aplicação de sandbox.
  2. Registe os seus URLs de redirecionamento exatos (até 50) e os allowed_origins do navegador (até 50) que chamam a API de execução.
  3. Ative os métodos de início de sessão que quer oferecer. A Didit ID Wallet está sempre ativa.
  4. Escolha as definições de sessão e de palavra-passe (ver abaixo).
  5. Teste o registo, o início de sessão, a recuperação da palavra-passe, a MFA, a expiração da sessão e o encerramento de sessão antes de passar para produção.
Uma chave de acesso pertence à sua origem. Se mais tarde ativar um domínio personalizado, as pessoas terão de registar novamente as suas chaves de acesso.

​
URLs de redirecionamento

A Didit só devolve uma pessoa a um endereço que tenha registado. Registe o seu na consola, em Autenticação > Segurança e sessões > URLs de redirecionamento e origens permitidas. O redirect_uri de um pedido de início de sessão tem de corresponder a um URL registado, carácter a carácter: esquema, host, porta, caminho e query. Uma porta diferente, uma barra final ou uma diferença de maiúsculas e minúsculas é outro endereço. Carateres universais, fragmentos, credenciais no URL e esquemas personalizados são rejeitados. Quando o endereço não está registado, a Didit nunca redireciona para ele. {origin}/sign-in responde com 400 e uma página que indica o que registar e onde, e POST {origin}/authorize/ responde com 400 {"error": "invalid_redirect_uri"}.

​
Desenvolvimento local

Teste na sua máquina com a sua aplicação de sandbox:
  1. Registe o seu URL de retorno com a porta, por exemplo http://localhost:3000/auth/callback.
  2. Se o código do navegador chamar a API de execução, por exemplo para trocar o código em POST {origin}/token/, adicione também a origem a Origens permitidas: http://localhost:3000, sem caminho e sem barra final.
  3. Comece o fluxo de início de sessão 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 distintos, e cada porta também. Registe cada um que usar. As aplicações de produção nunca aceitam http://. Antes de passar para produção, registe o seu URL de retorno https:// de produção na sua aplicação de produção.

​
Definições da aplicação

Gere estas definições na consola ou com uma sessão autorizada na consola que tenha write:authentication.

​
Manter uma pessoa em todos os produtos

Cada identidade tem um valor vendor_data. É o external_id que forneceu ao importar a pessoa ou, caso contrário, o ID de identidade da Didit. 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 submeter transações. Assim, os eventos de autenticação ficam associados à mesma pessoa na consola, junto das respetivas verificações e transações. Consulte eventos e webhooks. Obtenha o vendor_data no seu backend a partir de um token verificado, nunca a partir de um campo do navegador não validado. Use o prompt de integração partilhado para qualquer combinação. Leia proteção contra bots para conhecer as políticas que são executadas no início de sessão.
Última modificação em 7 de novembro de 2026