권한 부여 유형

Verify그랜트 유형 은 클라이언트가 ID 토큰과 액세스 토큰을 가져오기 위해 사용하는 인증 메커니즘을 나타냅니다. 인증 코드, 암시적 인증, 인증 코드 및 암시적 인증, 디바이스 플로우, 리소스 소유자 자격 증명, JWT, 컨텍스트 기반 인증, 리프레시 토큰, 토큰 교환 중에서 선택할 수 있습니다.

지원되는 권한 부여 유형에 대한 비교 내용을 확인하고 애플리케이션에 대해 설정할 권한 부여 유형을 판별하려면 다음 표를 참조하십시오.
표 1. 지원 유형
특성 권한 코드 내재적 권한 코드 및 내재적
설명

권한 부여 엔드포인트 /authorize가 권한 코드를 리턴합니다. 권한 코드는 ID 토큰, 액세스 토큰 또는 새로 고치기 토큰과 교환할 수 있습니다.

토큰 엔드포인트 /token에서 ID 토큰 또는 액세스 토큰을 검색하려면 클라이언트 ID 및 시크릿을 사용한 클라이언트 인증이 필요합니다.

가장 일반적으로 사용되는 플로우입니다.

권한 부여 엔드포인트 /authorize가 직접 ID 토큰 또는 액세스 토큰을 리턴합니다.

권한 코드 또는 토큰 엔드포인트 /token이 사용되지 않습니다.

클라이언트 프론트 엔드 및 백엔드가 서로에게 독립적으로 토큰을 수신할 수 있습니다.

클라이언트가 권한 부여 엔드포인트 /authorize에서 권한 코드와 토큰을 얻습니다. 일부 토큰은 토큰 엔드포인트 /token에서 요청됩니다.

유스 케이스

클라이언트 시크릿을 안전하게 유지보수할 수 있는 클라이언트(예: 웹 애플리케이션 및 기본 모바일 애플리케이션)에 사용하십시오.

이는 사용자와 클라이언트를 인증하기 위한 것입니다.

클라이언트 시크릿을 보관할 수 없는 클라이언트(예: 브라우저 또는 Javascript)에 사용하십시오.

사용자를 인증하는 데 사용됩니다.

다음과 같은 클라이언트에 사용하십시오.
  • 클라이언트 시크릿을 안전하게 유지보수할 수 있는 클라이언트(예: 웹 애플리케이션 및 기본 모바일 애플리케이션)
  • ID 정보를 얻기 위해 ID 토큰에 즉시 액세스해야 하는 클라이언트
  • 새로 고치기 토큰을 사용하여 장기 토큰이 필요한 클라이언트
