인터넷 응용 프로그램 인터페이스

Web API 앱은 웹 API에서 리소스를 가져와야 하는 웹 애플리케이션입니다. 이 시나리오에서는 웹 애플리케이션이 웹 API를 인증하고 호출하는 데 사용할 수 있는 두 가지 ID 형식이 있습니다.

• 애플리케이션 ID - 이 시나리오에서는 OAuth 2.0 클라이언트 자격 증명 부여를 사용하여 애플리케이션으로 인증하고 웹 API에 액세스합니다. 애플리케이션 ID를 사용하는 경우 웹 API는 웹 API가 사용자에 대한 정보를 수신하지 않으므로 웹 애플리케이션이 호출하고 있음을 감지할 수 있습니다. 애플리케이션이 사용자에 대한 정보를 수신하는 경우 애플리케이션 프로토콜을 통해 전송되고 Azure AD에서 서명되지 않습니다. 웹 API는 웹 애플리케이션이 사용자를 인증한 것을 신뢰합니다. 이러한 이유로 이 패턴을 신뢰할 수 있는 하위 시스템이라고 합니다.
• 위임된 사용자 ID - 이 시나리오는 OpenID Connect와 기밀 클라이언트를 사용한 OAuth 2.0 권한 부여 코드 부여의 두 가지 방법으로 수행할 수 있습니다. 웹 애플리케이션은 사용자에 대한 액세스 토큰을 얻습니다. 이 토큰은 웹 API에 사용자가 웹 애플리케이션에 성공적으로 인증되었고 웹 애플리케이션이 위임된 사용자 ID를 획득하여 웹 API를 호출할 수 있음을 증명합니다. 이 액세스 토큰은 사용자에게 권한을 부여하고 원하는 리소스를 반환하는 웹 API에 대한 요청에서 전송됩니다.

애플리케이션 ID와 위임된 사용자 ID 형식은 모두 아래 흐름에서 설명합니다. 둘 사이의 주요 차이점은 사용자가 로그인하고 웹 API에 액세스하기 전에 위임된 사용자 ID가 먼저 권한 부여 코드를 획득해야 한다는 것입니다.

도표

프로토콜 흐름

OAuth 2.0 클라이언트 자격 증명 부여를 사용하는 애플리케이션 ID

1. 사용자가 웹 애플리케이션에서 Azure AD에 로그인됩니다(자세한 내용은 웹앱 섹션 참조).
2. 웹 애플리케이션은 웹 API에 인증하고 원하는 리소스를 검색할 수 있도록 액세스 토큰을 획득해야 합니다. 자격 증명, 애플리케이션 ID 및 웹 API의 애플리케이션 ID URI를 제공하여 Azure AD의 토큰 엔드포인트에 요청합니다.
3. Azure AD는 애플리케이션을 인증하고 웹 API를 호출하는 데 사용되는 JWT 액세스 토큰을 반환합니다.
4. HTTPS를 통해 웹 애플리케이션은 반환된 JWT 액세스 토큰을 사용하여 웹 API에 대한 요청의 권한 부여 헤더에 "전달자" 지정이 있는 JWT 문자열을 추가합니다. 그런 다음 웹 API는 JWT 토큰의 유효성을 검사하고 유효성 검사가 성공하면 원하는 리소스를 반환합니다.

OpenID Connect를 사용하여 위임된 사용자 ID

1. 사용자가 Azure AD를 사용하여 웹 애플리케이션에 로그인합니다(위의 웹 브라우저-웹 애플리케이션 섹션 참조). 웹 애플리케이션의 사용자가 웹 애플리케이션이 웹 API를 대신 호출하도록 허용하는 데 아직 동의하지 않은 경우 사용자는 동의해야 합니다. 애플리케이션에 필요한 사용 권한이 표시되며 이러한 권한이 관리자 수준 권한인 경우 디렉터리의 일반 사용자가 동의할 수 없습니다. 이 동의 프로세스는 애플리케이션에 필요한 권한이 이미 있으므로 단일 테넌트 애플리케이션이 아닌 다중 테넌트 애플리케이션에만 적용됩니다. 사용자가 로그인했을 때 웹 애플리케이션은 사용자에 대한 정보와 권한 부여 코드가 포함된 ID 토큰을 받았습니다.
2. 웹 애플리케이션은 Azure AD에서 발급한 권한 부여 코드를 사용하여 권한 부여 코드, 클라이언트 애플리케이션에 대한 세부 정보(애플리케이션 ID 및 리디렉션 URI) 및 원하는 리소스(웹 API의 애플리케이션 ID URI)를 포함하는 Azure AD의 토큰 엔드포인트에 요청을 보냅니다.
3. 웹 애플리케이션 및 웹 API에 대한 권한 부여 코드 및 정보는 Azure AD에서 유효성을 검사합니다. 유효성 검사가 성공하면 Azure AD는 JWT 액세스 토큰과 JWT 새로 고침 토큰이라는 두 개의 토큰을 반환합니다.
4. HTTPS를 통해 웹 애플리케이션은 반환된 JWT 액세스 토큰을 사용하여 웹 API에 대한 요청의 권한 부여 헤더에 "전달자" 지정이 있는 JWT 문자열을 추가합니다. 그런 다음 웹 API는 JWT 토큰의 유효성을 검사하고 유효성 검사가 성공하면 원하는 리소스를 반환합니다.

