자격 증명 관리자의 OAuth 2.0 연결 - 프로세스 세부 정보 및 흐름

  • 아티클

적용 대상: 모든 API Management 계층

이 문서에서는 Azure API Management에서 자격 증명 관리자를 사용하여 OAuth 2.0 연결을 관리하기 위한 프로세스 흐름에 대해 자세히 설명합니다. 프로세스 흐름은 관리와 런타임의 두 부분으로 나뉩니다.

API Management의 자격 증명 관리자에 대한 배경 정보는 API Management의 자격 증명 관리자 및 API 자격 증명 정보를 참조하세요.

연결 관리

자격 증명 관리자 연결의 관리 부분은 OAuth 2.0 토큰에 대한 자격 증명 공급자를 설정 및 구성하고, 공급자에 대한 동의 흐름을 사용하도록 설정하고, 자격 증명에 액세스하기 위해 자격 증명 공급자에 대한 하나 이상의 연결을 설정하는 작업을 담당합니다.

다음 이미지는 인증 코드 권한 부여 형식을 사용하는 API Management에 연결을 만들기 위한 프로세스 흐름을 요약해서 보여줍니다.

자격 증명 만들기 프로세스 흐름을 보여 주는 다이어그램.

단계 Description
1 클라이언트가 자격 증명 공급자를 만들라는 요청을 보냅니다.
2 자격 증명 공급자가 만들어지고 응답이 되돌아옵니다.
3 클라이언트가 연결을 만들라는 요청을 보냅니다.
4 연결이 만들어지고 "연결이" 되지 않았다는 정보가 있는 응답이 되돌아옵니다.
5 클라이언트가 자격 증명 공급자에서 OAuth 2.0 동의를 시작하기 위해 로그인 URL을 검색하라는 요청을 보냅니다. 요청에는 마지막 단계에서 사용할 리디렉션 후 URL이 포함됩니다.
6 응답은 동의 흐름을 시작하는 데 사용해야 하는 로그인 URL과 함께 반환됩니다.
7 클라이언트는 이전 단계에서 제공된 로그인 URL이 있는 브라우저를 엽니다. 자격 증명 공급자의 OAuth 2.0 동의 흐름으로 브라우저가 리디렉션됩니다.
8 동의가 승인되면 인증 코드와 함께 자격 증명 공급자에 구성된 리디렉션 URL로 브라우저가 리디렉션됩니다.
9 API Management는 권한 부여 코드를 사용하여 액세스 및 새로 고침 토큰을 가져옵니다.
10 API Management는 토큰을 수신하고 암호화합니다.
11 API Management는 5단계에서 제공된 URL로 리디렉션됩니다.

자격 증명 공급자

자격 증명 공급자를 구성할 때 다양한 OAuth 공급자 및 권한 부여 유형(권한 부여 코드 또는 클라이언트 자격 증명) 중에서 선택할 수 있습니다. 각 공급자에는 특정 구성이 필요합니다. 유의해야 할 중요한 사항:

  • 자격 증명 공급자 구성에는 권한 부여 유형이 하나만 있을 수 있습니다.
  • 하나의 자격 증명 공급자 구성에는 여러 연결이 있을 수 있습니다.

참고 항목

일반 OAuth 2.0 공급자를 사용하면 OAuth 2.0 흐름의 표준을 지원하는 다른 ID 공급자를 사용할 수 있습니다.

자격 증명 공급자를 구성할 때 백그라운드 자격 증명 관리자는 공급자의 OAuth 2.0 액세스 토큰 및 새로 고침 토큰을 캐시하는 데 사용되는 자격 증명 저장소를 만듭니다.

자격 증명 공급자에 연결

공급자의 토큰에 액세스하고 사용하려면 클라이언트 앱이 자격 증명 공급자에 연결해야 합니다. 특정 연결은 Microsoft Entra ID ID를 기반으로 하는 액세스 정책에 의해 허용됩니다. 공급자에 대해 여러 연결을 구성할 수 있습니다.

연결을 구성하는 프로세스는 구성된 권한 부여에 따라 다르며 자격 증명 공급자 구성과 관련이 있습니다. 예를 들어 두 권한 부여 유형을 모두 사용하도록 Microsoft Entra ID를 구성하려면 두 가지 자격 증명 공급자 구성이 필요합니다. 다음 표에서는 두 권한 부여 유형을 요약해서 보여 줍니다.

권한 부여 유형 설명
인증 코드 사용자 컨텍스트에 바인딩됩니다. 즉, 사용자는 연결에 동의해야 합니다. 새로 고침 토큰이 유효한 한 API Management는 새 액세스 및 새로 고침 토큰을 검색할 수 있습니다. 새로 고침 토큰이 잘못되면 사용자는 다시 인증해야 합니다. 모든 자격 증명 공급자는 권한 부여 코드를 지원합니다. 자세한 정보
클라이언트 자격 증명 사용자에게 바인딩되지 않으며 애플리케이션-애플리케이션 시나리오에서 자주 사용됩니다. 클라이언트 자격 증명 부여 유형에 대한 동의는 필요하지 않으며 연결이 무효화되지 않습니다. 자세한 정보