응답 유형 값
code
id_token
token
id_token token
code id_token
code token
code id_token token
모든 토큰이 권한 부여 엔드포인트에서 리턴됩니다. 아니오 아니오
모든 토큰이 토큰 엔드포인트에서 리턴됩니다. 아니오 아니오
토큰은 사용자 에이전트에 공개되지 않습니다. 아니오 아니오
클라이언트 애플리케이션을 인증할 수 있습니다. 아니오
새로 고치기 토큰을 생성합니다. 아니오
한 번의 왕복으로 통신 아니오 아니오
대부분의 서버 간 통신 아니오 다양함
로그인 힌트(login_hint)
이 값은 문자열로 된 사용자 이름(예: john@ibm.com) 또는 JSON일 수 있습니다. 예를 들어, 다음과 같습니다.
{"realm":"securityVerifyRealm",
"username":"john@ibm.com"}
. JSON 값을 사용할 때 범위는 ID 소스 범위를 나타냅니다.
이 값은 문자열로 된 사용자 이름(예: john@ibm.com) 또는 JSON일 수 있습니다. 예를 들어, 다음과 같습니다.
{"realm":"securityVerifyRealm",
"username":"john@ibm.com"}
. JSON 값을 사용할 때 범위는 ID 소스 범위를 나타냅니다.
이 값은 문자열로 된 사용자 이름(예: john@ibm.com) 또는 JSON일 수 있습니다. 예를 들어, 다음과 같습니다.
{"realm":"securityVerifyRealm",
"username":"john@ibm.com"}
. JSON 값을 사용할 때 범위는 ID 소스 범위를 나타냅니다.
최대 인증 수명(max_age) 이 값은 마지막으로 사용자가 적극적으로 인증된 후 허용되는 경과 시간(초)입니다. 이 속성은 Cloud Directory 로그인 세션에만 적용됩니다. 이 값은 마지막으로 사용자가 적극적으로 인증된 후 허용되는 경과 시간(초)입니다. 이 속성은 Cloud Directory 로그인 세션에만 적용됩니다. 이 값은 마지막으로 사용자가 적극적으로 인증된 후 허용되는 경과 시간(초)입니다. 이 속성은 Cloud Directory 로그인 세션에만 적용됩니다.
워크플로우
  1. 클라이언트에서 필수 요청 매개변수가 포함된 인증 요청을 준비합니다.
  2. 클라이언트가 인증 서버에 Verify 요청을 전송합니다.
  3. 인증 서버는 Verify 사용자를 인증합니다.
  4. 인증 서버는 Verify 사용자의 동의 또는 승인을 얻습니다.
  5. 인증 서버는 Verify 인증 코드를 함께 사용하여 사용자를 클라이언트로 되돌려 보냅니다.
  6. 클라이언트가 토큰 엔드포인트에서 권한 코드를 사용하여 인증 응답을 요청합니다.
  7. 클라이언트가 응답 본문에 ID 토큰과 액세스 토큰이 포함된 응답을 수신합니다.
  8. 클라이언트가 ID 토큰의 유효성을 검증하고 사용자의 주체 ID를 검색합니다.
  1. 클라이언트에서 필수 요청 매개변수가 포함된 인증 요청을 준비합니다.
  2. 클라이언트가 인증 서버에 Verify 요청을 전송합니다.
  3. 인증 서버는 Verify 사용자를 인증합니다.
  4. 인증 서버는 Verify 사용자의 동의 또는 승인을 얻습니다.
  5. 인증 서버는 Verify ID 토큰과, 요청된 경우 액세스 토큰을 함께 사용하여 사용자를 클라이언트로 되돌려 보냅니다.
  6. 클라이언트가 ID 토큰의 유효성을 검증하고 사용자의 주체 ID를 검색합니다.
  1. 클라이언트에서 필수 요청 매개변수가 포함된 인증 요청을 준비합니다.
  2. 클라이언트가 인증 서버에 Verify 요청을 전송합니다.
  3. 인증 서버는 Verify 사용자를 인증합니다.
  4. 인증 서버는 Verify 사용자의 동의 또는 승인을 얻습니다.
  5. 인증 서버는 Verify 인증 코드와 응답 유형에 따라 하나 이상의 매개변수를 포함하여 사용자를 클라이언트로 되돌려 보냅니다.
  6. 클라이언트가 토큰 엔드포인트에서 권한 코드를 사용하여 응답을 요청합니다.
  7. 클라이언트가 응답 본문에 ID 토큰과 액세스 토큰이 포함된 응답을 수신합니다.
  8. 클라이언트가 ID 토큰의 유효성을 검증하고 사용자의 주체 ID를 검색합니다.
표 2. 지원 유형 (계속)
특성 디바이스 플로우 자원 소유자 비밀번호 인증 정보 JWT
설명 이는 클라이언트가 URL에 전송된 QR 코드 또는 사용자 코드를 사용하여 권한 부여될 수 있도록 합니다. 클라이언트 및 사용자 인증은 클라이언트 ID, 클라이언트 시크릿, 사용자 이름 및 비밀번호를 사용하여 토큰 엔드포인트 /token에서 액세스 토큰 및 ID 토큰을 검색할 때 필요합니다. 사용자 이름 및 비밀번호는 Cloud Directory에 대해 유효성을 검증합니다. RFC7523에서 정의됩니다. 클라이언트가 서명되거나 암호화된 JWT 또는 권한 부여와 교환하기 위해 서명되고 암호화된 JWT를 표시할 수 있습니다. JWT는 권한 부여 서버에 의해 유효성 검증되며 JWT 내의 ID는 권한 부여의 주제로 사용됩니다.
유스 케이스
다음과 같은 클라이언트에 사용하십시오.
  • 사용자-에이전트 기반 OAuth 플로우를 수행할 브라우저가 없습니다.
  • 사용자에게 많은 텍스트를 입력하도록 요구하는 것이 실용적이지 않을 정도로 입력이 제한되어 있습니다.
