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
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 oPOST step-up/da sua aplicação para perguntar seactionrequer uma verificação de identidade.actionépayout,bankoucontact, e um payout requeramount. 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 comGET 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 comhandleRedirectCallback(). Se outra pessoa concluir o processo, este é rejeitado comstep_up_user_mismatche a sessão original mantém-se.
{ 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 respetivovendor_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.