Começar
Integrar / SDKs
Verificação de utilizadores
Verificação de empresas
Monitorização de transações
Registo de alteraçõesMantenha a sessão no seu servidor
Use o fluxo alojado descrito no guia rápido de JavaScript, com as seguintes alterações para uma aplicação renderizada no servidor. Os nomes das suas rotas são rotas da aplicação que você implementa, não são endpoints da API da Didit.
Envie apenas uma referência aleatória de sessão da aplicação num cookie
Secure, HttpOnly, SameSite=Lax, com um caminho restrito. Defina uma validade adequada e altere a referência após o início de sessão. Não exponha o token de renovação da Didit em props renderizadas, componentes do cliente ou armazenamento do navegador. Use Cache-Control: no-store nas respostas de token e de retorno de chamada.
Não confie apenas numa verificação de layout ou de middleware: autorize em cada acesso a dados e em cada alteração. Proteja as alterações autenticadas por cookie contra CSRF. Permita apenas destinos pós-início de sessão configurados, nunca um URL returnTo arbitrário da query string.
Pré-visualização da versão do pacote
O pacote planeado acrescenta middleware,auth() do lado do servidor, uma rota de retorno de chamada e suporte a cookies HttpOnly para renderização no servidor. A entrada /server do núcleo destina-se a fornecer verifyToken() com JWKS em cache. Aguarde pelas exportações da versão verificada antes de usar estes símbolos. Até lá, verifique os tokens por si, com qualquer biblioteca JOSE, conforme descrito em tokens e JWKS.
Ligue os outros produtos
Crie sessões de verificação e emita tokens de monitorização com âmbito definido no servidor. Derivevendor_data a partir do mapeamento validado da pessoa. Devolva ao navegador apenas um URL de sessão de verificação ou um token SDK de curta duração. Não inclua DIDIT_API_KEY em variáveis de ambiente públicas.
Use o SDK de verificação web existente para a verificação e o guia de envio de transações para a monitorização. Nenhum dos dois é um gestor de sessões de Autenticação.
Teste a reutilização de retornos de chamada, um state incorreto, um state expirado, condições de corrida na renovação, sessões revogadas, a rejeição de CSRF e o terminar de sessão antes da versão. Consulte tokens e JWKS para o contrato de validação.