AD FS OpenID Connect/OAuth 흐름 및 애플리케이션 시나리오

AD FS(Active Directory Federation Services) 2019 이상에 적용

암시적 권한 부여 흐름

단일 페이지 애플리케이션(AngularJS, Ember.js, React.js등)의 경우 AD FS는 OAuth 2.0 암시적 허용 흐름을 지원합니다. 암시적 흐름은 OAuth 2.0 사양에 설명되어 있습니다. 주요 이점은 백 엔드 서버 자격 증명 교환을 수행하지 않고도 앱에서 AD FS로부터 토큰을 가져올 수 있다는 이 있습니다. 이 흐름을 통해 앱은 사용자 로그인, 세션 유지관리, 클라이언트 JavaScript 코드 내에서 다른 웹 API에 토큰을 가져올 수 있습니다. 특히 클라이언트를 중심으로 암시적 흐름을 사용할 때 고려해야 할 몇 가지 중요한 보안 고려 사항이 있습니다.

암시적 흐름과 AD FS를 사용하여 인증을 JavaScript 앱에 추가하려면 다음 섹션의 일반 단계를 따릅니다.

프로토콜 다이어그램

다음 다이어그램은 전체 암시적 로그인 흐름의 모양을 보여줍니다. 다음 섹션에서는 각 단계를 자세히 설명합니다.

ID 토큰 및 액세스 토큰 요청

처음에 사용자를 앱에 로그인하려면 OpenID Connect 인증 요청을 보내고 AD FS 엔드포인트에서 id_token 및 액세스 토큰을 가져올 수 있습니다.

// Line breaks for legibility only

https://adfs.contoso.com/adfs/oauth2/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=id_token+token
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&scope=openid
&response_mode=fragment
&state=12345

이 시점에서 사용자에게 자격 증명을 입력하고 인증을 완료하라는 메시지가 표시됩니다. 사용자가 인증을 완료한 후 AD FS 권한 부여 엔드포인트는 response_mode 매개 변수에 지정된 메서드를 사용하여 지정된 redirect_uri로 앱에 응답을 반환합니다.

성공적인 응답

성공적인 응답은 사용되는 경우 response_mode=fragment and response_type=id_token+token 다음과 같습니다.

// Line breaks for legibility only

GET https://localhost/myapp/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZEstZnl0aEV...
&token_type=Bearer
&expires_in=3599
&scope=openid
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZstZnl0aEV1Q...
&state=12345

토큰 새로 고침

암시적 허용은 새로 고침 토큰을 제공하지 않습니다. id_tokens 및 access_tokens 모두 짧은 기간 후에 만료되므로 앱은 이러한 토큰을 주기적으로 새로 고칠 준비를 해야 합니다. 두 가지 유형의 토큰을 새로 고치려면 매개 변수를 사용하여 prompt=none ID 플랫폼의 동작을 제어하여 이전 섹션과 동일한 숨겨진 iframe 요청을 수행할 수 있습니다. 새 id_token를 받으려면 반드시 response_type=id_token를 사용하십시오.

인증 코드 부여 흐름

웹앱에서 OAuth 2.0 권한 부여 코드 부여를 사용하여 웹 API와 같은 보호된 리소스에 액세스할 수 있습니다. OAuth 2.0 인증 코드 흐름은 OAuth 2.0 사양의 섹션 4.1에서 설명합니다. 웹앱 및 기본적으로 설치된 앱을 포함하여 대부분의 앱 유형에서 인증 및 권한 부여를 수행하는 데 사용됩니다. 이 흐름을 통해 앱에서 AD FS를 신뢰하는 리소스에 액세스하는 데 사용할 수 있는 access_token을 안전하게 획득할 수 있습니다.

프로토콜 다이어그램

네이티브 애플리케이션의 인증 흐름은 개략적으로 다음과 같습니다.

인증 코드 요청

인증 코드 흐름은 클라이언트에서 사용자를 /authorization 엔드포인트에 연결하면서 시작됩니다. 이 요청에서 클라이언트는 사용자로부터 획득해야 하는 권한을 나타냅니다.

