Saltar para o conteúdo principal
Didit expõe um servidor de autorização OpenID Connect concebido para a verificação de identidade delegada. Implementa o contrato que a estrutura “bring your own identity verification vendor” (BYO IDV) da Okta espera: Pushed Authorization Requests (PAR, RFC 9126), o fluxo de código de autorização com PKCE e um ID token que transporta um objeto OpenID Connect verified_claims. Os mesmos endpoints funcionam para qualquer parte confiadora que siga este perfil, incluindo as Actions de post-login do Auth0.

Endpoints

Todos os endpoints estão sob o URL base da ponte de verificação de identidade. A produção e o sandbox usam os mesmos endpoints. A aplicação associada às suas credenciais de cliente determina o ambiente. Use credenciais de cliente separadas e um fluxo de verificação pertencente à aplicação correspondente para cada ambiente. Consulte Sandbox e dados de teste para ver os resultados simulados de verificação. O documento de discovery em {base}/.well-known/openid-configuration anuncia todos eles: A autenticação do cliente usa client_secret_basic ou client_secret_post. O fluxo de código de autorização exige PKCE com code_challenge_method=S256. Os ID tokens são assinados com RS256; verifique-os através do endpoint JWKS.

Fluxo

  1. A parte confiadora envia pedido de autorização para POST /par, incluindo o desafio PKCE, state, nonce, o seu redirect_uri registado, os scopes openid profile identity_assurance e os claims que pretende que sejam verificados. A Didit devolve um request_uri de utilização única, válido durante 60 segundos.
  2. A parte confiadora redireciona o navegador do utilizador para GET /authorize?request_uri=.... A Didit cria uma sessão de verificação e encaminha o utilizador para o fluxo de verificação alojado.
  3. Quando o utilizador termina, a Didit avalia a decisão de verificação, compara a identidade extraída com os claims enviados e devolve o utilizador ao redirect_uri da parte confiadora com um code de utilização única e o state original.
  4. A parte confiadora troca o código em POST /token com o seu code_verifier e recebe um ID token assinado.

Pedido de claims

Envie os claims a comparar dentro do parâmetro claims padrão do OpenID Connect no pedido PAR. Tanto given_name como family_name são suportados, e ambos são sempre comparados de forma aproximada. verified_claims é um array, em conformidade com o perfil BYO IDV da Okta e com a resposta do ID token abaixo.

O ID token

O ID token transporta um array verified_claims. assurance_level é VERIFIED apenas quando a sessão de verificação foi aprovada e todos os claims pedidos corresponderam ao documento verificado. Caso contrário, é FAILED.
verification_process é o id da sessão na Didit, por isso pode consultar a verificação na consola ou através da API de sessões.
Considere o utilizador verificado apenas quando trust_framework for IDV-DELEGATED e assurance_level for VERIFIED. Qualquer outra combinação significa que a verificação não teve êxito.

Configurar a Okta

Peça à Didit para ativar a verificação de identidade para as suas aplicações de produção e de sandbox, associe cada uma ao respetivo fluxo de verificação e registe o URL de retorno exato para cada organização da Okta. Uma aplicação ou chave de API existente, por si só, não ativa esta integração. Na Okta Admin Console, adicione um fornecedor personalizado de verificação de identidade e preencha os valores abaixo. A Okta cria a integração como um fornecedor de identidade do tipo IDV_STANDARD com o protocolo ID_PROOFING, e depois referencia-a numa regra de Account Management Policy. Configure a produção e o sandbox como integrações de verificação de identidade separadas, com as respetivas credenciais. Use os endpoints acima para ambas. O segredo do cliente é obrigatório, embora o fluxo também utilize PKCE. Uma chave de API nomeada criada à parte não pode substituir a chave de API principal da aplicação nesta integração. Indique à Didit o seu URL de retorno para que seja registado no seu cliente. A Okta constrói-o como {yourOktaOrgUrl}/idp/identity-verification/callback.

Configurar o Auth0

O Auth0 não tem uma opção nativa para fornecedores de IDV, por isso a verificação é executada a partir de uma Action de post-login que redireciona o utilizador para o mesmo fluxo. Guarde DIDIT_IDV_BASE, DIDIT_CLIENT_ID e DIDIT_CLIENT_SECRET como segredos da Action, e registe https://{yourAuth0Domain}/continue como URI de redirecionamento na Didit.
O Auth0 acrescenta o seu próprio state ao redirecionamento para /authorize, para poder retomar o login. A Didit adota esse state e devolve-o a /continue, o que permite ao Auth0 concluir a transação. Não inclua o state do Auth0 no corpo do PAR, porque só é gerado no redirecionamento.
Guarde o code_verifier do PKCE por transação de login (identificado por event.transaction.id), e não num único campo de app_metadata. Se um utilizador repetir a tentativa ou iniciar um login sobreposto, um campo partilhado único é sobrescrito e a troca do token falha com invalid_grant.

Erros

Os erros seguem a RFC 6749 e a RFC 9126. A falha na autenticação do cliente devolve 401 com {"error": "invalid_client"}. Um request_uri ou código de autorização expirado ou reutilizado devolve 400 com invalid_request ou invalid_grant. Os códigos de autorização, os valores de request_uri e as sessões de verificação são todos de utilização única.
Última modificação em 7 de novembro de 2026