Microsoft Entra 다단계 인증 외부 방법 공급자 참조(미리 보기)
이 항목에서는 외부 인증 공급자가 Microsoft Entra MFA(다단계 인증)에 연결하는 방법에 대해 설명합니다. 외부 인증 공급자는 EAM(외부 인증 방법)으로 Microsoft Entra ID 테넌트와 통합할 수 있습니다. EAM은 리소스 또는 애플리케이션에 액세스하기 위한 MFA 요구 사항의 두 번째 단계를 충족할 수 있습니다. EAM에는 최소한 Microsoft Entra ID P1 라이선스가 필요합니다.
사용자가 로그인하면 해당 테넌트 정책이 평가됩니다. 인증 요구 사항은 사용자가 액세스하려는 리소스에 따라 결정됩니다.
해당 매개 변수에 따라 여러 정책이 로그인에 적용될 수 있습니다. 이러한 매개 변수에는 사용자 및 그룹, 애플리케이션, 플랫폼, 로그인 위험 수준 등이 포함됩니다.
인증 요구 사항에 따라 사용자는 MFA 요구 사항을 충족하기 위해 다른 요소로 로그인해야 할 수도 있습니다. 두 번째 단계는 첫 번째 단계의 형식을 보완해야 합니다.
EAM은 테넌트 관리자가 Microsoft Entra ID에 추가합니다. 테넌트가 MFA를 위해 EAM을 요구하는 경우 Microsoft Entra ID가 두 가지를 모두 유효성 검사한 후 로그인이 MFA 요구 사항을 충족하는 것으로 간주됩니다.
- Microsoft Entra ID로 완료된 첫 번째 단계
- EAM으로 완료된 두 번째 단계
해당 유효성 검사는 다음 중 두 가지 이상의 메서드 형식에 대한 MFA 요구 사항을 충족합니다.
- 알고 있는 내용(지식)
- 가지고 있는 항목(소유)
- 사용자의 신원 정보(선천적 특성)
EAM은 OIDC(Open ID Connect) 위에 구현됩니다. 이 구현에는 공개적으로 연결되는 엔드포인트가 3개 이상 필요합니다.
- 공급자 메타데이터 검색에 설명된 OIDC 검색 엔드포인트
- 유효한 OIDC 인증 엔드포인트
- 공급자의 공용 인증서가 게시되는 URL
EAM에서 로그인이 작동하는 방식을 자세히 살펴보겠습니다.
- 사용자는 Microsoft Entra ID로 보호되는 애플리케이션에 암호와 같은 첫 번째 단계에서 로그인을 시도합니다.
- Microsoft Entra ID에서는 다른 요소가 충족되어야 한다고 판단합니다. 예를 들어, 조건부 액세스 정책에는 MFA가 필요합니다.
- 사용자는 EAM을 두 번째 단계로 선택합니다.
- Microsoft Entra ID는 사용자의 브라우저 세션을 EAM URL로 리디렉션합니다.
- 이 URL은 관리자가 EAM을 만들 때 프로비전한 검색 URL에서 발견됩니다.
- 애플리케이션은 사용자와 테넌트를 식별하는 정보가 포함된 만료되었거나 거의 만료된 토큰을 제공합니다.
- 외부 인증 공급자는 토큰이 Microsoft Entra ID에서 제공되었는지 유효성을 검사하고 토큰의 콘텐츠의 유효성을 검사합니다.
- 외부 인증 공급자는 선택적으로 Microsoft Graph를 호출하여 사용자에 대한 추가 정보를 가져올 수 있습니다.
- 외부 인증 공급자는 일부 자격 증명으로 사용자를 인증하는 등 필요하다고 판단되는 모든 작업을 수행합니다.
- 외부 인증 공급자는 모든 필수 클레임을 포함하여 유효한 토큰을 사용하여 사용자를 Microsoft Entra ID로 다시 리디렉션합니다.
- Microsoft Entra ID는 토큰의 서명이 구성된 외부 인증 공급자로부터 온 것인지 유효성을 검사한 다음 토큰의 콘텐츠의 유효성을 검사합니다.
- Microsoft Entra ID는 요구 사항에 따라 토큰의 유효성을 검사합니다.
- 유효성 검사에 성공하면 사용자가 MFA 요구 사항을 충족했습니다. 사용자는 다른 정책 요구 사항을 충족해야 할 수도 있습니다.
Microsoft Entra ID를 사용하여 새 외부 인증 공급자 구성
EAM이 id_token_hint를 발급하려면 통합을 나타내는 애플리케이션이 필요합니다. 애플리케이션은 두 가지 방법으로 만들 수 있습니다.
- 외부 공급자를 사용하는 각 테넌트에서 만들어집니다.
- 하나의 다중 테넌트 애플리케이션으로 만들어졌습니다. 권한 있는 역할 관리자는 테넌트에 대한 통합을 사용하도록 설정하려면 동의를 부여해야 합니다.
다중 테넌트 애플리케이션은 각 테넌트의 구성 오류 가능성을 줄여줍니다. 또한 각 테넌트가 변경하도록 요구하는 대신 공급자가 회신 URL과 같은 메타데이터를 한 곳에서 변경할 수 있습니다.
다중 테넌트 애플리케이션을 구성하려면 공급자 관리자가 먼저 다음을 수행해야 합니다.
아직 Microsoft Entra ID 테넌트가 없다면 새로 만듭니다.
테넌트에 애플리케이션을 등록합니다.
애플리케이션의 지원되는 계정 유형을 모든 조직 디렉터리의 계정(모든 Microsoft Entra ID 테넌트 - 다중 테넌트)으로 설정합니다.
Microsoft Graph의 위임된 권한
openid및profile을 애플리케이션에 추가합니다.이 애플리케이션에는 범위를 게시하지 마세요.
외부 ID 공급자의 유효한 권한 authorization_endpoint URL을 해당 애플리케이션에 회신 URL로 추가합니다.
참고 항목
공급자의 검색 문서에 제공된 authorization_endpoint를 애플리케이션 등록 시 리디렉션 URL로 추가해야 합니다. 그렇지 않으면 다음 오류가 발생합니다. ENTRA IDSTS50161: 외부 클레임 공급자의 권한 부여 URL의 유효성을 검사하지 못했습니다!
애플리케이션 등록 프로세스는 여러 속성을 가진 애플리케이션을 만듭니다. 이러한 속성은 시나리오에 필요합니다.
| 속성 | 설명 |
|---|---|
| 개체 ID | 공급자는 Microsoft Graph에서 개체 ID를 사용하여 애플리케이션 정보를 쿼리할 수 있습니다. 공급자는 개체 ID를 사용하여 애플리케이션 정보를 프로그래밍 방식으로 검색하고 편집할 수 있습니다. |
| 애플리케이션 ID | 공급자는 애플리케이션 ID를 애플리케이션의 ClientId로 사용할 수 있습니다. |
| 홈페이지 URL | 공급자 홈페이지 URL은 어떤 용도로도 사용되지 않지만 애플리케이션 등록의 일부로 필요합니다. |
| 회신 URL | 공급자에 대한 유효한 리디렉션 URL입니다. 공급자의 테넌트에 대해 설정된 공급자 호스트 URL과 일치해야 합니다. 등록된 회신 URL 중 하나는 Microsoft Entra ID가 호스트 URL에 대한 OIDC 검색을 통해 발견하는 authorization_endpoint의 접두사와 일치해야 합니다. |
각 테넌트에 대한 애플리케이션도 통합을 지원하는 유효한 모델입니다. 단일 테넌트 등록을 사용하는 경우 테넌트 관리자는 단일 테넌트 애플리케이션에 대한 이전 표의 속성을 사용하여 애플리케이션 등록을 만들어야 합니다.
참고 항목
EAM을 사용하는 테넌트에는 애플리케이션에 대한 관리자 동의가 필요합니다. 동의가 부여되지 않은 경우 관리자가 EAM을 사용하려고 하면 다음 오류가 나타납니다. AADSTS900491: 서비스 주체 <앱 ID>를 찾을 수 없습니다.
선택적 클레임 구성
공급자는 id_token에 대한 선택적 클레임을 사용하여 더 많은 클레임을 구성할 수 있습니다.
참고 항목
애플리케이션 만들기 방법에 관계없이 공급자는 각 클라우드 환경에 대한 선택적 클레임을 구성해야 합니다. 다중 테넌트 애플리케이션이 글로벌 Azure 및 US Gov용 Azure에 사용되는 경우 각 클라우드 환경에는 서로 다른 애플리케이션 및 애플리케이션 ID가 필요합니다.
Microsoft Entra ID에 EAM 추가
외부 ID 공급자 정보는 각 테넌트의 인증 방법 정책에 저장됩니다. 공급자 정보는 externalAuthenticationMethodConfiguration 형식의 인증 방법으로 저장됩니다.
각 공급자에는 정책의 목록 개체에 하나의 항목이 있습니다. 각 항목에는 다음 사항이 명시되어야 합니다.
- 메서드가 사용하도록 설정된 경우
- 해당 방법을 사용할 수 있는 포함된 그룹
- 해당 방법을 사용할 수 없는 제외그룹
조건부 액세스 관리자는 MFA 필요 부여가 포함된 정책을 만들어 사용자 로그인에 대한 MFA 요구 사항을 설정할 수 있습니다. 외부 인증 방법은 현재 인증 강도에서 지원되지 않습니다.
Microsoft Entra 관리 센터에서 외부 인증 방법을 추가하는 방법에 대한 자세한 내용은 Microsoft Entra ID(미리 보기)에서 외부 인증 방법 관리를 참조하세요.
Microsoft Entra ID와 공급자의 상호 작용
다음 섹션에서는 공급자 요구 사항을 설명하고 공급자와의 Microsoft Entra ID 상호 작용에 대한 예를 포함합니다.
공급자 메타데이터 검색
외부 ID 공급자는 OIDC 검색 엔드포인트를 제공해야 합니다. 이 엔드포인트는 더 많은 구성 데이터를 가져오는 데 사용됩니다. .well-known/oidc-configuration을 포함한 전체 URL은 EAM이 만들어질 때 구성된 검색 URL에 포함되어야 합니다.
엔드포인트는 호스트된 공급자 메타데이터 JSON 문서를 반환합니다. 엔드포인트는 유효한 콘텐츠 길이 헤더도 반환해야 합니다.
다음 표에는 공급자의 메타데이터에 있어야 하는 데이터가 나열되어 있습니다. 이 확장성 시나리오에는 이러한 값이 필요합니다. JSON 메타데이터 문서에 더 많은 정보가 포함될 수 있습니다.
공급자 메타데이터 값이 포함된 OIDC 문서는 공급자 메타데이터를 참조하세요.
| 메타데이터 값 | 값 | 설명 |
|---|---|---|
| Issuer | 이 URL은 검색에 사용되는 호스트 URL과 공급자 서비스에서 발급한 토큰의 iss 클레임과 모두 일치해야 합니다. | |
| authorization_endpoint | Microsoft Entra ID가 권한 부여를 위해 통신하는 엔드포인트입니다. 이 엔드포인트는 허용된 애플리케이션에 대한 회신 URL 중 하나로 존재해야 합니다. | |
| jwks_uri | Microsoft Entra ID는 공급자가 발급한 서명을 확인하는 데 필요한 공개 키를 찾을 수 있습니다. [!NOTE] 제공된 키의 X.509 표현을 제공하려면 JWK(JSON 웹 키) x5c 매개 변수가 있어야 합니다. |
|
| scopes_supported | openid | 다른 값도 포함될 수 있지만 필수는 아닙니다. |
| response_types_supported | id_token | 다른 값도 포함될 수 있지만 필수는 아닙니다. |
| subject_types_supported | ||
| id_token_signing_alg_values_supported | Microsoft는 RS256을 지원합니다. | |
| claim_types_supported | 노멀 | 이 속성은 선택 사항이지만 존재하는 경우 일반 값을 포함해야 합니다. 다른 값도 포함될 수 있습니다. |
http://customcaserver.azurewebsites.net/v2.0/.well-known/openid-configuration
{
"authorization_endpoint": "https://customcaserver.azurewebsites.net/api/Authorize",
"claims_supported": [
"email"
],
"grant_types_supported": [
"implicit"
],
"id_token_signing_alg_values_supported": [
"RS256"
],
"issuer": "https://customcaserver.azurewebsites.net",
"jwks_uri": "http://customcaserver.azurewebsites.net/.well-known/jwks",
"response_modes_supported": [
"form_post"
],
"response_types_supported": [
"id_token"
],
"scopes_supported": [
"openid"
],
"SigningKeys": [],
"subject_types_supported": [
"public"
]
}
http://customcaserver.azurewebsites.net/.well-known/jwks
{
"keys": [
{
"kty": "RSA",
"use": "sig",
"kid": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
"x5t": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
"n": "jq277LRoE6WKM0awT3b...vt8J6MZvmgboVB9S5CMQ",
"e": "AQAB",
"x5c": [
"cZa3jz...Wo0rzA="
]
}
]
}
참고 항목
제공된 키의 X.509 표현을 제공하려면 JWK x5c 매개 변수가 있어야 합니다.
공급자 메타데이터 캐싱
성능을 개선하기 위해 Microsoft Entra ID는 키를 포함하여 공급자가 반환한 메타데이터를 캐시합니다. 공급자 메타데이터 캐싱은 Microsoft Entra ID가 외부 ID 공급자와 통신할 때마다 검색 호출을 방지합니다.
이 캐시는 24시간(1일)마다 새로 고쳐집니다. 공급자에게 키 롤오버를 제안하는 방법은 다음과 같습니다.
- "jwks_uri"에 기존 인증서와 새 인증서를 게시합니다.
- Microsoft Entra ID 캐시가 새로 고쳐지거나 만료되거나 업데이트될 때까지(2일마다) 기존 인증서로 계속 서명합니다.
- 새 인증서를 사용한 서명으로 전환합니다.
키 롤오버 일정은 게시하지 않습니다. 종속 서비스는 즉시 및 주기적인 롤오버를 모두 처리할 수 있도록 준비되어야 합니다. azure-activedirectory-identitymodel-extensions-for-dotnet과 같이 이러한 목적으로 빌드된 전용 라이브러리를 사용하는 것이 좋습니다. 자세한 내용은 Microsoft Entra ID의 서명 키 롤오버를 참조하세요.
Microsoft Entra ID 메타데이터 검색
또한 공급자는 Microsoft Entra ID에서 발급한 토큰의 유효성을 검사하기 위해 Microsoft Entra ID의 공개 키를 검색해야 합니다.
Microsoft Entra ID 메타데이터 검색 엔드포인트:
- 글로벌 Azure:
https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration - 미국 정부용 Azure:
https://login.microsoftonline.us/common/v2.0/.well-known/openid-configuration - 21Vianet에서 운영하는 Microsoft Azure:
https://login.partner.microsoftonline.cn/common/v2.0/.well-known/openid-configuration
토큰의 공개 키 식별자(JWS(JSON 웹 서명)의 "kid")를 사용하면 jwks_uri 속성에서 검색된 키 중 어느 것이 Microsoft Entra ID 토큰 서명의 유효성을 검사하는 데 사용해야 하는지 결정할 수 있습니다.
Microsoft Entra ID에서 발급한 토큰 유효성 검사
Microsoft Entra ID에서 발급한 토큰의 유효성을 검사하는 방법에 대한 자세한 내용은 유효성 검사 및 ID 토큰을 참조하세요. 검색 메타데이터 소비자를 위한 특별한 단계는 없습니다.
Microsoft의 토큰 유효성 검사 라이브러리에는 문서화된 토큰 유효성 검사의 세부 사항에 대한 모든 세부 정보가 포함되어 있거나 소스 코드를 탐색하여 유효성 검사할 수 있습니다. 샘플은 Azure 샘플을 참조하세요.
유효성 검사가 성공하면 클레임 페이로드를 사용하여 사용자 및 해당 테넌트에 대한 세부 정보를 가져올 수 있습니다.
참고 항목
id_token_hint가 Microsoft 테넌트에서 왔으며 통합을 나타내도록 하려면 id_token_hint의 유효성을 검사해야 합니다. id_token_hint는 특히 서명, 발급자, 대상 그룹 및 기타 클레임 값을 완전히 유효성 검사해야 합니다.
외부 ID 공급자에 대한 Microsoft Entra ID 호출
Microsoft Entra ID는 OIDC 암시적 흐름을 사용하여 외부 ID 공급자와 통신합니다. 이 흐름을 사용하면 공급자와의 통신은 공급자의 권한 부여 엔드포인트를 통해서만 수행됩니다. Microsoft Entra ID가 요청하는 사용자를 공급자에게 알리기 위해 Microsoft Entra ID는 id_token_hint 매개 변수를 통해 토큰을 전달합니다.
공급자에게 전달되는 매개 변수 목록이 크기 때문에 이 호출은 POST 요청을 통해 이루어집니다. 목록이 크면 GET 요청의 길이를 제한하는 브라우저를 사용할 수 없습니다.
인증 요청 매개 변수는 다음 표에 나열되어 있습니다.
참고 항목
다음 표에 나열되지 않은 경우 공급자는 요청의 다른 매개 변수를 무시해야 합니다.
| 인증 쿼리 매개 변수 | 값 | 설명 |
|---|---|---|
| scope | openid | |
| response_type | Id_token | 암시적 흐름에 사용되는 값입니다. |
| response_mode | form_post | 대규모 URL 관련 문제를 방지하기 위해 양식 POST를 사용합니다. 모든 매개 변수가 요청 본문에 전송될 것으로 예상됩니다. |
| client_id | ABCD와 같은 외부 ID 공급자가 Microsoft Entra ID에 부여한 클라이언트 ID입니다. 자세한 내용은 외부 인증 방법 설명을 참조하세요. | |
| redirect_url | 외부 ID 공급자가 응답(id_token_hint)을 보내는 리디렉션 URI(Uniform Resource Identifier)입니다. | |
| 이 표 다음에 나오는 예를 참조하세요. | ||
| nonce | Microsoft Entra ID에서 생성된 임의의 문자열입니다. 세션 ID일 수 있습니다. 제공된 경우 Microsoft Entra ID에 대한 응답으로 반환되어야 합니다. | |
| state | 전달된 경우 공급자는 응답으로 상태를 반환해야 합니다. Microsoft Entra ID는 상태를 사용하여 통화에 대한 컨텍스트를 유지합니다. | |
| id_token_hint | 최종 사용자를 위해 Microsoft Entra ID에서 발급하고 공급자의 이익을 위해 전달된 토큰입니다. | |
| claims | 요청된 클레임이 포함된 JSON Blob입니다. 이 매개 변수의 형식에 대한 자세한 내용은 OIDC 설명서의 클레임 요청 매개 변수와 이 표 뒤에 나오는 예를 참조하세요. | |
| client-request-id | GUID 값 | 공급자는 문제 해결을 돕기 위해 이 값을 기록할 수 있습니다. |
리디렉션 URI의 예
리디렉션 URI(Uniform Resource Identifier)는 오프밴드 공급자에 등록되어야 합니다. 전송할 수 있는 리디렉션 URI는 다음과 같습니다.
- 글로벌 Azure:
https://login.microsoftonline.com/common/federation/externalauthprovider - 미국 정부용 Azure:
https://login.microsoftonline.us/common/federation/externalauthprovider - 21Vianet에서 운영하는 Microsoft Azure:
https://login.partner.microsoftonline.cn/common/federation/externalauthprovider
MFA를 만족하는 EAM의 예
다음은 EAM이 MFA를 충족하는 인증의 예입니다. 이 예는 공급자가 Microsoft Entra ID에서 예상하는 클레임이 무엇인지 파악하는 데 도움이 됩니다.
acr 및 amr 값의 조합은 Microsoft Entra ID에서 다음의 유효성을 검사하는 데 사용됩니다.
- 두 번째 단계에 사용된 인증 방법은 MFA 요구 사항을 충족합니다.
- 인증 방법은 Microsoft Entra 아이디 로그인을 위한 1단계 완료 방법과 '형식'이 다릅니다.
{
"id_token": {
"acr": {
"essential": true,
"values":["possessionorinherence"]
},
"amr": {
"essential": true,
"values": ["face", "fido", "fpt", "hwk", "iris", "otp", "pop", "retina", "sc", "sms", "swk", "tel", "vbm"]
}
}
}
기본 Id_token_hint 클레임
이 섹션에서는 공급자에 대한 요청에서 id_token_hint로 전달된 토큰의 필수 콘텐츠를 설명합니다. 토큰에는 다음 표보다 더 많은 클레임이 포함될 수 있습니다.
| 클레임 | 값 | 설명 |
|---|---|---|
| iss | 토큰을 생성하고 반환하는 STS(보안 토큰 서비스)와 사용자가 인증된 Microsoft Entra ID 테넌트를 식별합니다. 앱은 클레임의 GUID 부분을 사용하여 앱에 로그인할 수 있는 테넌트 집합을 제한할 수 있습니다(해당되는 경우). 발급자는 사용자가 로그인한 테넌트에 대한 OIDC 검색 JSON 메타데이터의 발급자 URL과 일치해야 합니다. | |
| aud | 대상 그룹은 Microsoft Entra ID에 대한 외부 ID 공급자의 클라이언트 ID로 설정되어야 합니다. | |
| exp | 만료 시간은 발급 시간 이후 짧은 시간 후에 만료되도록 설정되어 있어 시간 기울이기 문제를 방지하기에 충분합니다. 이 토큰은 인증용이 아니기 때문에 유효성이 요청보다 오래 지속될 이유가 없습니다. | |
| iat | 평소대로 발급 시간을 설정합니다. | |
| tid | 테넌트 ID는 공급자에게 테넌트를 보급하기 위한 것입니다. 사용자가 속한 Microsoft Entra ID 테넌트를 나타냅니다. | |
| oid | Microsoft ID 플랫폼의 엔터티에 대한 변경이 불가능한 식별자입니다. 이 경우에는 사용자 계정입니다. 데이터베이스 테이블의 키로써 안전하게 권한 부여 검사를 수행하는 데 사용할 수도 있습니다. 이 ID는 애플리케이션 전체에서 사용자를 고유하게 식별합니다. 동일한 사용자로 로그인하는 두 개의 서로 다른 애플리케이션은 oid 클레임에서 동일한 값을 받습니다. 따라서 oid는 Microsoft Graph와 같은 Microsoft Online Services에 대한 쿼리에 사용될 수 있습니다. | |
| preferred_username | 토큰의 주체를 식별하는, 사람이 인식할 수 있는 값을 제공합니다. 이 값은 테넌트 내에서 고유하다고 보장되지 않으며 표시 목적으로만 사용됩니다. | |
| sub | 발급자의 최종 사용자에 대한 주체 식별자입니다. 애플리케이션의 사용자와 같이 토큰에서 정보를 어설션하는 주체입니다. 이 값은 변경할 수 없으며 재할당 또는 재사용할 수 없습니다. 예를 들어, 리소스 액세스에 토큰을 사용할 때 이 값을 사용하면 안전하게 인증 검사를 수행하고 데이터베이스 테이블에서 키로 사용할 수 있습니다. Microsoft Entra ID가 발급하는 토큰에는 주체가 항상 존재하므로 범용 권한 부여 시스템에서 이 값을 사용하는 것이 좋습니다. 그러나 주체는 쌍으로 된 식별자이며 특정 애플리케이션 ID에 고유합니다. 따라서, 단일 사용자가 두 개의 다른 클라이언트 ID를 사용하여 두 개의 다른 애플리케이션에 로그인하는 경우 해당 애플리케이션은 주체 클레임에 두 개의 다른 값을 받게 됩니다. 이 결과는 아키텍처 및 개인 정보 보호 요구 사항에 따라 바람직할 수도 있고 그렇지 않을 수도 있습니다. oid 클레임도 참조하세요(테넌트 내의 앱 전체에서 동일하게 유지됨). |
힌트 이외의 용도로 사용되지 않도록 토큰은 만료된 상태로 발급됩니다. 토큰은 서명되었으며 게시된 Microsoft Entra ID 검색 메타데이터를 사용하여 확인할 수 있습니다.
Microsoft Entra ID의 선택적 클레임
공급자가 Microsoft Entra ID의 선택적 클레임을 필요로 하는 경우 id_token에 대해 이러한 선택적 클레임을 구성할 수 있습니다. 자세한 내용은 선택적 소유권 클레임을 참조하세요.
클레임의 권장 사용
Microsoft에서는 oid 및 tid 클레임을 사용하여 공급자 쪽 계정을 Azure AD의 계정과 연결하는 것이 좋습니다. 이 두 클레임은 테넌트의 계정에 대해 고유한 것으로 보장됩니다.
id_token_hint의 예
다음은 디렉터리 멤버에 대한 id_token_hint의 예입니다.
{
"typ": "JWT",
"alg": "RS256",
"kid": "C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w"
}.{
"ver": "2.0",
"iss": "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0",
"sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA",
"aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
"exp": 1536093790,
"iat": 1536093791,
"nbf": 1536093791,
"name": "Test User 2",
"preferred_username": "testuser2@contoso.com"
"oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
"tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
}.
다음은 테넌트의 게스트 사용자에 대한 id_token 힌트의 예입니다.
{
"typ": "JWT",
"alg": "RS256",
"kid": "C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w"
}.{
"ver": "2.0",
"iss": "https://login.microsoftonline.com/9122040d-6c67-4c5b-b112-36a304b66dad/v2.0",
"sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA",
"aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
"exp": 1536093790,
"iat": 1536093791,
"nbf": 1536093791,
"name": "External Test User (Hotmail)",
"preferred_username": "externaltestuser@hotmail.com",
"oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
"tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
}.
외부 ID 공급자를 위한 권장 작업
외부 ID 공급자가 이러한 단계를 완료하는 것이 좋습니다. 이 목록은 완전한 것이 아니며 서비스 공급자는 적합하다고 판단되는 다른 유효성 검사 단계를 완료해야 합니다.
- 요청에서:
- 외부 ID 공급자에 대한 Microsoft Entra ID 호출에 redirect_uri가 게시되었는지 확인합니다.
- client_id에 ABCD와 같은 Microsoft Entra ID에 할당된 값이 있는지 확인합니다.
- 공급자는 먼저 Microsoft Entra ID가 제공하는 id_token_hint를 유효성 검사해야 합니다.
- id_token_hint의 클레임에서:
- 선택적으로 Microsoft Graph를 호출하여 이 사용자에 대한 기타 세부 정보를 가져올 수 있습니다. 이와 관련하여 id_token_hint의 oid 및 tid 클레임이 유용합니다. id_token_hint에 제공된 클레임에 대한 자세한 내용은 기본 id_token_hint 클레임을 참조하세요.
- 그런 다음 공급자의 제품이 수행하도록 만들어진 다른 인증 작업을 수행합니다.
- 사용자 작업의 결과와 기타 요인에 따라 공급자는 다음 섹션에 설명된 대로 응답을 구성하여 Microsoft Entra ID로 다시 보냅니다.
공급자 응답의 Microsoft Entra ID 처리
공급자는 redirect_uri에 응답을 다시 게시해야 합니다. 성공적인 응답에는 다음 매개 변수가 제공되어야 합니다.
| 매개 변수 | 값 | 설명 |
|---|---|---|
| id_token | 외부 ID 공급자가 발급한 토큰입니다. | |
| state | 요청에 전달된 것과 동일한 상태입니다(있는 경우). 그렇지 않으면 이 값이 없어야 합니다. |
성공하면 공급자는 사용자에게 id_token을 발급합니다. Microsoft Entra ID는 게시된 OIDC 메타데이터를 사용하여 토큰에 예상되는 클레임이 포함되어 있는지 확인하고 OIDC에서 요구하는 기타 토큰 유효성 검사를 수행합니다.
| 클레임 | 값 | 설명 |
|---|---|---|
| iss | 발급자 – 공급자 검색 메타데이터의 발급자와 일치해야 합니다. | |
| aud | 대상 그룹 – Microsoft Entra ID 클라이언트 ID입니다. 외부 ID 공급자에 대한 Microsoft Entra ID 호출에서 client_id를 참조하세요. | |
| exp | 만료 시간 – 평소대로 설정합니다. | |
| iat | 발급 시간 – 평소와 같이 설정됩니다. | |
| sub | 제목 – 이 요청을 시작하기 위해 전송된 id_token_hint의 하위와 일치해야 합니다. | |
| nonce | 요청에 전달된 것과 동일한 nonce입니다. | |
| acr | 인증 클레임에 대한 acr 클레임입니다. 이 값은 이 요청을 시작하기 위해 보낸 요청의 값 중 하나와 일치해야 합니다. 하나의 acr 클레임만 반환되어야 합니다. 소유권 클레임 목록은 지원되는 acr 소유권 클레임을 참조하세요. | |
| amr | amr은 인증에 사용되는 인증 방법에 대한 클레임입니다. 이 값은 배열로 반환되어야 하며, 메서드 클레임은 하나만 반환되어야 합니다. 클레임 목록은 지원되는 amr 클레임을 참조하세요. |
지원되는 acr 클레임
| 클레임 | 주의 |
|---|---|
| possessionorinherence | 인증이 소유 또는 선천적 특성 기반 요소로 수행되어야 합니다. |
| knowledgeorpossession | 인증이 지식 또는 소유 기반 요소로 수행되어야 합니다. |
| knowledgeorinherence | 인증이 지식 또는 선천적 특성 기반 요소를 통해 수행되어야 합니다. |
| knowledgeorpossessionorinherence | 인증이 지식, 소유 또는 선천적 특성 기반 요소를 통해 수행되어야 합니다. |
| 지식 | 인증이 기술 자료 요소로 수행되어야 합니다. |
| possession | 인증이 소유 기반 요소로 수행되어야 합니다. |
| inherence | 인증이 선천적 특성 기반 요소를 사용하여 수행되어야 합니다. |
지원되는 amr 클레임
| 클레임 | 주의 |
|---|---|
| face | 얼굴 인식을 통한 생체 인식 |
| fido | FIDO2가 사용되었습니다. |
| fpt | 지문을 통한 생체 인식 |
| hwk | 하드웨어 보안 키 소유 증명 |
| iris | 홍채 검사를 통한 생체 인식 |
| otp | 일회용 암호 |
| pop | 소유 증명 |
| retina | 망막 검사의 생체 인식 |
| sc | 스마트 카드 |
| SMS | 등록된 번호에 대한 텍스트로 확인 |
| swk | 소프트웨어 보안 키 존재 확인 |
| tel | 전화로 확인 |
| vbm | 성문을 이용한 생체 인식 |
Microsoft Entra ID에서는 MFA 클레임이 포함된 토큰을 발급하려면 MFA를 충족해야 합니다. 결과적으로 다른 형식의 메서드만 두 번째 단계 요구 사항을 충족할 수 있습니다. 앞서 언급한 바와 같이 두 번째 단계를 만족시키기 위해 사용할 수 있는 다양한 방법 형식은 지식, 소유, 선천적 특성입니다.
Microsoft Entra ID는 다음 표를 기반으로 형식 매핑의 유효성을 검사합니다.
| Claim 메서드 | Type | 주의 |
|---|---|---|
| face | 선천적 특성 | 얼굴 인식을 통한 생체 인식 |
| fido | 소유 | FIDO2가 사용되었습니다. 일부 구현에서는 생체 인식이 필요할 수도 있지만 소유 방법 형식은 기본 보안 특성이기 때문에 매핑됩니다. |
| fpt | 선천적 특성 | 지문을 통한 생체 인식 |
| hwk | 소유 | 하드웨어 보안 키 소유 증명 |
| iris | 선천적 특성 | 홍채 검사를 통한 생체 인식 |
| otp | 소유 | 일회용 암호 |
| pop | 소유 | 소유 증명 |
| retina | 선천적 특성 | 망막 검사의 생체 인식 |
| sc | 소유 | 스마트 카드 |
| SMS | 소유 | 등록된 번호에 대한 텍스트로 확인 |
| swk | 소유 | 소프트웨어 보안 키의 존재 증명 |
| tel | 소유 | 전화로 확인 |
| vbm | 선천적 특성 | 성문을 이용한 생체 인식 |
토큰에 문제가 발견되지 않으면 Microsoft Entra ID는 MFA가 충족된 것으로 간주하고 최종 사용자에게 토큰을 발급합니다. 그렇지 않으면 최종 사용자의 요청이 실패합니다.
실패는 오류 응답 매개 변수를 발행하여 표시됩니다.
| 매개 변수 | 값 | 설명 |
|---|---|---|
| Error | access_denied 또는 temporary_unavailable과 같은 ASCII 오류 코드입니다. |
Microsoft Entra ID는 id_token 매개 변수가 응답에 있고 토큰이 유효한 경우 요청이 성공한 것으로 간주합니다. 그렇지 않으면 요청이 실패한 것으로 간주됩니다. Microsoft Entra ID는 조건부 액세스 정책 요구 사항으로 인해 원래 인증 시도에 실패합니다.
Microsoft Entra ID는 공급자로 리디렉션되고 약 10분 후에 인증 시도 상태를 포기합니다.
Microsoft Entra ID 오류 응답 처리
Microsoft Azure 서비스는 correlationId를 사용하여 다양한 내부 및 외부 시스템에서 호출의 상관 관계를 지정합니다. 이는 잠재적으로 여러 HTTP 호출을 포함하는 전체 작업이나 흐름의 공통 식별자 역할을 합니다. 작업 중에 오류가 발생하면 응답에 상관 관계 ID라는 필드가 포함됩니다.
Microsoft 지원 또는 유사한 서비스에 문의할 때 원격 분석 및 로그에 더 빠르게 액세스하는 데 도움이 되므로 이 상관 관계 ID 값을 제공합니다.
예시:
ENTRA IDSTS70002: 자격 증명의 유효성을 검사하는 동안 오류가 발생했습니다. ENTRA IDSTS50012: 발급자 'https://sts.XXXXXXXXX.com/auth/realms/XXXXXXXXXmfa'의 외부 ID 토큰이 서명 확인에 실패했습니다. 토큰의 KeyID는 'A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u'입니다. 추적 ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333 상관 관계 ID: aaaa0000-bb11-2222-33cc-444444dddddd 타임스탬프: 2023-07-24 16:51:34Z
사용자 지정 컨트롤 및 EAM
Microsoft Entra ID에서는 고객이 EAM을 준비하고 EAM으로 마이그레이션하는 동안 EAM 및 조건부 액세스 사용자 지정 컨트롤이 병렬로 작동할 수 있습니다.
현재 사용자 지정 컨트롤을 사용하여 외부 공급자와의 통합을 사용하는 고객은 해당 컨트롤과 액세스를 관리하기 위해 구성한 모든 조건부 액세스 정책을 계속 사용할 수 있습니다. 관리자는 마이그레이션 기간 동안 병렬 조건부 액세스 정책 집합을 만드는 것이 좋습니다.
정책은 사용자 지정 컨트롤 부여 대신 다단계 인증 필요 부여 제어를 사용해야 합니다.
참고 항목
기본 제공 MFA 강도를 포함하여 인증 강도를 기반으로 한 부여 제어는 EAM에서 충족되지 않습니다. 정책은 다단계 인증 필요로만 구성되어야 합니다. 강력한 인증 기능을 갖춘 EAM을 지원하기 위해 적극적으로 노력하고 있습니다.
새 정책은 먼저 일부 사용자를 대상으로 테스트할 수 있습니다. 테스트 그룹은 사용자 지정 컨트롤이 필요한 정책에서는 제외되고, MFA가 필요한 정책에는 포함됩니다. 관리자가 MFA를 요구하는 정책이 EAM에 의해 충족된다는 점을 확신하게 되면 관리자는 MFA 부여를 통해 정책에 필요한 모든 사용자를 포함할 수 있으며 사용자 지정 컨트롤을 위해 구성된 정책을 해제로 이동할 수 있습니다.
통합 지원
Microsoft Entra ID와 EAM 통합을 빌드할 때 문제가 발생하는 경우 Microsoft CxE(고객 환경 엔지니어링) ISV(독립 솔루션 공급업체)가 도움을 줄 수 있습니다. CxE ISV 팀과 협력하려면 지원 요청을 제출합니다.
참조
용어
| 용어 | 설명 |
|---|---|
| MFA | 다단계 인증. |
| EAM | 외부 인증 방법은 사용자 인증의 일부로 사용되는 Microsoft Entra ID가 아닌 공급자의 인증 방법입니다. |
| OIDC | Open ID Connect는 OAuth 2.0 기반의 인증 프로토콜입니다. |
| 00001111-aaaa-2222-bbbb-3333cccc4444 | 외부 인증 방법을 위해 통합된 앱 ID의 예입니다. |
다음 단계
Microsoft Entra 관리 센터에서 EAM을 구성하는 방법에 대한 자세한 내용은 Microsoft에서 외부 인증 방법 관리(미리 보기)를 참조하세요.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기