API 클라이언트 배치

사용자가 웹 애플리케이션에서 수행하는 단계는 API 클라이언트가 수행하는 조치와 연관이 있습니다.

1. 사용자가 로그인합니다.
   • 정책 auth가 시작됩니다.
     • 거부가 리턴되면 애플리케이션이 사용자가 현재 로그인할 수 없음을 표시하는 오류 페이지를 사용자에게 리턴합니다.
     • 애플리케이션은 요구된 요인을 기반으로 한 다양한 UX를 제공할 수 있습니다.
     • 또는 사용자가 인증 정보를 제공한 후 이 단계를 건너뛰고 ROPC를 수행합니다. 비밀번호는 수행할 수 있는 유일한 첫 번째 요인입니다.
   • 사용자는 인증 데이터를 제공합니다.
     • 요인 API가 API 클라이언트에 의해 호출된 다음 JWT가 다시 /token에 제공됩니다.
     • 추가 인증이 필요하지 않으면 이제 사용자가 인증됩니다. MFA가 필요한 경우 적절한 UX가 사용자로 리턴됩니다.
   • 사용자가 MFA를 완료합니다.
     • mfa_challenge 범위의 토큰이 리턴될 때마다 요인에 대한 후속 호출은 API 클라이언트에 의해 수행됩니다.

고려할 세부사항.

• 브라우저로 전체 액세스 토큰만 리턴하십시오. mfa_challenge가 리턴되면 브라우저 세션이 트랜잭션을 시작합니다.
• 애플리케이션 서버에 새로 고치기 토큰을 보관하십시오.
• 액세스 토큰이 브라우저로 리턴되면 웹 애플리케이션에 만료된 액세스 토큰을 발견하기 위한 로직이 포함됩니다. 즉, 보호된 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
}