몇 가지 예를 들면 스마트 TV, 미디어 콘솔, 디지털 액자 및 프린터 등이 있습니다.
이 권한 부여 유형은 사용으로 설정될 수 있지만 기타 플로우가 사용되지 않는 경우에만 사용하십시오. 이는 다음에 사용될 수 있습니다.
  • 클라이언트와 신뢰 관계에 있는 리소스 소유자. 예를 들어 디바이스 운영 체제 또는 높은 권한이 부여된 애플리케이션.
  • 대화식 양식을 사용하여 리소스 소유자의 인증 정보(사용자 이름 및 비밀번호)를 확보할 수 있는 클라이언트.
  • 저장된 인증 정보를 액세스 토큰으로 변환시켜 HTTP Basic 또는 Digest 인증과 같은 직접 인증 스킴을 사용하는 기존 클라이언트를 OAuth로 마이그레이션.
인증 서버(Verify)와 JWT를 발급하는 엔티티 사이에는 확립된 신뢰 관계가 존재합니다. 클라이언트는 엔티티를 발행하는 JWT로부터 JWT를 획득하고 이를 권한 부여와 교환하기 위해 권한 부여 서버에 제공합니다. JWT 발행 엔티티에는 자체 요구사항이 있을 수 있으며, 이는 JWT가 발행되기 전에 충족되어야 합니다(예: 대체 인증 및 권한 검사).
응답 유형 값 해당사항 없음 해당사항 없음 해당사항 없음
모든 토큰이 권한 부여 엔드포인트에서 리턴됩니다. 아니오 아니오 아니오
모든 토큰이 토큰 엔드포인트에서 리턴됩니다.
토큰은 사용자 에이전트에 공개되지 않습니다.
클라이언트 애플리케이션을 인증할 수 있습니다.
새로 고치기 토큰을 생성합니다.
한 번의 왕복으로 통신
대부분의 서버 간 통신
로그인 힌트(login_hint) 아니오 아니오 아니오
최대 인증 수명(max_age) 해당사항 없음
워크플로우
  1. 사용자가 사용자 코드 및 디바이스 코드를 요청하기 위해 디바이스에서 클라이언트 ID를 전송하여 플로우를 시작합니다.
  2. 클라이언트 ID가 유효한 경우에는 검증 URI, 사용자 코드 및 디바이스 코드가 리턴됩니다.
  3. 디바이스가 검증 URI를 표시하며 사용자가 브라우저에 입력하기 위한 사용자 코드, 또는 스캔하기 위한 QR 코드를 표시합니다.
  4. 디바이스가 지속적으로 디바이스 코드를 토큰과 교환하려 시도합니다.
  5. 사용자가 검증 URI 및 사용자 코드를 수동으로 스캔하거나 입력하여 사용자 코드를 OIDC 서비스에 전송합니다.
  6. 사용자 코드가 유효한 경우에는 성공 메시지가 전송되며 디바이스 코드가 액세스 토큰과 교환됩니다.
  1. 사용자는 RP(relying party)에서 하나의 양식으로 사용자 이름과 비밀번호를 입력합니다.
  2. 클라이언트는 토큰 엔드포인트로 사용자 이름, 비밀번호, 클라이언트 ID 및 클라이언트 시크릿을 전송합니다.
  3. 사용자 이름 및 비밀번호는 Cloud Directory에 대해 유효성을 검증합니다.
  4. 클라이언트는 응답 본문에 ID 토큰 및 액세스 토큰이 있는 응답을 수신합니다.
  1. 클라이언트는 JWT(외부 수단에 의해)를 획득하여 엔드포인트에 제공합니다.
  2. JWT의 유효성이 검증되고 주제 및 추가 속성이 추출됩니다.
  3. 클라이언트는 응답 본문에 ID 토큰 및 액세스 토큰이 있는 응답을 수신합니다.