// Line breaks for legibility only

https://adfs.contoso.com/adfs/oauth2/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=query
&resource=https://webapi.com/
&scope=openid
&state=12345

이 시점에서 사용자에게 자격 증명을 입력하고 인증을 완료하라는 메시지가 표시됩니다. 사용자가 인증한 후 AD FS는 redirect_uri 매개 변수에 지정된 메서드를 사용하여 response_mode로 표시된 앱에 응답을 반환합니다.

성공적인 응답

response_mode=query가 사용되는 경우 성공적인 응답은 다음과 같습니다.

GET https://adfs.contoso.com/common/oauth2/nativeclient?
code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&state=12345

액세스 토큰 요청

이제 authorization_code을(를) 획득하고 사용자가 권한을 부여했으므로 access_token에 대한 코드를 원하는 리소스로 사용할 수 있습니다. POST 요청을 /token 엔드포인트로 보내 코드를 교환합니다.

// Line breaks for legibility only

POST /adfs/oauth2/token HTTP/1.1
Host: https://adfs.contoso.com/
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&code=OAAABAAAAiL9Kn2Z27UubvWFPbm0gLWQJVzCTE9UkP3pSx1aXxUjq3n8b2JRLk4OxVXr...
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&grant_type=authorization_code
&client_secret=JqQX2PNo9bpM0uEihUPzyrh    // NOTE: Only required for confidential clients (web apps)

성공적인 응답

성공적인 토큰 응답은 다음과 같습니다.

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "token_type": "Bearer",
    "expires_in": 3599,
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "refresh_token_expires_in": 28800,
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD...",
}

액세스 토큰 사용

GET /v1.0/me/messages
Host: https://webapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...

토큰 부여 흐름 새로 고침

access_token은 수명이 짧으며, 만료된 후 새로 고쳐야 리소스에 계속 액세스할 수 있습니다. 이렇게 하려면 다른 POST 요청을 /token엔드포인트에 제출합니다. 이번에는 코드 대신 refresh_token을 제공합니다. 새로 고침 토큰은 클라이언트가 이미 액세스 토큰을 받은 모든 권한에 유효합니다.

새로 고침 토큰에는 지정된 수명이 없습니다. 일반적으로 새로 고침 토큰의 수명은 비교적 깁니다. 그러나 경우에 따라 새로 고침 토큰이 만료되거나, 해지되거나, 원하는 작업에 대한 충분한 권한이 없습니다. 애플리케이션은 토큰 발급 엔드포인트에서 반환하는 오류를 예상하고 정확히 처리해야 합니다.

새 액세스 토큰을 획득하는 데 사용할 때 새로 고침 토큰이 해지되지 않지만, 이전의 새로 고침 토큰은 삭제해야 합니다. OAuth 2.0 사양은 다음과 같습니다. "권한 부여 서버는 새 새로 고침 토큰을 발급할 수 있습니다. 이 경우 클라이언트는 이전 새로 고침 토큰을 삭제하고 새 새로 고침 토큰으로 바꿔야 합니다. 권한 부여 서버는 클라이언트에 새 새로 고침 토큰을 발급한 후 이전 새로 고침 토큰을 해지할 수 있습니다." 새 새로 고침 토큰 수명이 이전 새로 고침 토큰 수명보다 길면 AD FS에서 새로 고침 토큰을 발급합니다. AD FS 새로 고침 토큰 수명에 대한 추가 정보를 보려면 AD FS Single Sign-On 설정을 참조하세요.

// Line breaks for legibility only

POST /adfs/oauth2/token HTTP/1.1
Host: https://adfs.contoso.com
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&refresh_token=OAAABAAAAiL9Kn2Z27UubvWFPbm0gLWQJVzCTE9UkP3pSx1aXxUjq...
&grant_type=refresh_token
&client_secret=JqQX2PNo9bpM0uEihUPzyrh      // NOTE: Only required for confidential clients (web apps)

성공적인 응답

