Azure API Management의 API에 대한 인증 및 권한 부여
적용 대상: 모든 API Management 계층
이 문서에서는 관리되는 API에 대한 사용자의 액세스를 보호하는 데 도움이 되는 API Management의 풍부하고 유연한 기능 집합을 소개합니다.
API Management의 API 인증 및 권한 부여에는 API Management 게이트웨이와 백엔드 API를 통한 클라이언트 앱의 종단 간 통신 보안이 포함됩니다. 많은 고객 환경에서 OAuth 2.0이 기본 설정되는 API 권한 부여 프로토콜입니다. API Management 클라이언트와 API Management 게이트웨이 간, 게이트웨이와 백엔드 API 간 또는 둘 다 독립적으로 OAuth 2.0 권한 부여를 지원합니다.
API Management OAuth 2.0을 보완하거나 API에 대한 OAuth 2.0 권한 부여가 불가능할 때 유용한 다른 클라이언트 쪽 및 서비스 쪽 인증 및 권한 부여 메커니즘을 지원합니다. 이러한 옵션 중에서 선택하는 방법은 조직의 API 환경의 완성도, 보안 및 규정 준수 요구 사항 및 일반적인 API 위협을 완화하기 위한 조직의 접근 방식에 따라 달라집니다.
Important
API에 대한 사용자의 액세스를 보호하는 것은 API Management 환경을 보호하기 위한 많은 고려 사항 중 하나입니다. 자세한 내용은 API Management를 위한 Azure 보안 기준을 참조하세요.
참고 항목
다른 API Management 구성 요소에는 사용자 액세스를 보호하고 제한하는 별도의 메커니즘이 있습니다.
- Azure 컨트롤 플레인을 통해 API Management 인스턴스를 관리하기 위해 API Management는 Microsoft Entra ID 및 Azure RBAC(역할 기반 액세스 제어)를 사용합니다.
- 개발자 포털에는 보안 사용자 등록 및 로그인을 용이하게 하는 몇 가지 옵션이 있습니다.
인증 대 권한 부여
다음은 API 액세스 컨텍스트에서 인증 및 권한 부여에 대한 간략한 설명입니다.
인증 - API에 액세스하는 사용자 또는 앱의 ID를 확인하는 프로세스입니다. 인증은 사용자 이름 및 암호와 같은 자격 증명, 인증서 또는 SSO(Single Sign-On) 또는 기타 방법을 통해 수행할 수 있습니다.
승인 - 종종 OAuth 2.0과 같은 토큰 기반 프로토콜을 통해 사용자 또는 앱이 특정 API에 액세스할 수 있는 권한이 있는지 확인하는 프로세스입니다.
참고 항목
인증 및 권한 부여를 보완하려면 TLS를 사용하여 API에 대한 액세스를 보호하여 인증 또는 권한 부여에 사용되는 자격 증명 또는 토큰을 보호해야 합니다.
OAuth 2.0 개념
OAuth 2.0은 웹 API와 같은 리소스에 대한 액세스를 보호하는 데 널리 사용되는 표준 권한 부여 프레임워크입니다. OAuth 2.0은 사용자의 자격 증명을 공유하지 않고도 클라이언트 앱이 사용자를 대신하여 리소스에서 수행할 수 있는 작업을 제한합니다. OAuth 2.0은 인증 프로토콜은 아니지만 사용자 인증 및 SSO 기능을 제공하여 OAuth 2.0을 확장하는 OIDC(OpenID Connect)와 함께 사용되는 경우가 많습니다.
OAuth 흐름
클라이언트 앱이 TLS 및 OAuth 2.0을 사용하여 보호되는 요청으로 API를 호출하면 어떻게 되나요? 다음은 간략한 흐름 예입니다.
클라이언트(호출 앱 또는 전달자)는 ID 공급자에 대한 자격 증명을 사용하여 인증합니다.
클라이언트는 ID 공급자의 권한 부여 서버에서 시간이 제한된 액세스 토큰(JSON 웹 토큰 또는 JWT)을 가져옵니다.
ID 공급자(예: Microsoft Entra ID)는 토큰의 발급자이며 토큰에는 리소스 서버(예: 백 엔드 API 또는 API Management 게이트웨이 자체)에 대한 액세스를 승인하는 대상 그룹 클레임이 포함됩니다.
클라이언트는 API를 호출하고 액세스 토큰을 제공합니다(예: 권한 부여 헤더).
리소스 서버는 액세스 토큰의 유효성을 검사합니다. 유효성 검사는 발급자 및 대상 그룹 클레임에 예상 값이 포함되어 있는지 유효성을 검사하는 복잡한 프로세스입니다.
토큰 유효성 검사 조건에 따라 백엔드 API의 리소스에 대한 액세스 권한이 부여됩니다.
클라이언트 앱 및 시나리오 형식에 따라 토큰을 요청하고 관리하는 데 서로 다른 인증 흐름이 필요합니다. 예를 들어 인증 코드 흐름 및 부여 형식은 웹 API를 호출하는 앱에서 일반적으로 사용됩니다. Microsoft Entra ID의 OAuth 흐름 및 애플리케이션 시나리오에 대해 자세히 알아봅니다.
API Management OAuth 2.0 권한 부여 시나리오
시나리오 1 - 클라이언트 앱이 백엔드에 직접 권한을 부여합니다.
일반적인 권한 부여 시나리오는 호출 애플리케이션이 백엔드 API에 대한 액세스를 직접 요청하고 게이트웨이에 권한 부여 헤더에 OAuth 2.0 토큰을 제공하는 경우입니다. 그런 다음 Azure API Management 호출자와 백엔드 API 간의 "투명한" 프록시 역할을 하며 변경되지 않은 토큰을 통해 백엔드에 전달합니다. 액세스 토큰의 범위는 호출 애플리케이션과 백 엔드 API 사이입니다.
다음 이미지는 Microsoft Entra ID가 권한 부여 공급자인 예제를 보여 줍니다. 클라이언트 앱은 SPA(단일 페이지 애플리케이션)일 수 있습니다.
HTTP 요청과 함께 전송된 액세스 토큰은 백엔드 API용이지만 API Management는 여전히 심층 방어 방법을 허용합니다. 예를 들어 JWT의 유효성을 검사를 하도록 정책을 구성하여 토큰 없이 도착한 요청이나 의도한 백엔드 API에 유효하지 않은 토큰을 거부합니다. 토큰에서 추출된 다른 관심 클레임을 확인하도록 API Management를 구성할 수도 있습니다.
참고 항목
이러한 방식으로 OAuth 2.0을 사용하여 Azure API Management 통해 노출되는 API를 보호하는 경우 Azure Portal 또는 개발자 포털 테스트 콘솔 사용자를 대신하여 테스트 목적으로 유효한 토큰을 생성하도록 API Management를 구성할 수 있습니다. API Management instance OAuth 2.0 서버를 추가하고 API에서 OAuth 2.0 권한 부여 설정을 사용하도록 설정해야 합니다. 자세한 내용은 OAuth 2.0 사용자 권한 부여를 구성하여 개발자 포털의 테스트 콘솔을 권한 부여하는 방법을 참조하세요.
예시:
팁
Microsoft Entra ID를 사용하여 API 액세스를 보호하는 특별한 경우 validate-azure-ad-token 토큰 유효성 정책을 구성할 수 있습니다.
시나리오 2 - 클라이언트 앱이 API Management 권한을 부여합니다.
이 시나리오에서 API Management 서비스는 API를 대신하여 작동하고 호출 애플리케이션은 API Management 인스턴스에 대한 액세스를 요청합니다. 액세스 토큰의 범위는 호출 애플리케이션과 API Management 게이트웨이 사이입니다. API Management에서 게이트웨이가 요청을 백엔드에 전달하기 전에 토큰의 유효성을 검사하도록 정책(validate-jwt 또는 validate-azure-ad-token)을 구성합니다. 별도의 메커니즘은 일반적으로 게이트웨이와 백엔드 API 간의 연결을 보호합니다.
다음 예제에서 Microsoft Entra ID는 다시 권한 부여 공급자이며 mTLS(상호 TLS) 인증은 게이트웨이와 백엔드 간의 연결을 보호합니다.
이렇게 하려는 데에는 여러 가지 이유가 있습니다. 예시:
백엔드는 OAuth를 지원하도록 업데이트할 수 없는 레거시 API입니다.
API Management는 먼저 토큰의 유효성을 검사하도록 구성해야 합니다(최소한 발급자 및 대상 그룹 클레임 유효성 검사). 유효성 검사 후 mTLS(상호 TLS) 인증과 같은 API Management 이후 연결을 보호하는 데 사용할 수 있는 여러 옵션 중 하나를 사용합니다. 이 문서 뒷부분의 서비스 쪽 옵션을 참조하세요.
백엔드에 필요한 컨텍스트는 호출자로부터 설정할 수 없습니다.
API Management가 호출자로부터 받은 토큰의 유효성을 성공적으로 유효성 검사한 후에는 자체 컨텍스트 또는 호출 애플리케이션에서 파생된 컨텍스트를 사용하여 백 엔드 API에 대한 액세스 토큰을 가져와야 합니다. 이 시나리오는 다음 중 하나를 사용하여 수행할 수 있습니다.
구성된 ID 공급자로부터 백엔드 API에 유효한 정방향 액세스 토큰을 가져오기 위한 send-request와 같은 사용자 지정 정책입니다.
API Management 인스턴스의 고유 ID – API Management 리소스의 시스템 할당 또는 사용자 할당 관리 ID에서 백 엔드 API로 토큰을 전달합니다.
organization은 표준화된 권한 부여 접근 방식을 채택하려고 합니다.
조직은 API 백엔드의 인증 및 권한 부여 메커니즘에 관계없이 프런트 엔드에서 표준화된 권한 부여 접근 방식을 위해 OAuth 2.0에 수렴하도록 선택할 수 있습니다. API Management 게이트웨이는 organization 백엔드가 발전함에 따라 API 소비자에게 일관된 권한 부여 구성 및 일반적인 환경을 가능하게 할 수 있습니다.
시나리오 3: API Management가 백엔드에 권한을 부여함
관리형 연결(이전의 권한 부여)을 사용하면 API Management의 자격 증명 관리자를 사용하여 LinkedIn, GitHub 또는 기타 OAuth 2.0 호환 백 엔드와 같은 하나 이상의 백 엔드 또는 SaaS 서비스에 대한 액세스 권한을 부여합니다. 이 시나리오에서 사용자 또는 클라이언트 앱은 ID 공급자 또는 기타 클라이언트 쪽 옵션을 사용하여 제어되는 게이트웨이 액세스를 사용하여 API Management 게이트웨이에 요청을 수행합니다. 그런 다음 정책 구성을 통해 사용자 또는 클라이언트 앱이 API Management의 백엔드 인증 및 권한 부여를 위임합니다.
다음 예제에서는 클라이언트와 게이트웨이 간에 구독 키가 사용되고 GitHub는 백 엔드 API에 대한 자격 증명 공급자입니다.
자격 증명 공급자에 대한 연결을 사용하여 API Management는 OAuth 2.0 흐름에서 API 액세스에 대한 토큰을 획득하고 새로 고칩니다. 연결은 다음과 같은 여러 시나리오에서 토큰 관리를 간소화합니다.
- 클라이언트 앱은 GraphQL 확인자를 사용하여 여러 필드를 resolve 위해 여러 SaaS 백 엔드에 권한을 부여해야 할 수 있습니다.
- 사용자는 ID 공급자에서 SSO로 API Management 인증하지만 공통 조직 계정을 사용하여 백 엔드 SaaS 공급자(예: LinkedIn)에 권한을 부여합니다.
- 클라이언트 앱(또는 봇)이 인증된 사용자를 대신하여 보호되는 백 엔드 온라인 리소스에 액세스해야 하는 시나리오(예: 메일 확인 또는 주문)
예:
API를 보호하는 기타 옵션
권한 부여가 선호되고 OAuth 2.0이 API에 대한 강력한 권한 부여를 사용하도록 설정하는 주요 방법이 되지만 API Management 클라이언트와 게이트웨이(클라이언트 쪽) 또는 게이트웨이와 백 엔드(서비스 쪽) 간의 액세스를 보호하거나 제한하는 몇 가지 다른 메커니즘을 제공합니다. organization 요구 사항에 따라 OAuth 2.0을 보완하는 데 사용할 수 있습니다. 또는 호출 애플리케이션 또는 백 엔드 API가 레거시이거나 OAuth 2.0을 아직 지원하지 않는 경우 독립적으로 구성합니다.
클라이언트 쪽 옵션
| 메커니즘 | 설명 | 고려 사항 |
|---|---|---|
| mTLS | 연결 클라이언트에서 제공하는 인증서의 유효성을 검사하고 API Management 관리되는 인증서에 대해 인증서 속성을 검사 | 인증서는 키 자격 증명 모음에 저장될 수 있습니다. |
| 호출자 IP 제한 | 특정 IP 주소 또는 주소 범위에서 호출을 필터링(허용/거부)합니다. | 특정 사용자 또는 조직에 대한 액세스 또는 업스트림 서비스의 트래픽을 제한하는 데 사용합니다. |
| 구독 키 | API Management 구독에 따라 하나 이상의 API에 대한 액세스 제한 | 다른 인증 또는 권한 부여 방법과 함께 구독(API) 키를 사용하는 것이 좋습니다. 구독 키는 그 자체로 강력한 인증 형식이 아니지만 구독 키의 사용은 개별 고객의 API 사용 추적 또는 특정 API 제품에 대한 액세스와 같은 특정 시나리오에서 유용할 수 있습니다. |
팁
심층 방어를 위해 API Management instance 웹 애플리케이션 방화벽 업스트림 배포하는 것이 좋습니다. 예를 들어 Azure Application Gateway 또는 Azure Front Door를 사용합니다.
서비스 쪽 옵션
| 메커니즘 | 설명 | 고려 사항 |
|---|---|---|
| 관리 ID 인증 | 시스템 할당 또는 사용자 할당 관리 ID를 사용하여 백 엔드 API에 인증합니다. | Microsoft Entra ID에서 토큰을 가져와 보호된 백 엔드 리소스에 대한 범위가 지정된 액세스에 권장됩니다. |
| 인증서 인증 | 클라이언트 인증서를 사용하여 백 엔드 API에 인증합니다. | 인증서는 키 자격 증명 모음에 저장될 수 있습니다. |
| 인증 유형 | 권한 부여 헤더를 통해 전달되는 사용자 이름 및 암호를 사용하여 백 엔드 API에 인증합니다. | 더 나은 옵션을 사용할 수 있는 경우 권장되지 않습니다. |
다음 단계
- Microsoft ID 플랫폼의 인증 및 권한 부여에 대해 자세히 알아봅니다.
- API Management를 사용하여 OWASP API 보안 위협을 완화하는 방법을 알아봅니다.