API クライアントのデプロイ

ユーザーが Web アプリケーションに対して実行するステップは、API クライアントが実行するアクションに関連付けられます。

1. ユーザーがログインします。
   • ポリシー認証が開始されます。
     • 拒否が返された場合は、ユーザーが現在ログインできないことを通知するエラー・ページがアプリケーションから表示されます。
     • アプリケーションは、必要な要素に基づいてさまざまな UX を提供します。
     • あるいは、このステップがスキップされ、ユーザーが資格情報を提供した後に ROPC が実行されます。 パスワードが、実行可能な唯一の第 1 要素となります。
   • ユーザーが認証データを提供します。
     • API クライアントが要素 API を呼び出し、その後に JWT が /token に返されます。
     • これ以上の認証が不要であれば、これでユーザーが認証されます。 MFA が必要である場合は、適切な UX がユーザーに返されます。
   • ユーザーが MFA を実行します。
     • mfa_challenge スコープのトークンが返されるたびに、API クライアントが後続の要素の呼び出しを実行します。

以下の詳細について検討します。

• フル・アクセス・トークンのみをブラウザーに返します。 mfa_challenge が返されると、ブラウザー・セッションはトランザクションに入ります。
• アプリケーション・サーバーでリフレッシュ・トークンを保持します。
• アクセス・トークンがブラウザーに返される場合は、Web アプリケーションに期限切れのアクセス・トークンを検出するロジックが組み込まれています。 つまり、保護された API から返される 401 状態または 403 状態です。 この状態によって、アプリケーション・サーバーでリフレッシュ・トークン・フローが開始され、ブラウザーに新しいトークンが発行されます。 このフローでは、MFA が必要である場合に、追加の mfa_challenge を返すことができます。

以下の場合は、追加の検査を実行する必要があります。

• デプロイするリソース・サーバーが、API 付与タイプのアクセス・ポリシーを通じてクライアントに発行されるアクセス・トークンを使用する場合
• ISV が発行するアクセス・トークンに対してイントロスペクションが実行される場合

イントロスペクション時に、mfa_challenge アクセス・トークン

"active": true

が返されます。 リソース・サーバーでは、イントロスペクトされたアクセス・トークンの scope が mfa_challenge でないことをチェックする必要があります。

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
}