Saltar para o conteúdo principal
A autenticação é nova: use este exemplo de fluxo alojado com uma aplicação que tenha a Autenticação ativada. O pacote @didit-protocol/auth ainda não está publicado; a API do pacote abaixo é uma pré-visualização, não um guia de início rápido instalável.

Configurar o início de sessão alojado

Registe o URL de retorno exato e a origem web da sua aplicação de sandbox. Copie a origem de início de sessão (https://<slug>.sandbox.auth.didit.me) a partir da consola, como descrito na visão geral. Este exemplo usa as APIs de criptografia do navegador e exige HTTPS, ou localhost no sandbox: consulte desenvolvimento local para saber o que deve registar. A aplicação é responsável pelo state e pelo verificador PKCE. O início de sessão alojado é responsável pelos ecrãs de palavra-passe, e-mail, passkey, telefone, SSO e MFA obrigatório. Nenhuma chave de API deve estar neste código.
auth.js
Chame signIn() a partir do botão de início de sessão. Na página de retorno registada, chame handleCallback() uma vez, mostre um estado de carregamento e apresente o erro, se falhar. Use getSession() para obter o utilizador atual e signOut() para terminar a sessão. A função de retorno remove o código da barra de endereços antes de fazer qualquer pedido. Este exemplo mínimo mantém os tokens em memória e volta a iniciar sessão após um recarregamento da página ou quando o token de acesso expira. Para sessões persistentes, use o seu backend e cookies seguros, ou implemente a rotação de tokens de atualização com serialização. Nunca coloque tokens de atualização em URLs ou registos. A verificação de sessão no frontend controla apenas a apresentação; o seu backend deve validar quem faz o pedido em cada pedido protegido.

Pré-visualização da versão do SDK de autenticação

O núcleo planeado @didit-protocol/auth expõe createDiditAuth({publishableKey}), signIn(), handleRedirectCallback(), getSession(), getToken(), onAuthStateChange e signOut(), com vendorData na identidade. Destina-se a acrescentar sinais automáticos do dispositivo e um ponto de entrada no servidor com verifyToken(). A chave publicável é pk_live_ (aplicação de produção) ou pk_test_ (aplicação de sandbox), seguida da codificação base64url, sem preenchimento, da origem da sua aplicação. O SDK envia os seus pedidos de API para essa origem. A chave é pública: identifica a aplicação e não é um segredo.

Verificação adicional e reautenticação na pré-visualização

  • stepUp({ action, amount?, currency?, redirectUri? }) chama o POST step-up/ da sua aplicação para perguntar se action requer uma verificação de identidade. action é payout, bank ou contact, e um payout requer amount. Quando se aplica uma das suas regras de verificação adicional, navega para a página de verificação que a Didit devolve.
  • handleStepUpCallback(url?) é executado na página para onde a pessoa regressa. Lê ?step_up=<id>, remove-o da barra de endereços e lê o resultado com GET step-up/{id}/.
  • reauthenticate({ method? }) volta a autenticar a mesma pessoa, na página alojada (method: "redirect", o padrão) ou com uma chave de acesso (method: "passkey", apenas no domínio de início de sessão da sua aplicação na Didit). Depois da página alojada, conclua com handleRedirectCallback(). Se outra pessoa concluir o processo, este é rejeitado com step_up_user_mismatch e a sessão original mantém-se.
Ambos os métodos de verificação adicional devolvem { id, status, approved, rule, method }, em que status é not_required, pending, approved, review, declined ou expired. redirectUri assume por predefinição o endereço de redirecionamento do cliente e tem de corresponder exatamente a um dos endereços de redirecionamento registados da sua aplicação: quando é necessária uma verificação, a Didit recusa qualquer outro endereço. Antes de o seu backend agir sobre uma verificação adicional, leia-a novamente com GET step-up/{id}/ e com o token de acesso da pessoa, porque um resultado comunicado pelo navegador pode ser alterado. Um início de sessão sem interface gráfica (headless) também pode responder protection_required quando as regras de proteção da sua aplicação o assinalam. A pessoa conclui-o então com o código que a Didit lhe enviou por e-mail (protection.verify({ code })) ou com uma passkey (protection.passkey()), e methods indica quais dos dois pode utilizar. Não instale uma versão baseada em suposições nem escreva com base em opções de callback presumidas. Confirme as exportações do pacote publicado, o emissor e a configuração das chaves antes de substituir o exemplo alojado. Palavra-passe, código por e-mail, ligação mágica, passkey, telefone, MFA, início de sessão social, verificação adicional e métodos de agente dependerão da API suportada por essa versão.

Adicionar outros produtos

O seu backend verifica o token de acesso (consulte tokens e JWKS) e lê o respetivo vendor_data. Use esse valor como vendor_data ao criar uma sessão de verificação ou ao emitir um token de transação. Um início de sessão bem-sucedido não significa que qualquer dos produtos tenha aprovado o utilizador. Antes de publicar, teste o registo, o início de sessão de utilizadores recorrentes, o cancelamento, um state que não corresponde, um código reutilizado, a recuperação de palavra-passe, o MFA, a expiração e o terminar de sessão na sua aplicação de sandbox com a Autenticação ativada.
Última modificação em 7 de novembro de 2026