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
- A parte confiadora envia pedido de autorização para
POST /par, incluindo o desafio PKCE,state,nonce, o seuredirect_uriregistado, os scopesopenid profile identity_assurancee os claims que pretende que sejam verificados. A Didit devolve umrequest_uride utilização única, válido durante 60 segundos. - 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. - 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_urida parte confiadora com umcodede utilização única e ostateoriginal. - A parte confiadora troca o código em
POST /tokencom o seucode_verifiere recebe um ID token assinado.
Pedido de claims
Envie os claims a comparar dentro do parâmetroclaims 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 arrayverified_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 tipoIDV_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. GuardeDIDIT_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 devolve401 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.