verified_claims do OpenID Connect.
Os mesmos endpoints funcionam com qualquer relying party compatível com esse perfil, incluindo as Actions pós-login do Auth0.
Endpoints
Todos os endpoints estão disponíveis na URL base da ponte de verificação de identidade.
Produção e sandbox usam os mesmos endpoints.
A aplicação associada às suas credenciais de cliente determina o ambiente.
Use credenciais de cliente separadas e um workflow de verificação pertencente à aplicação correspondente para cada ambiente.
Consulte Sandbox e dados de teste para ver resultados de verificação simulados.
O documento de descoberta em
{base}/.well-known/openid-configuration lista 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 usando o endpoint JWKS.
Fluxo
- A relying party envia a requisição de autorização para
POST /par, incluindo o desafio PKCE,state,nonce, suaredirect_uriregistrada, os escoposopenid profile identity_assurancee os claims que deseja verificar. O Didit retorna umrequest_uride uso único, válido por 60 segundos. - A relying party redireciona o navegador do usuário para
GET /authorize?request_uri=.... O Didit cria uma sessão de verificação e encaminha o usuário para o fluxo de verificação hospedado. - Quando o usuário termina, o Didit avalia a decisão da verificação, compara a identidade extraída com os claims enviados e devolve o usuário para a
redirect_urida parte confiável com umcodede uso único e ostateoriginal. - A relying party troca o código no endpoint
POST /tokenusando seucode_verifiere recebe um ID token assinado.
Solicitação de claims
Envie os claims a serem comparados dentro do parâmetro padrão OpenID Connectclaims da requisição PAR.
Tanto given_name quanto family_name são aceitos, e ambos são sempre comparados de forma aproximada (fuzzy).
verified_claims é um array, de acordo com o perfil BYO IDV do Okta e com a resposta do ID token abaixo.
O ID token
O ID token contém um arrayverified_claims. assurance_level é VERIFIED somente quando a sessão de verificação foi aprovada e todos os claims solicitados corresponderam ao documento verificado.
Caso contrário, é FAILED.
verification_process é o ID da sessão no Didit, para que você possa consultar a verificação no console ou pela API de sessões.
Considere o usuário verificado somente quando
trust_framework for IDV-DELEGATED e assurance_level for VERIFIED.
Qualquer outra combinação significa que a verificação não foi bem-sucedida.Configurar o Okta
Peça ao Didit para habilitar a verificação de identidade nas suas aplicações de produção e sandbox, associar cada uma ao seu fluxo de verificação e registrar a URL de retorno exata de cada tenant do Okta. Uma aplicação ou chave de API existente, por si só, não habilita esta integração. No Okta Admin Console, adicione um fornecedor personalizado de verificação de identidade e preencha os valores abaixo. O Okta cria a integração como um provedor de identidade do tipoIDV_STANDARD com o protocolo ID_PROOFING. Em seguida, você faz referência a ele em uma regra de Account Management Policy.
Configure produção e sandbox como integrações de verificação de identidade separadas, cada uma com suas respectivas credenciais.
Use os endpoints acima para ambas.
O segredo do cliente é obrigatório, mesmo que o fluxo também use PKCE.
Uma chave de API nomeada criada separadamente não pode substituir a chave de API principal da aplicação nesta integração.
Informe sua URL de retorno ao Didit para que ela seja registrada no seu cliente.
O Okta a monta como
{yourOktaOrgUrl}/idp/identity-verification/callback.
Configurar o Auth0
O Auth0 não tem uma opção nativa de fornecedor de IDV, então a verificação é executada a partir de uma Action pós-login que redireciona o usuário para o mesmo fluxo. ArmazeneDIDIT_IDV_BASE, DIDIT_CLIENT_ID e DIDIT_CLIENT_SECRET como secrets da Action e registre https://{yourAuth0Domain}/continue como URI de redirecionamento junto ao Didit.
O Auth0 acrescenta seu próprio
state ao redirecionamento para /authorize para poder retomar o login. O Didit adota esse state e o devolve para /continue, o que permite ao Auth0 concluir a transação. Você não precisa passar o state do Auth0 no corpo da PAR (ele só é gerado no momento do redirecionamento).Armazene o
code_verifier do PKCE por transação de login (usando event.transaction.id como chave), e não em um único campo app_metadata.
Se um usuário tentar novamente ou iniciar um login simultâneo, um único campo compartilhado será sobrescrito e a troca de token falhará com invalid_grant.Erros
Os erros seguem as RFC 6749 e RFC 9126. Uma falha na autenticação do cliente retorna401 com {"error": "invalid_client"}; um request_uri ou código de autorização expirado ou reutilizado retorna 400 com invalid_request ou invalid_grant.
Códigos de autorização, valores de request_uri e sessões de verificação são todos de uso único.