인증 코드 권한 부여 유형을 기준으로 하는 연결의 경우 공급자에서 인증을 받고 권한 부여에 동의해야 합니다. 자격 증명 공급자의 로그인 및 권한 부여에 성공하면 공급자는 유효한 액세스 및 새로 고침 토큰을 반환하며, 이 토큰은 API Management에서 암호화되고 저장됩니다.

액세스 정책

각 연결에 대해 하나 이상의 액세스 정책을 구성합니다. 액세스 정책은 런타임 시 자격 증명에 액세스할 수 있는 Microsoft Entra ID를 결정합니다. 연결은 현재 서비스 주체, API Management 인스턴스의 ID, 사용자 및 그룹을 사용하여 액세스를 지원합니다.

ID 설명 이점 고려 사항
서비스 사용자 조직에서 Microsoft Entra ID를 사용하는 경우 해당 토큰을 사용하여 특정 Azure 리소스에 대한 액세스 권한을 인증하고 부여할 수 있는 ID. 조직에서는 서비스 주체를 사용하므로 리소스에 액세스해야 할 경우 인증을 관리하기 위해 가상 사용자를 만들 필요가 없습니다. 서비스 주체는 등록된 Microsoft Entra 애플리케이션을 나타내는 Microsoft Entra ID입니다. 연결 및 사용자 위임 시나리오에 대한 보다 엄격한 범위의 액세스를 허용합니다. 특정 API Management instance에 연결되지 않습니다. 권한 적용을 위해 Microsoft Entra ID를 사용합니다. 권한 부여 컨텍스트를 가져오려면 Microsoft Entra ID 토큰이 필요합니다.
관리 ID <Your API Management instance name> 이 옵션은 API Management 인스턴스에 연결된 관리 ID에 해당합니다. 기본적으로 해당 API 관리 인스턴스에 대한 시스템 할당 관리 ID에 대한 액세스가 제공됩니다. ID는 API Management 인스턴스에 연결됩니다. API Management 인스턴스에 대한 기여자 액세스 권한이 있는 모든 사용자는 관리 ID 권한을 부여하는 모든 연결에 액세스할 수 있습니다.
사용자 또는 그룹 Microsoft Entra ID 테넌트에 있는 사용자 또는 그룹입니다. 특정 사용자 또는 사용자 그룹에 대한 액세스를 제한할 수 있습니다. 사용자에게 Microsoft Entra ID 계정이 있어야 합니다.

연결 런타임

런타임 파트에서는 get-authorization-context 정책을 사용하여 백 엔드 OAuth 2.0 API를 구성해야 합니다. 런타임 시 정책은 API Management가 공급자에 대해 설정한 자격 증명 저장소에서 액세스 및 새로 고침 토큰을 가져와 저장합니다. 호출이 API Management로 들어오고 get-authorization-context 정책이 실행되면 먼저 기존 권한 부여 토큰이 유효한지 유효성을 검사합니다. 권한 부여 토큰이 만료된 경우 API Management는 OAuth 2.0 흐름을 사용하여 자격 증명 공급자에서 저장된 토큰을 새로 고칩니다. 그런 다음, 액세스 토큰을 사용하여 백 엔드 서비스에 대한 액세스 권한을 부여합니다.

정책을 실행하는 동안 액세스 정책을 사용하여 토큰에 대한 액세스도 유효성을 검사합니다.

다음 이미지는 권한 부여 코드 부여 유형을 사용하는 연결을 기반으로 권한 부여 및 새로 고침 토큰을 가져오고 저장하는 프로세스 흐름 예제를 보여줍니다. 토큰을 검색한 후 백 엔드 API에 대한 호출이 이루어집니다.

런타임 시 토큰을 검색하는 프로세스 흐름을 보여 주는 다이어그램.

단계 Description
1 클라이언트는 API Management 인스턴스에 요청을 보냅니다.
2 get-authorization-context 정책은 액세스 토큰이 현재 연결에 유효한지 확인합니다.
3 액세스 토큰이 만료되었지만 새로 고침 토큰이 유효한 경우 API Management는 구성된 자격 증명 공급자에서 새 액세스 및 새로 고침 토큰을 가져오려고 시도합니다.
4 자격 증명 공급자는 액세스 토큰과 새로 고침 토큰을 모두 반환하며, 이 토큰은 암호화되어 API Management에 저장됩니다.
5 토큰을 검색한 후 백 엔드 API에 보내는 요청에 대한 권한 부여 헤더로 set-header 정책을 사용하여 액세스 토큰이 연결됩니다.
6 응답이 API Management로 반환됩니다.
7 응답이 클라이언트로 반환됩니다.

관련 콘텐츠