Implementando um cliente da API

As etapas que um usuário executa no aplicativo da web estão vinculadas às ações realizadas pelo cliente da API.

1. O usuário efetua login.
   • A autenticação da política é iniciada.
     • Se uma negação for retornada, o aplicativo retornará uma página de erro para o usuário que indica que o usuário não pode efetuar login no momento.
     • O aplicativo pode fornecer um UX variado com base no fator necessário.
     • Como alternativa, esta etapa é ignorada e o ROPC é executado depois que um usuário fornece credenciais. A senha é o único primeiro fator que pode ser executado.
   • O usuário fornece dados de autenticação.
     • Uma API de fatores é chamada pelo cliente da API, em seguida, o JWT é apresentado novamente ao /token.
     • Se nenhuma autenticação adicional for necessária, o usuário será autenticado agora. Se a MFA for necessária, um UX adequado será retornado ao usuário.
   • O usuário conclui a MFA
     • As chamadas de fatores subsequentes são pré-formadas pelo cliente da API sempre que um token com o escopo mfa_challenge é retornado.

Detalhes a serem considerados.

• Retorne somente tokens de acesso completos para o navegador. Quando um mfa_challenge é retornado, a sessão do navegador entra em uma transação.
• Mantenha o token de atualização no servidor de aplicativos.
• Se o token de acesso for retornado para o navegador, o aplicativo da web incluirá uma lógica para detectar um token de acesso expirado. Ou seja, uma condição 401 ou 403 de uma API protegida. Essa condição inicia um fluxo de token de atualização no servidor de aplicativos e um novo token é emitido para o navegador. Esse fluxo permite que um mfa_challenge adicional seja retornado quando a MFA for necessária.

Uma verificação adicional deve ser executada,

• Ao implantar um servidor de recursos que consome tokens de acesso que são emitidos para um cliente por meio de política de acesso para tipos de concessão de API.
• quando a introspecção é feita em um token de acesso que é emitido pelo ISV.

Um token de acesso mfa_challenge retorna

"active": true

após a introspecção. O servidor de recursos deve incluir uma verificação de que o scope do token de acesso submetido à introspecção não é mfa_challenge.

Um exemplo de introspecção de um token mfa_challenge.

{
  "entitlements": [
    "authn",
    "readEnrollMFAMethod"
  ],
  "at_hash": "Z3vQf5X3vzGu7sYqJShe_g",
  "ext": {
    "tenantId": "securitypoc.ice.ibmcloud.com"
  },
  "sub": "6030003FNL",
  "amr": [
    "password"
  ],
  "uniqueSecurityName": "6030003FNL",
  "iss": "https://securitypoc.ice.ibmcloud.com/oidc/endpoint/default",
  "active": true,
  "token_type": "Bearer",
  "client_id": "89136d7c-564b-4ea4-aa5b-19b0d9a8a47f",
  "aud": "89136d7c-564b-4ea4-aa5b-19b0d9a8a47f",
  "grant_type": "urn:ietf:params:oauth:grant-type:jwt-bearer",
  "restrictEntitlements": true,
  "scope": "mfa_challenge",
  "grant_id": "bdbdd509-2866-46cd-b5cf-f5c5a4385691",
  "category": "application",
  "exp": 1594019673,
  "app_id": "2512439131051198658",
  "iat": 1594017873
}