Pular para o conteúdo principal
A autenticação é nova: o didit_auth depende da versão. As coordenadas de distribuição, as versões e as assinaturas das funções não estão confirmadas aqui. Não instale um pacote não confirmado nem use o SDK de verificação de identidade como SDK de autenticação.

​
Preparar a aplicação

  1. Confirme que o Authentication está ativado para a sua aplicação Didit e copie a origem de login dela (https://<slug>.auth.didit.me, ou <slug>.sandbox.auth.didit.me para o sandbox) do console.
  2. Registre uma URL de retorno exata, compatível com a sua aplicação e com o runtime. Valide a propriedade do app link; não presuma que esquemas de URL personalizados arbitrários sejam aceitos.
  3. Mantenha separadas as configurações do sandbox e do ambiente de produção, incluindo o tratamento do retorno e as credenciais armazenadas.
  4. Defina um mapeamento estável de pessoas antes de conectar a verificação ou o monitoramento.
Configure e teste os links de retorno separadamente no iOS e no Android. O wrapper de Authentication é separado do didit_sdk, que cuida da verificação.

​
Implementar o fluxo hospedado

Abra o navegador de autenticação nativo do sistema com a URL {origin}/sign-in. Informe um state aleatório novo, um desafio PKCE S256 e o seu redirect_uri registrado. Mantenha o verifier no seu app apenas para essa tentativa. O quickstart de JavaScript mostra o protocolo subjacente; no código nativo, use a criptografia e o tratamento de URLs da plataforma em vez de variáveis globais do navegador. No retorno, verifique o state, o tempo de vida da transação e o destino do retorno antes de trocar o código de uso único em token/. Use o verifier original e a URI de redirecionamento exata. Cancelar ou fechar o navegador não é um login bem-sucedido. Armazene os refresh tokens no armazenamento nativo protegido da plataforma; nunca em um arquivo de preferências não protegido, em analytics ou em logs de falhas. Valide a sessão atual usando GET session/ com o token Bearer do usuário final. Faça as renovações em série, substitua os dois tokens juntos e limpe o estado específico do usuário após o logout. Consulte tokens e JWKS para o contrato da requisição e o comportamento de reutilização do token de renovação.

​
Prévia do lançamento do SDK nativo

Os módulos nativos de Authentication têm previsão de oferecer login, acesso à sessão atual, obtenção de tokens, logout e step-up, com sinais automáticos do dispositivo. Passkeys nativas e armazenamento protegido de tokens fazem parte desse lançamento. As APIs do wrapper seguirão os contratos publicados de cada plataforma; não copie argumentos de construtor nem assinaturas de métodos presumidos a partir de um exemplo de design. Até o módulo ser lançado, mantenha o adaptador dele desativado ou use uma implementação revisada do protocolo hospedado para sua aplicação habilitada. Não anuncie um quickstart nativo de Authentication funcional baseado apenas na instalação do pacote.

​
Conectar verificação e monitoramento

O seu backend gera o vendor_data com base na pessoa autenticada. Ele cria sessões de verificação ou emite tokens de monitoramento com escopo para essa pessoa. Retorne ao seu app apenas a credencial da sessão ou o token com escopo; a chave de API permanece no servidor. Use o SDK de verificação para Flutter quando precisar de verificação de identidade. Siga o envio de transações pelo SDK para o suporte a monitoramento na sua plataforma. Trate separadamente as decisões de login, de verificação e de transações.

​
Verificar a integração

Teste o retorno a um app encerrado, as transições entre segundo e primeiro plano, o cancelamento no navegador, um retorno incompatível, a repetição do código, a expiração do token, renovações simultâneas, MFA, logout e o login como outro usuário. Teste o cadastro de passkeys e o login em dispositivos compatíveis assim que esse lançamento estiver disponível. Uma verificação exclusiva de dispositivo continua não verificada até ser executada na plataforma de destino.
Última modificação em 1 de novembro de 2026