성공적인 토큰 응답은 다음과 같습니다.

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "token_type": "Bearer",
    "expires_in": 3599,
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "refresh_token_expires_in": 28800,
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD...",
}

OAuth에 PKCE(코드 교환용 증명 키) 지원

권한 부여 코드 부여를 사용하는 OAuth 공용 클라이언트는 RFC 7636에 설명된 대로 권한 부여 코드 가로채기 공격에 취약합니다. 이러한 공격을 완화하기 위해 Windows Server 2019를 기준으로 AD FS는 OAuth 인증 코드 부여 흐름에 대한 PKCE(코드 교환용 증명 키)를 지원합니다.

PKCE 지원 사양은 OAuth 2.0 권한 부여 및 액세스 토큰 요청에 더 많은 매개 변수를 추가합니다. 다음 다이어그램에서는 클라이언트가 Windows Server 2019에서 AD FS에 연결할 때 PKCE 프로세스의 개요를 보여 줍니다.

A라는 레이블이 지정된 섹션에서 클라이언트는 code_verifier(이)라고 지정된 비밀을 만들고 기록하며, t(code_verifier)(이)라고 하는 변환된 버전의 비밀(code_challenge(이)라고도 함)을 파생시킵니다. 그런 다음, 클라이언트는 변환 방법과 함께 OAuth 2.0 권한 부여 요청에서 t_m 비밀을 보냅니다.

B라는 레이블이 지정된 섹션에서 권한 부여 엔드포인트는 평소와 같이 응답하지만 t(code_verifier) 비밀 및 변환 메서드를 기록합니다.

C라는 레이블이 지정된 섹션에서 클라이언트는 액세스 토큰 요청에서 권한 부여 코드를 평소처럼 보내지만 섹션 A에서 생성된 비밀을 포함합니다 code_verifier .

D라는 레이블이 지정된 섹션에서 AD FS는 비밀을 변환 code_verifier하고 B 섹션의 t(code_verifier) 비밀과 비교합니다. 값이 같지 않으면 AD FS는 액세스를 거부합니다.

Windows Server 2019에서 동일한 규칙 정책에 대해 여러 인증 공급자를 선택하는 방법

AD FS는 이미 클레임 규칙 정책(RP)을 기반으로 하는 추가 인증 트리거를 지원합니다. 특정 RP 또는 전역 수준에서 이러한 정책을 설정할 수 있습니다. 관리자 권한으로 PowerShell을 열고 Set-AdfsRelyingPartyTrust cmdlet을 실행하여 AdditionalAuthenticationRules 또는 AdditionalAuthenticationRulesFile 매개 변수를 전달하여 특정 RP에 대한 추가 인증 정책을 설정할 수 있습니다. 이를 전역으로 설정하려면 관리자는 Set-AdfsAdditionalAuthenticationRule cmdlet을 사용할 수 있습니다. 추가 정책을 설정하면 동일한 애플리케이션에 둘 이상의 인증 공급자를 사용할 수 있습니다.

클레임 규칙은 추가 인증을 위해 인증 공급자를 선택하는 옵션을 제공합니다. 이는 고객이 공급자 간에 전환하거나 특정 애플리케이션에 대해 고유한 공급자를 요구하는 상황에서 유용합니다. Windows Server 2019를 기준으로 클레임 규칙을 사용하여 추가 인증을 위해 호출할 다른 인증 공급자를 결정할 수 있습니다. 이 기능은 다음 두 가지 시나리오에서 유용합니다.

• 사용자가 한 인증 공급자에서 다른 인증 공급자로 전환하고 있습니다. 사용자를 새로운 인증 공급자에게 온보딩할 때 그룹을 사용하여 서비스가 사용하는 추가 인증 공급자를 제어할 수 있습니다.

• 사용자는 특정 애플리케이션에 대한 특정 추가 인증 공급자가 필요하지만 다른 애플리케이션에서는 또 다른 방법을 사용해야 합니다.

다른 인증 정책에서 다음 명령을 실행하여 이러한 설정을 구성할 수 있습니다.

