Azure Logic Apps에서 사용자 지정 API를 호출할 때 인증 추가
API 호출에 대한 보안을 강화하기 위해 Azure Portal을 통해 Microsoft Entra 인증을 설정하면 코드를 업데이트할 필요가 없습니다. 또는 API 코드를 통해 인증을 요구하고 적용할 수 있습니다.
인증은 다음과 같은 방법으로 추가할 수 있습니다.
코드 변경 없음: Azure Portal을 통해 Microsoft Entra ID로 API를 보호하므로 코드를 업데이트하거나 API를 다시 배포할 필요가 없습니다.
참고 항목
기본적으로 Azure Portal에서 선택하는 Microsoft Entra 인증은 세분화된 권한 부여를 제공하지 않습니다. 예를 들어 이 인증을 통해 특정 사용자 또는 앱이 아니라 특정 테넌트에 대한 API를 잠급니다.
API 코드 업데이트: 코드를 통해 인증서 인증, 기본 인증 또는 Microsoft Entra 인증을 적용하여 API를 보호합니다.
코드를 변경하지 않고 API에 대한 호출 인증
이 방법의 일반적인 단계는 다음과 같습니다.
두 개의 Microsoft Entra 애플리케이션 ID를 만듭니다. 하나는 논리 앱 리소스용이고 다른 하나는 웹앱(또는 API 앱)용입니다.
API에 대한 호출을 인증하려면 논리 앱의 Microsoft Entra 애플리케이션 ID와 연결된 서비스 주체에 대한 자격 증명(클라이언트 ID 및 비밀)을 사용합니다.
애플리케이션 ID를 논리 앱의 워크플로 정의에 포함합니다.
1부: 논리 앱에 대한 Microsoft Entra 애플리케이션 ID 만들기
논리 앱 리소스는 이 Microsoft Entra 애플리케이션 ID를 사용하여 Microsoft Entra ID에 대해 인증합니다. 디렉터리에 대해 이 ID를 한 번만 설정하면 됩니다. 예를 들어 논리 앱마다 고유한 ID를 만들 수 있더라도 모든 논리 앱에 대해 동일한 ID를 사용하도록 선택할 수 있습니다. Azure Portal에서 또는 PowerShell을 사용하여 이러한 ID를 설정할 수 있습니다.
Azure Portal에서 Microsoft Entra ID를 선택합니다.
웹앱 또는 API 앱과 동일한 디렉터리에 있는지 확인합니다.
팁
디렉터리를 전환하려면 프로필을 선택하고 다른 디렉터리를 선택합니다. 또는 개요>디렉터리 전환을 차례로 선택합니다.
디렉터리 메뉴의 관리 아래에서 앱 등록>새 등록을 차례로 선택합니다.
모든 등록 목록에 디렉터리의 모든 앱 등록이 표시됩니다. 앱 등록만 보려면 소유한 애플리케이션을 선택합니다.
논리 앱의 애플리케이션 ID에 대해 사용자에게 표시되는 이름을 제공합니다. 지원되는 계정 유형을 선택합니다. 리디렉션 URI에 대해 웹을 선택하고, 인증 응답을 반환할 고유한 URL을 제공한 다음, 등록을 선택합니다.
이제 소유한 애플리케이션 목록에 만든 애플리케이션 ID가 포함되어 있습니다. 이 ID가 표시되지 않으면 도구 모음에서 새로 고침을 선택합니다.
앱 등록 목록에서 새 애플리케이션 ID를 선택합니다.
애플리케이션 ID 탐색 메뉴에서 개요를 선택합니다.
개요 창의 기본 정보 아래에서 3부에서 논리 앱에 대한 "클라이언트 ID"로 사용할 애플리케이션 ID를 복사하고 저장합니다.
애플리케이션 ID 탐색 메뉴에서 인증서 및 비밀을 선택합니다.
클라이언트 암호 탭에서 새 클라이언트 암호를 선택합니다.
설명에 대해 비밀의 이름을 입력합니다. 만료에 대해 비밀의 기간을 선택합니다. 완료되면 추가를 선택합니다.
만든 비밀은 논리 앱에 대한 애플리케이션 ID의 "비밀" 또는 암호 역할을 합니다.
이제 인증서 및 비밀 창의 클라이언트 암호 아래에 비밀 값 및 비밀 ID와 함께 비밀이 표시됩니다.
나중에 사용할 수 있도록 비밀 값을 복사합니다. 3부에서 논리 앱을 구성할 때 이 키를 "비밀" 또는 암호로 지정합니다.
2부: 웹앱 또는 API 앱용 Microsoft Entra 애플리케이션 ID 만들기
웹앱 또는 API 앱이 이미 배포된 경우 Azure Portal에서 인증을 설정하고 애플리케이션 ID를 만들 수 있습니다. 그렇지 않으면 Azure Resource Manager 템플릿으로 배포할 때 인증을 설정할 수 있습니다.
Azure Portal에서 배포된 웹앱 또는 API 앱에 대한 애플리케이션 ID 만들기
Azure Portal에서 웹앱 또는 API 앱을 찾고 선택합니다.
설정 아래에서 인증>ID 공급자 추가를 차례로 선택합니다.
ID 공급자 추가 창이 열리면 기본 사항 탭의 ID 공급자 목록에서 Microsoft를 선택하여 Microsoft Entra ID를 사용한 다음 추가를 선택합니다.
이제 다음과 같이 웹앱 또는 API 앱에 대한 애플리케이션 ID를 만듭니다.
앱 등록 유형에 대해 새 앱 등록 만들기를 선택합니다.
이름에 대해 애플리케이션 ID의 이름을 제공합니다.
지원되는 계정 유형에 대해 시나리오에 적합한 계정 유형을 선택합니다.
액세스 제한에 대해 인증 필요를 선택합니다.
인증되지 않은 요청에 대해 시나리오에 따라 옵션을 선택합니다.
완료되면 추가를 선택합니다.
웹앱 또는 API 앱에 대해 방금 만든 애플리케이션 ID가 이제 ID 공급자 섹션에 표시됩니다.
팁
애플리케이션 ID가 표시되지 않으면 도구 모음에서 새로 고침을 선택합니다.
이제 웹앱 또는 API 앱에 대해 방금 만든 애플리케이션 ID의 애플리케이션(클라이언트) ID 및 테넌트 ID를 찾아야 합니다. 이러한 ID는 3부에서 사용됩니다. 따라서 Azure Portal에 대해 다음 단계를 계속합니다.
Azure Portal에서 웹앱 또는 API 앱에 대한 애플리케이션 ID의 클라이언트 ID 및 테넌트 ID 찾기
웹앱의 탐색 메뉴에서 인증을 선택합니다.
ID 공급자 섹션에서 이전에 만든 애플리케이션 ID를 찾습니다. 애플리케이션 ID의 이름을 선택합니다.
애플리케이션 ID의 개요 창이 열리면 애플리케이션(클라이언트) ID 및 디렉터리(테넌트) ID 값을 찾습니다. 3부에서 사용하기 위해 값을 복사하고 저장합니다.
또한 필요한 경우 웹앱 또는 API 앱의 배포 템플릿에서 이 테넌트 ID GUID를 사용할 수 있습니다. 이 GUID는 특정 테넌트의 GUID("테넌트 ID")이며
https://sts.windows.net/{GUID}
URL에 표시되어야 합니다.
Azure Resource Manager 템플릿을 사용하여 배포할 때 인증 설정
ARM 템플릿(Azure Resource Manager 템플릿)을 사용하는 경우에도 논리 앱의 앱 ID와 다른 웹앱 또는 API 앱용 Microsoft Entra 애플리케이션 ID를 만들어야 합니다. 애플리케이션 ID를 만든 다음, 클라이언트 ID와 테넌트 ID를 찾으려면 Azure Portal에 대한 2부의 이전 단계를 수행합니다. 앱의 배포 템플릿 및 3부에서도 클라이언트 ID와 테넌트 ID를 모두 사용합니다.
Important
웹앱 또는 API 앱에 대한 Microsoft Entra 애플리케이션 ID를 만들 때 PowerShell이 아닌 Azure Portal을 사용해야 합니다. PowerShell commandlet은 웹 사이트에 사용자가 로그인하는 데 필요한 권한을 설정하지 않습니다.
클라이언트 ID와 테넌트 ID를 가져온 후에는 이러한 ID를 웹앱 또는 API 앱의 하위 리소스로 배포 템플릿에 포함합니다.
"resources": [
{
"apiVersion": "2015-08-01",
"name": "web",
"type": "config",
"dependsOn": ["[concat('Microsoft.Web/sites/','parameters('webAppName'))]"],
"properties": {
"siteAuthEnabled": true,
"siteAuthSettings": {
"clientId": "<client-ID>",
"issuer": "https://sts.windows.net/<tenant-ID>/"
}
}
}
]
Microsoft Entra 인증과 함께 빈 웹앱과 논리 앱을 자동으로 배포하려면 여기에서 전체 템플릿을 확인하거나 다음 Azure에 배포 단추를 선택합니다.
3부: 논리 앱의 권한 부여 섹션 채우기
이전 템플릿에는 이미 이 권한 부여 섹션이 설정되어 있지만, 논리 앱 정의를 직접 작성하는 경우 권한 부여 섹션 전체를 포함해야 합니다.
코드 보기에서 논리 앱 정의를 엽니다.
HTTP 작업 정의로 이동하고, 권한 부여 섹션을 찾아서 다음 속성을 포함합니다.
{
"tenant": "<tenant-ID>",
"audience": "<client-ID-from-Part-2-web-app-or-API app>",
"clientId": "<client-ID-from-Part-1-logic-app>",
"secret": "<secret-from-Part-1-logic-app>",
"type": "ActiveDirectoryOAuth"
}
속성 | 필수 | 설명 |
---|---|---|
tenant |
예 | Microsoft Entra 테넌트의 GUID |
audience |
예 | 액세스하려는 대상 리소스의 GUID, 즉 웹앱 또는 API 앱에 대한 애플리케이션 ID의 클라이언트 ID |
clientId |
예 | 액세스를 요청하는 클라이언트의 GUID, 즉 논리 앱에 대한 애플리케이션 ID의 클라이언트 ID |
secret |
예 | 액세스 토큰을 요청하는 클라이언트에 대한 애플리케이션 ID의 비밀 또는 암호 |
type |
예 | 인증 유형입니다. ActiveDirectoryOAuth 인증의 경우 이 값은 ActiveDirectoryOAuth 입니다. |
예시:
{
"actions": {
"HTTP": {
"inputs": {
"method": "POST",
"uri": "https://your-api-azurewebsites.net/api/your-method",
"authentication": {
"tenant": "tenant-ID",
"audience": "client-ID-from-azure-ad-app-for-web-app-or-api-app",
"clientId": "client-ID-from-azure-ad-app-for-logic-app",
"secret": "key-from-azure-ad-app-for-logic-app",
"type": "ActiveDirectoryOAuth"
}
}
}
}
}
코드를 통한 API 호출 보호
인증서 인증
논리 앱 워크플로에서 웹앱 또는 API 앱으로 들어오는 요청의 유효성을 검사하기 위해 클라이언트 인증서를 사용할 수 있습니다. 코드를 설정하려면 TLS 상호 인증을 구성하는 방법을 참조하세요.
권한 부여 섹션에서 다음 속성을 포함합니다.
{
"type": "ClientCertificate",
"password": "<password>",
"pfx": "<long-pfx-key>"
}
속성 | 필수 | 설명 |
---|---|---|
type |
예 | 인증 유형입니다. TLS/SSL 클라이언트 인증서의 경우 이 값은 ClientCertificate 여야 합니다. |
password |
아니요 | 클라이언트 인증서(PFX 파일)에 액세스하기 위한 암호 |
pfx |
예 | 클라이언트 인증서(PFX 파일)의 Base64로 인코딩된 콘텐츠 |
기본 인증
논리 앱에서 웹앱 또는 API 앱으로 들어오는 요청의 유효성을 검사하기 위해 사용자 이름 및 암호와 같은 기본 인증을 사용할 수 있습니다. 기본 인증은 일반적인 패턴이며, 웹앱 또는 API 앱을 빌드하는 데 사용되는 언어에서 이 인증을 사용할 수 있습니다.
권한 부여 섹션에서 다음 속성을 포함합니다.
{
"type": "Basic",
"username": "<username>",
"password": "<password>"
}
속성 | 필수 | 설명 |
---|---|---|
type |
예 | 사용할 인증 유형입니다. 기본 인증의 경우 값은 Basic 이어야 합니다. |
username |
예 | 인증에 사용할 사용자 이름 |
password |
예 | 인증에 사용할 암호 |
코드를 통한 Microsoft Entra 인증
기본적으로 Azure Portal에서 설정하는 Microsoft Entra 인증은 세분화된 권한 부여를 제공하지 않습니다. 예를 들어 이 인증을 통해 특정 사용자 또는 앱이 아니라 특정 테넌트에 대한 API를 잠급니다.
코드를 통해 논리 앱에 대한 API 액세스를 제한하려면 JWT(JSON Web Token)가 포함된 헤더를 추출합니다. 호출자의 ID를 확인하고 일치하지 않는 요청을 거부합니다.