Déploiement d'un client API

Les étapes qu'un utilisateur effectue sur l'application Web sont liées aux actions exécutées par le client API.

1. L'utilisateur se connecte.
   • L'autorisation de stratégie est lancée.
     • Si un refus est renvoyé, l'application renvoie une page d'erreur à l'utilisateur, qui indique que ce dernier ne peut pas se connecter actuellement.
     • L'application peut fournir une expérience utilisateur différente en fonction du facteur requis.
     • Sinon, cette étape est ignorée et ROPC est exécuté une fois que l'utilisateur a fourni des données d'identification. Le mot de passe est le seul premier facteur pouvant être exécuté.
   • L'utilisateur fournit des données d'authentification.
     • Une API de facteurs est appelée par le client API, puis le jeton Web JSON (JWT) est présenté à /token.
     • Si aucune authentification supplémentaire n'est requise, l'utilisateur est désormais authentifié. Si une authentification multi-facteur est requise, une expérience utilisateur adaptée est renvoyée à l'utilisateur.
   • L'utilisateur effectue l'authentification multi-facteur.
     • Les appels suivants aux facteurs sont effectués par le client API chaque fois qu'un jeton avec la portée mfa_challenge est renvoyé.

Détails à prendre en compte.

• Renvoyez uniquement des jetons d'accès complet au navigateur. Lorsqu'une portée mfa_challenge est renvoyée, la session de navigateur ouvre une transaction.
• Conservez le jeton d'actualisation sur le serveur d'applications.
• Si le jeton d'accès est renvoyé au navigateur, l'application Web inclut une logique permettant de détecter un jeton d'accès arrivé à expiration. Il s'agit d'une condition 401 ou 403 à partir d'une API protégée. Cette condition démarre un flux de jeton d'actualisation sur le serveur d'applications et un nouveau jeton est émis dans le navigateur. Ce flux permet de renvoyer une portée mfa_challenge supplémentaire lorsque l'authentification multi-facteur est requise.

Une vérification supplémentaire doit être effectuée :

• Lorsque vous déployez un serveur de ressources qui consomme des jetons d'accès qui sont émis sur un client via la stratégie d'accès pour les types d'octroi d'API.
• Lorsque l'introspection est effectuée sur un jeton d'accès émis par un éditeur de logiciel indépendant.

Un jeton d'accès mfa_challenge renvoie

"active": true

lors de l'introspection. Le serveur de ressources doit inclure une vérification que le scope du jeton d'accès qui est introspecté n'est pas mfa_challenge.

Exemple d'introspection d'un jeton 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
}