표 3. 지원 유형 (계속)
특성 컨텍스트 기반 권한 부여 토큰 새로 고치기 토큰 교환
설명 추가 인증 및 권한 부여 검사가 수행되는 API 기반 플로우입니다. 권한 부여가 클라이언트에 발행되기 전에 다단계 인증이 필요할 수 있습니다. 클라이언트 ID, 클라이언트 시크릿 및 리프레시 토큰을 사용하여 토큰 엔드포인트 /token에서 새로운 액세스 토큰, ID 토큰 및 리프레시 토큰 세트를 가져오려면 클라이언트 및 사용자 인증이 필요합니다. 리프레시 토큰은 동일한 클라이언트 ID에 속해야 합니다. 이 흐름이 진행되는 동안 토큰과 연결된 속성 값은 갱신되지 않습니다. RFC8693 에 정의되어 있습니다. 클라이언트가 토큰을 제시하여 다른 토큰으로 교환할 수 있도록 합니다.
유스 케이스
  • 클라이언트는 권한 부여 서버의 인증 확인 유형 응답을 처리하도록 계측되어야 합니다.

  • 클라이언트는 에서 Verify 제공하는 인증 요소 API를 사용하여 JWT를 수신한 후, 이를 제시하여 흐름을 계속 진행합니다.
  • 클라이언트는 `context` 매개변수를 통해 추가 컨텍스트 정보를 요청에 포함해야 합니다.
이 그랜트 유형을 사용하여 유효 기간이 갱신된 새로운 액세스 토큰 세트를 획득하세요. 이를 통해 액세스 토큰의 유효 기간을 짧게 유지할 수 있지만, 사용자가 새로운 액세스 토큰을 얻기 위해 다시 로그인할 필요는 없습니다.
  • 사칭: 클라이언트가 다른 주체로 가장하여 리소스에 접근하는 행위.

  • 위임: 의뢰인이 권한을 부여받은 주체를 대신하여 행동하는 것.

응답 유형 값 해당사항 없음 해당사항 없음 해당사항 없음
모든 토큰이 권한 부여 엔드포인트에서 리턴됩니다. 아니오 아니오 아니오
모든 토큰이 토큰 엔드포인트에서 리턴됩니다.
토큰은 사용자 에이전트에 공개되지 않습니다.
클라이언트 애플리케이션을 인증할 수 있습니다.
새로 고치기 토큰을 생성합니다.
한 번의 왕복으로 통신
대부분의 서버 간 통신
로그인 힌트(login_hint) 아니오 아니오 아니오
최대 인증 수명(max_age) 해당사항 없음 아니오
워크플로우
  1. 클라이언트는 다음을 사용하여 요청과 함께 `컨텍스트`를 전달함으로써 흐름을 시작합니다. grant_type=Context-based authorization
  2. 클라이언트는 DENY(이 컨텍스트에서 액세스가 허용되지 않는 경우) 또는 CHALLENGE(리턴된 범위를 통해 식별됨)를 수신합니다.
  3. 클라이언트는 프롬프트 응답과 함께 리턴되는 액세스 토큰을 사용하여 플래그를 포함하여 사용 가능한 인증 요인 API에 액세스하여 요인 완료의 결과로 JWT를 요청합니다.
  4. 완료된 요인에서 리턴된 JWT는 JWT 전달자 권한 부여 요청(컨텍스트도 포함되어야 함)으로 /token에 다시 제공되며 토큰이 발행됩니다.
참고:
  • 구성된 정책에 따라 첫 번째 요인이 수행된 후 추가 요인이 필요할 수 있습니다. 이러한 요인으로 인해 두 번째 CHALLENGE와 두 번째 인증 요인이 수행될 수 있습니다.
  • 이 권한 부여 유형을 사용하려면 사용자 정의 액세스 정책을 작성하여 애플리케이션에 첨부해야 합니다. 이 액세스 정책에는 1단계 인증 규칙 및 선택적으로 2FA 요구사항이 포함되어야 합니다.
  1. 클라이언트가 액세스 토큰의 유효 기간이 만료되었거나 만료될 예정임을 확인하고, 새로운 액세스 토큰을 획득하고자 합니다.
  2. 클라이언트는 클라이언트 자격 증명과 갱신 토큰을 토큰 엔드포인트로 전송합니다.
  3. 리프레시 토큰과 클라이언트 자격 증명이 검증됩니다.
  4. 클라이언트는 응답 본문에 ID 토큰, 리프레시 토큰 및 액세스 토큰이 포함된 응답을 수신합니다.
  1. 클라이언트는 주체 토큰으로 사용할 토큰을 생성하거나 가져옵니다. 선택적으로, 배우 토큰도 포함될 수 있습니다.

  2. 해당 토큰과 선택적으로 행위자 토큰을 포함하여 인증 서버의 토큰 엔드포인트로 요청을 전송합니다.

  3. 인증 서버가 요청된 토큰을 반환합니다.