OAuth 2.0 인증 코드 부여를 사용하여 위임된 사용자 ID

1. 인증 메커니즘이 Azure AD와 독립적인 웹 애플리케이션에 사용자가 이미 로그인되어 있습니다.
2. 웹 애플리케이션에는 액세스 토큰을 획득하기 위한 권한 부여 코드가 필요하므로 브라우저를 통해 Azure AD의 권한 부여 엔드포인트로 요청을 발급하여 인증에 성공한 후 웹 애플리케이션에 대한 애플리케이션 ID 및 리디렉션 URI를 제공합니다. 사용자가 Azure AD에 로그인합니다.
3. 웹 애플리케이션의 사용자가 웹 애플리케이션이 웹 API를 대신 호출하도록 허용하는 데 아직 동의하지 않은 경우 사용자는 동의해야 합니다. 애플리케이션에 필요한 사용 권한이 표시되며 이러한 권한이 관리자 수준 권한인 경우 디렉터리의 일반 사용자가 동의할 수 없습니다. 이 동의는 단일 및 다중 테넌트 애플리케이션 모두에 적용됩니다. 단일 테넌트 경우 관리자는 사용자를 대신하여 동의하도록 관리자 동의를 수행할 수 있습니다. Grant Permissions의 단추를 사용하여 수행할 수 있습니다.
4. 사용자가 동의하면 웹 애플리케이션은 액세스 토큰을 획득하는 데 필요한 권한 부여 코드를 받습니다.
5. 웹 애플리케이션은 Azure AD에서 발급한 권한 부여 코드를 사용하여 권한 부여 코드, 클라이언트 애플리케이션에 대한 세부 정보(애플리케이션 ID 및 리디렉션 URI) 및 원하는 리소스(웹 API의 애플리케이션 ID URI)를 포함하는 Azure AD의 토큰 엔드포인트에 요청을 보냅니다.
6. 웹 애플리케이션 및 웹 API에 대한 권한 부여 코드 및 정보는 Azure AD에서 유효성을 검사합니다. 유효성 검사가 성공하면 Azure AD는 JWT 액세스 토큰과 JWT 새로 고침 토큰이라는 두 개의 토큰을 반환합니다.
7. HTTPS를 통해 웹 애플리케이션은 반환된 JWT 액세스 토큰을 사용하여 웹 API에 대한 요청의 권한 부여 헤더에 "전달자" 지정이 있는 JWT 문자열을 추가합니다. 그런 다음 웹 API는 JWT 토큰의 유효성을 검사하고 유효성 검사가 성공하면 원하는 리소스를 반환합니다.

코드 샘플

Web Application to Web API 시나리오에 대한 코드 샘플을 참조하세요. 그리고 자주 새 샘플이 추가되니 자주 확인해 주세요. 웹 애플리케이션에서 Web API로.

앱 등록

Azure AD v1.0 엔드포인트에 애플리케이션을 등록하려면 앱등록을 참조하세요.

• 단일 테넌트 - 애플리케이션 ID 및 위임된 사용자 ID 사례 모두에 대해 웹 애플리케이션과 웹 API를 Azure AD의 동일한 디렉터리에 등록해야 합니다. 웹 API는 웹 애플리케이션의 리소스 액세스를 제한하는 데 사용되는 사용 권한 집합을 노출하도록 구성할 수 있습니다. 위임된 사용자 ID 유형을 사용하는 경우 웹 애플리케이션은 Azure Portal의 다른 애플리케이션 드롭다운 메뉴에 대한 사용 권한 에서 원하는 권한을 선택해야 합니다. 애플리케이션 ID 형식을 사용하는 경우에는 이 단계가 필요하지 않습니다.
• 다중 테넌트 - 먼저 웹 애플리케이션이 작동하는 데 필요한 권한을 나타내도록 구성됩니다. 대상 디렉터리의 사용자 또는 관리자가 애플리케이션에 동의하면 이 필수 사용 권한 목록이 대화 상자에 표시되어 조직에서 사용할 수 있습니다. 일부 애플리케이션에는 조직의 모든 사용자가 동의할 수 있는 사용자 수준 권한만 필요합니다. 다른 애플리케이션에는 조직의 사용자가 동의할 수 없는 관리자 수준 권한이 필요합니다. 디렉터리 관리자만 이 수준의 권한이 필요한 애플리케이션에 동의할 수 있습니다. 사용자 또는 관리자가 동의하면 웹 애플리케이션과 웹 API가 모두 해당 디렉터리에 등록됩니다.

토큰 만료

웹 애플리케이션이 권한 부여 코드를 사용하여 JWT 액세스 토큰을 가져오면 JWT 새로 고침 토큰도 수신합니다. 액세스 토큰이 만료되면 새로 고침 토큰을 사용하여 사용자를 다시 로그인할 필요 없이 다시 인증할 수 있습니다. 이 새로 고침 토큰은 사용자를 인증하는 데 사용되므로 새 액세스 토큰 및 새로 고침 토큰이 생성됩니다.

다음 단계

• 다른 애플리케이션 유형 및 시나리오 대해 자세히 알아보기
• Azure AD 인증 기본 사항 대해 알아봅니다.