Set-AdfsAdditionalAuthenticationRule -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = "http://schemas.microsoft.com/claims/multipleauthn" );' 

이 규칙을 설정하려면 다른 인증 정책에서 http://schemas.microsoft.com/claims/authnmethodsproviders 클레임을 발급해야 합니다. 이 클레임의 변수는 인증 공급자의 이름이어야 합니다.

사용자가 한 인증 공급자에서 다른 인증 공급자로 전환할 수 있도록 이 규칙 구성을 수정할 수도 있습니다. 예를 들어 Microsoft Entra MFA(다단계 인증)를 사용하도록 관리하는 그룹 하나와 인증서를 추가 인증 공급자로 사용하도록 한 그룹을 수정하려고 합니다.

MFA 및 인증서 인증에 등록하는 사용자 수를 추적하려는 경우 다음과 같은 명령을 실행하여 값이 조직과 관련된 값으로 대체될 수 있습니다.

'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

 c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-608905689-872870963-3921916988-12345"] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "AzureMfaAuthentication"); 

not exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value=="S-1-5-21-608905689-872870963-3921916988-12345"]) => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "CertificateAuthentication");’ 

다음으로, 다음 명령을 실행하여 MFA를 추가 인증 공급자로 사용하도록 첫 번째 애플리케이션을 AppA설정할 수 있습니다.

Set-AdfsRelyingPartyTrust -TargetName AppA -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "AzureMfaAuthentication");' 

마지막으로 다음 명령을 실행하여 인증서를 추가 인증 공급자로 사용하도록 두 번째 앱(호출 AppB)을 설정할 수 있습니다.

Set-AdfsRelyingPartyTrust -TargetName AppB -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "CertificateAuthentication");' 

관리자는 둘 이상의 추가 인증 공급자를 허용하는 규칙을 만들 수도 있습니다. 이 경우 AD FS는 발급된 인증 방법 공급자를 표시하며 사용자는 해당 공급자 중 하나를 선택할 수 있습니다. 여러 개의 추가 인증 공급자를 허용하려면 값을 http://schemas.microsoft.com/claims/authnmethodsproviders사용하여 여러 클레임을 발급해야 합니다.

클레임 평가에서 인증 공급자를 반환하지 않는 경우, AD FS는 롤백하고 AD FS에서 관리자가 구성한 모든 추가 인증 공급자를 보여 주는 목록을 표시합니다. 그런 다음 사용자는 적절한 인증 공급자를 수동으로 선택해야 합니다.

기본 인증 공급자가 목록에 없는 경우 다음 cmdlet을 실행하여 지원되는 모든 공급자를 볼 수 있습니다.

(Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider

클레임에 http://schemas.microsoft.com/claims/authnmethodsproviders 사용하는 값은 AD FS가 반환한 공급자 목록에서 반환된 공급자 이름 중 하나여야 합니다.

RP가 AD FS Windows Server 2016의 액세스 제어 정책을 사용하는 동안 AD FS는 특정 추가 인증 공급자 트리거를 지원하지 않습니다. 애플리케이션을 액세스 제어 정책 밖으로 이동하면 AD FS는 해당 정책을 Access Control Policy에서 AdditionalAuthenticationRules 및 IssuanceAuthorizationRules로 복사합니다. 관리자가 특정 인증 공급자를 사용하려는 경우 액세스 제어 정책 사용을 중지하고 대신 AdditionalAuthenticationRules를 수정해야 합니다.

On-Behalf-Of flow

OAuth 2.0 OBO(On-Behalf-Of) 흐름은 애플리케이션에서 서비스/웹 API를 호출하고, 이에 따라 다른 서비스/웹 API를 호출해야 하는 사용 사례를 처리합니다. 요청 체인을 통해 위임된 사용자 ID 및 사용 권한을 전파하는 개념입니다. 중간 계층 서비스가 다운스트림 서비스에 대해 인증된 요청을 하려면 사용자를 대신하여 AD FS에서 액세스 토큰을 보호해야 합니다.

프로토콜 다이어그램

사용자가 이전 섹션에서 설명한 OAuth 2.0 권한 부여 코드 부여 흐름을 사용하여 애플리케이션에서 인증된다고 가정합니다. 이 시점에서 애플리케이션에는 중간 계층 웹 API(API A) 액세스에 대한 사용자의 클레임 및 동의가 있는 API A에 대한 액세스 토큰(토큰 A)이 있습니다. 클라이언트가 토큰의 스코프에서 user_impersonation을 요청해야 합니다. 이제 API A는 다운스트림 웹 API(API B)에 인증된 요청을 수행해야 합니다.

다음 단계는 OBO 흐름을 구성하며, 다음 다이어그램의 지원을 통해 설명됩니다.

1. 클라이언트 애플리케이션은 토큰 A를 사용하여 API A에 요청합니다. (AD FS에서 OBO 흐름을 구성할 때 범위 user_impersonation 가 선택되고 클라이언트가 요청에서 범위를 요청 user_impersonation 해야 합니다.)
2. API A는 AD FS 토큰 발급 엔드포인트에 인증하고 API B에 액세스하기 위한 토큰을 요청합니다. (AD FS에서 이 흐름을 구성할 때 API A가 API A의 리소스 ID와 동일한 값을 가진 클라이언트 ID로 서버 애플리케이션으로 등록되었는지 확인합니다.)
3. AD FS 토큰 발급 엔드포인트에서 토큰 A를 사용하여 API A의 자격 증명에 대한 유효성을 검사하고, API B(토큰 B)에 대한 액세스 토큰을 발급합니다.
4. 토큰 B가 API B에 대한 요청의 권한 부여 헤더에 설정됩니다.
5. API B에서 보안 리소스의 데이터를 반환합니다.

서비스 간 액세스 토큰 요청

액세스 토큰을 요청하려면 다음 섹션에 설명된 매개 변수를 사용하여 AD FS 토큰 엔드포인트에 대한 HTTP POST를 만듭니다.

첫 번째 사례: 공유 암호를 사용한 액세스 토큰 요청

공유 비밀의 경우 서비스 간 액세스 토큰 요청에 포함되는 매개 변수는 다음과 같습니다.

Example

다음은 HTTP POST 액세스 토큰 및 새로 고침 토큰을 요청합니다.

// Line breaks for legibility only

POST /adfs/oauth2/token HTTP/1.1
Host: adfs.contoso.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&client_id=https://webapi.com/
&client_secret=BYyVnAt56JpLwUcyo47XODd
&assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIm…
&resource=https://secondwebapi.com/
&requested_token_use=on_behalf_of
&scope=openid

두 번째 사례: 인증서를 사용한 액세스 토큰 요청

인증서를 사용하는 서비스 간 액세스 토큰 요청에 포함되는 매개 변수는 다음과 같습니다.

매개 변수는 거의 동일합니다. 이 예제는 client_secret 매개 변수가 client_assertion_type과 client_assertion이라는 두 매개 변수로 대체된다는 점을 제외하고 공유 비밀을 통한 요청과 유사합니다.

Example

다음 HTTP POST는 인증서를 사용하여 웹 API에 대한 액세스 토큰을 요청합니다.

// Line breaks for legibility only

POST /adfs/oauth2/token HTTP/1.1
Host: https://adfs.contoso.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&client_id= https://webapi.com/
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6Imd4OHRHeXN5amNS…
&resource=https://secondwebapi.com/
&requested_token_use=on_behalf_of
&scope= openid

서비스 간 액세스 토큰 응답

성공 응답은 다음 매개 변수가 있는 JSON OAuth 2.0 응답입니다.

성공 응답 예제

다음 예제에서는 웹 API용 액세스 토큰 요청에 대한 성공 응답을 보여 줍니다.

{
  "token_type": "Bearer",
  "scope": openid,
  "expires_in": 3269,
  "access_token": "eyJ0eXAiOiJKV1QiLCJub25jZSI6IkFRQUJBQUFBQUFCbmZpRy1t"
  "id_token": "aWRfdG9rZW49ZXlKMGVYQWlPaUpLVjFRaUxDSmhiR2NpT2lKU1V6STFOa"
  "refresh_token": "OAQABAAAAAABnfiG…"
  "refresh_token_expires_in": 28800,
}

액세스 토큰을 사용하여 보안 리소스에 액세스

이제 중간 계층 서비스는 이전 응답 예제에서 획득한 토큰을 사용하여 다운스트림 웹 API에 대해 인증된 요청을 수행할 수 있습니다. 권한 부여 헤더에서 토큰을 설정합니다.

Example

GET /v1.0/me HTTP/1.1
Host: https://secondwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJub25jZSI6IkFRQUJBQUFBQUFCbmZpRy1tQ…

클라이언트 자격 증명 부여 흐름

RFC 6749에 지정된 OAuth 2.0 클라이언트 자격 증명 부여를 사용하여 애플리케이션의 ID를 사용하여 웹 호스팅 리소스에 액세스할 수 있습니다. 이 유형의 권한 부여는 일반적으로 사용자의 직접적인 상호 작용 없이 백그라운드에서 실행해야 하는 서버 간 상호 작용에 사용됩니다. 이러한 유형의 애플리케이션은 종종 디먼 또는 서비스 계정이라고 합니다.

OAuth 2.0 클라이언트 자격 증명 부여 흐름은 사용자를 가장하는 대신 다른 웹 서비스를 호출할 때 웹 서비스(기밀 클라이언트)가 자체 자격 증명을 사용하여 인증하도록 허용합니다. 이 시나리오에서 클라이언트는 일반적으로 중간 계층 웹 서비스, 디먼 서비스 또는 웹 사이트입니다. 더 높은 수준의 보증을 위해 AD FS를 사용하면 호출 서비스에서 공유 비밀 대신 인증서를 자격 증명으로 사용할 수도 있습니다.

프로토콜 다이어그램

다음 다이어그램에서는 클라이언트 자격 증명 부여 흐름을 보여 줍니다.

토큰 요청

클라이언트 인증서 부여를 사용하여 토큰을 얻으려면, 다음 섹션에 표시된 대로 POST 요청을 /token AD FS 엔드포인트로 보내십시오.

첫 번째 사례: 공유 암호를 사용한 액세스 토큰 요청

POST /adfs/oauth2/token HTTP/1.1
// Line breaks for legibility only

Host: https://adfs.contoso.com
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&client_secret=qWgdYAmab0YSkuL1qKv5bPX
&grant_type=client_credentials

두 번째 사례: 인증서를 사용한 액세스 토큰 요청

POST /adfs/oauth2/token HTTP/1.1

// Line breaks for legibility only

Host: https://adfs.contoso.com
Content-Type: application/x-www-form-urlencoded

&client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6Imd4OHRHeXN5amNScUtqRlBuZDdSRnd2d1pJMCJ9.eyJ{a lot of characters here}M8U3bSUKKJDEg
&grant_type=client_credentials

토큰 사용

이제 토큰을 획득했으므로 토큰을 사용하여 리소스에 대한 요청을 수행합니다. 토큰이 만료되면 /token 엔드포인트에 요청을 반복하여 새 액세스 토큰을 획득합니다.

GET /v1.0/me/messages
Host: https://webapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...

리소스 소유자 암호 자격 증명 부여 흐름(권장되지 않음)

ROPC(리소스 소유자 암호 자격 증명) 부여를 사용하면 애플리케이션에서 사용자의 암호를 직접 처리하여 사용자를 로그인할 수 있습니다. ROPC 흐름에는 높은 수준의 신뢰와 사용자 노출이 필요합니다. 더 안전한 다른 흐름을 사용할 수 없는 경우에만 이 흐름을 사용해야 합니다.

프로토콜 다이어그램

다음 다이어그램에서는 ROPC 흐름을 보여 줍니다.

권한 부여 요청

ROPC 흐름은 단일 요청입니다. 즉, 클라이언트 ID 및 사용자의 자격 증명을 IDP로 보낸 다음, 응답으로 토큰을 받습니다. 이렇게 하려면 먼저 클라이언트에서 사용자의 이메일 주소(UPN) 및 암호를 요청해야 합니다. 요청이 성공하는 즉시 클라이언트는 메모리에서 사용자의 자격 증명을 안전하게 해제해야 합니다. 절대 이를 저장하면 안 됩니다.

// Line breaks and spaces are for legibility only

POST /adfs/oauth2/token HTTP/1.1
Host: https://adfs.contoso.com
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope= openid
&username=myusername@contoso.com
&password=SuperS3cret
&grant_type=password

성공적인 인증 응답

다음 예제에서는 성공적인 토큰 응답을 보여 줍니다.

{
    "token_type": "Bearer",
    "scope": "openid",
    "expires_in": 3599,
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIn...",
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "refresh_token_expires_in": 28800,
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDR..."
}

새로 고침 토큰을 사용하여 이 문서의 인증 코드 부여 흐름 섹션에 설명된 것과 동일한 흐름을 사용하여 새 액세스 토큰을 획득하고 토큰을 새로 고칠 수 있습니다.

디바이스 코드 흐름

디바이스 코드 부여를 사용하면 사용자가 스마트 TV, IoT 디바이스 또는 프린터와 같은 입력 제한 디바이스에 로그인할 수 있습니다. 이 흐름을 사용하도록 설정하기 위해 디바이스에서 사용자가 다른 디바이스의 브라우저에 있는 웹 페이지를 방문하여 로그인하도록 합니다. 사용자가 로그인한 후 디바이스는 필요에 따라 액세스 토큰을 가져오고 토큰을 새로 고칠 수 있습니다.

프로토콜 다이어그램

전체 디바이스 코드 흐름은 다음 다이어그램에 표시된 흐름과 유사합니다. 각 단계는 이 문서의 뒷부분에 설명되어 있습니다.

디바이스 권한 부여 요청

클라이언트에서 먼저 인증을 시작하는 데 사용되는 디바이스 및 사용자 코드에 대한 인증 서버를 확인해야 합니다. 클라이언트는 /devicecode 엔드포인트에서 이 요청을 수집합니다. 이 요청에서 클라이언트는 사용자로부터 획득해야 하는 권한도 포함해야 합니다. 이 요청이 전송된 시점부터 사용자는 로그인하는 데 15분(expires_in 일반적인 값)만 있으므로 사용자가 로그인할 준비가 되었다고 표시한 경우에만 이 요청을 수행합니다.

// Line breaks are for legibility only

POST https://adfs.contoso.com/adfs/oauth2/devicecode
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
scope=openid

디바이스 권한 부여 응답

성공적인 응답은 사용자가 로그인하는 데 필요한 정보가 포함된 JSON 개체입니다.

사용자 인증

클라이언트는 user_code 수신하고 verification_uri 사용자에게 이러한 세부 정보를 표시하여 휴대폰 또는 PC 브라우저를 사용하여 로그인하도록 지시합니다. 또한 클라이언트에서 QR 코드 또는 비슷한 메커니즘을 사용하여 verfication_uri_complete을 표시할 수 있습니다. 이 경우 사용자에 대한 user_code를 입력하는 단계가 수행됩니다. 사용자가 verification_uri에서 인증하는 동안 클라이언트에서 device_code를 사용하여 요청된 토큰에 대한 /token 엔드포인트를 폴링해야 합니다.

POST https://adfs.contoso.com /adfs/oauth2/token
Content-Type: application/x-www-form-urlencoded

grant_type: urn:ietf:params:oauth:grant-type:device_code
client_id: 00001111-aaaa-2222-bbbb-3333cccc4444
device_code: GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8

성공적인 인증 응답

성공적인 토큰 응답에는 다음 매개 변수가 포함될 수 있습니다.

관련 콘텐츠

관련 흐름을 사용하는 방법에 대한 단계별 지침을 제공하는 전체 연습 문서 목록은 AD FS 개발을 참조하세요.