Configurar o login hospedado
Registre a URL de retorno exata e a origem web da sua aplicação de sandbox. Copie a origem de login dela (https://<slug>.sandbox.auth.didit.me) no console, como descrito na visão geral. Este exemplo usa as APIs de criptografia do navegador e exige HTTPS, ou localhost no sandbox: veja em desenvolvimento local o que registrar.
A aplicação é responsável pelo state e pelo verificador PKCE. O login hospedado é responsável pelas telas de senha, e-mail, passkey, telefone, SSO e MFA obrigatório. Nenhuma chave de API deve estar neste código.
auth.js
signIn() no seu botão de login. Na página de retorno registrada, chame handleCallback() uma única vez, exiba um estado de carregamento e mostre o erro caso ela falhe. Use getSession() para obter o usuário atual e signOut() para fazer logout. A página de retorno remove o código da barra de endereço antes de fazer uma requisição.
Este exemplo mínimo mantém os tokens em memória e faz login novamente após recarregar a página ou quando o token de acesso expira. Para sessões persistentes, use seu backend e cookies seguros ou implemente a rotação serializada de refresh. Nunca coloque refresh tokens em URLs ou logs. Uma verificação de sessão no frontend controla apenas a apresentação; seu backend deve validar quem faz a chamada em toda requisição protegida.
Prévia de lançamento do SDK de autenticação
O núcleo planejado do@didit-protocol/auth expõe createDiditAuth({publishableKey}), signIn(), handleRedirectCallback(), getSession(), getToken(), onAuthStateChange e signOut(), com vendorData na identidade. A intenção é adicionar 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 padding, da origem da sua aplicação.
O SDK envia suas chamadas de API para essa origem.
A chave é pública: ela identifica a aplicação e não é um segredo.
Step-up e reautenticação na prévia
stepUp({ action, amount?, currency?, redirectUri? })chama oPOST step-up/da sua aplicação para perguntar seactionexige uma verificação de identidade.actionépayout,bankoucontact, e um payout exigeamount. Quando uma das suas regras de step-up se aplica, ele navega até a página de verificação que a Didit retorna.handleStepUpCallback(url?)é executado na página para a qual a pessoa retorna. Ele lê?step_up=<id>, remove esse parâmetro da barra de endereço e lê o resultado comGET step-up/{id}/.reauthenticate({ method? })autentica a mesma pessoa novamente, na página hospedada (method: "redirect", o padrão) ou com uma passkey (method: "passkey", apenas no domínio de login da Didit da sua aplicação). Após a página hospedada, conclua comhandleRedirectCallback(). Se outra pessoa concluir, a operação é rejeitada comstep_up_user_mismatche a sessão original é mantida.
{ id, status, approved, rule, method }, em que status é not_required, pending, approved, review, declined ou expired.
redirectUri usa por padrão o endereço de redirecionamento do cliente e deve corresponder exatamente a um dos endereços de redirecionamento registrados da sua aplicação: quando uma verificação é necessária, a Didit recusa qualquer outro endereço.
Antes de agir com base em um step-up, seu backend lê o step-up novamente com GET step-up/{id}/ e o token de acesso da pessoa, porque um resultado informado pelo navegador pode ser alterado.
Um login headless também pode retornar protection_required quando as regras de proteção da sua aplicação o sinalizam.
A pessoa então o conclui com o código que a Didit enviou por e-mail (protection.verify({ code })) ou com uma passkey (protection.passkey()), e methods lista qual dos dois ela pode usar.
Não instale uma versão presumida nem escreva código com base em opções de retorno presumidas. Confirme os exports do pacote publicado, o emissor e a configuração de chaves antes de substituir o exemplo hospedado. Os métodos de senha, código por e-mail, link mágico, passkey, telefone, MFA, login social, step-up e agentes dependerão da API compatível com esse lançamento.
Adicionar outros produtos
Seu backend verifica o token de acesso (veja tokens e JWKS) e lê ovendor_data dele. Use esse valor como vendor_data ao criar uma sessão de verificação ou ao gerar um token de transação. Um login bem-sucedido não significa que um ou outro desses produtos tenha aprovado o usuário.
Antes de publicar, teste cadastro, login de retorno, cancelamento, state divergente, código reutilizado, esqueci a senha, MFA, expiração e logout na sua aplicação de sandbox ativada.