다음을 통해 공유

클레임의 유효성을 검사하여 애플리케이션 및 API 보호

  • 아티클

토큰과 상호 작용하는 것은 사용자에게 권한을 부여하기 위한 애플리케이션을 빌드하는 핵심 요소입니다. 최소 권한 있는 액세스에 대한 제로 트러스트 원칙에 따라 애플리케이션은 권한 부여를 수행할 때 액세스 토큰에 있는 특정 클레임 값의 유효성을 검사해야 합니다.

클레임 기반 권한 부여를 통해 애플리케이션이 토큰에 있는 테넌트, 주체 및 행위자와 같은 항목에 대한 올바른 값이 토큰에 포함되도록 할 수 있습니다. 즉, 다양한 활용 방법과 추적할 시나리오를 고려할 때 클레임 기반 권한 부여가 복잡해 보일 수 있습니다. 이 문서에서는 애플리케이션이 가장 안전한 사례를 준수하도록 클레임 기반 권한 부여 프로세스를 간소화하여 보여 줍니다.

권한 부여 논리가 안전한지 확인하려면 클레임에서 다음 정보의 유효성을 검사해야 합니다.

  • 토큰에 대해 적절한 대상 그룹이 지정됩니다.
  • 토큰의 테넌트 ID는 데이터가 저장된 테넌트 ID와 일치합니다.
  • 토큰의 주체가 적절합니다.
  • 행위자(클라이언트 앱)에 권한이 부여됩니다.

참고 항목

액세스 토큰은 클라이언트에서 획득한 웹 API에서만 유효성을 검사합니다. 클라이언트는 액세스 토큰의 유효성을 검사해서는 안 됩니다.

이 문서에 언급된 클레임에 대한 자세한 내용은 Microsoft ID 플랫폼 액세스 토큰을 참조하세요.

대상 그룹의 유효성 검사

aud 클레임은 토큰의 의도된 대상 그룹을 식별합니다. 클레임의 유효성을 검사하기 전에 액세스 토큰에 포함된 aud 클레임 값이 Web API와 일치하는지 항상 확인해야 합니다. 값은 클라이언트가 토큰을 요청한 방법에 따라 달라질 수 있습니다. 액세스 토큰의 대상 그룹은 엔드포인트에 따라 달라집니다.

  • v2.0 토큰의 경우 대상 그룹은 웹 API의 클라이언트 ID입니다. 이는 GUID입니다.
  • v1.0 토큰의 경우 대상 그룹은 토큰의 유효성을 검사하는 웹 API에 선언된 appID URI 중 하나입니다. 예를 들어 api://{ApplicationID} 또는 도메인 이름으로 시작하는 고유 이름(도메인 이름이 테넌트와 연결된 경우)입니다.

애플리케이션의 appID URI에 대한 자세한 내용은 애플리케이션 ID URI를 참조하세요.

테넌트 유효성 검사

항상 토큰의 tid가 애플리케이션에서 데이터를 저장하는 데 사용되는 테넌트 ID와 일치하는지 항상 검사합니다. 테넌트 컨텍스트에서 애플리케이션에 대한 정보가 저장되면 나중에 동일한 테넌트에서만 다시 액세스해야 합니다. 다른 테넌트에서 한 테넌트의 데이터에 액세스하도록 허용하지 마세요.

테넌트 유효성 검사는 첫 번째 단계일 뿐이며, 이 문서에 설명된 주체 및 작업자에 대한 확인은 여전히 ​​필요합니다. 테넌트의 모든 사용자에게 권한을 부여하려는 경우 해당 사용자를 그룹에 명시적으로 추가하고 그룹을 기반으로 권한을 부여하는 것이 좋습니다. 예를 들어, 테넌트 ID와 oid 클레임 존재 여부만 확인하면 API가 실수로 사용자 외에 해당 테넌트의 모든 서비스 주체에 권한을 부여할 수 있습니다.

주체 유효성 검사

사용자(또는 앱 전용 토큰의 애플리케이션 자체)와 같은 토큰 주체에 권한이 부여되었는지 확인합니다.

특정 sub 또는 oid 클레임에 대해 검사 수 있습니다.

또는,

제목이 , scp, groupswids 클레임을 사용하여 적절한 역할 또는 그룹에 roles속하는지 확인할 수 있습니다. 예를 들어 변경할 수 없는 클레임 값 tid 및 oid를 애플리케이션 데이터의 결합된 키로 사용하고 사용자에게 액세스 권한을 부여해야 하는지 여부를 결정합니다.

또는 groups wids 클레임을 roles사용하여 주체가 작업을 수행할 수 있는 권한이 있는지 여부를 확인할 수 있지만 주체에게 사용 권한을 부여할 수 있는 모든 방법의 전체 목록은 아닙니다. 예를 들어 관리자는 API에 쓸 수 있는 권한이 있지만 일반 사용자는 그렇지 않으며, 사용자는 일부 작업을 수행하기 위해 그룹에 포함될 수 있습니다. wid 클레임은 Microsoft Entra 기본 제공 역할에 있는 역할에서 사용자에게 할당된 테넌트 전체 역할을 나타냅니다. 자세한 내용은 Microsoft Entra 기본 제공 역할을 참조하세요.

Warning

저장할 email, preferred_username 또는 unique_name 등의 클레임을 사용하거나, 액세스 토큰의 사용자가 데이터에 액세스할 수 있어야 하는지 여부를 결정하지 마세요. 이러한 클레임은 고유하지 않으며 테넌트 관리자 또는 경우에 따라 사용자가 제어할 수 있으므로 권한 부여 결정에 적합하지 않습니다. 표시할 목적으로만 사용할 수 있습니다. 또한 권한 부여에 upn 클레임을 사용하지 마세요. UPN은 고유하지만 사용자 주체의 수명 동안 변경되는 경우가 많으므로 권한 부여를 신뢰할 수 없습니다.

행위자의 유효성을 검사합니다.

사용자를 대신하여 작동하는 클라이언트 애플리케이션(행위자라고도 함)에도 권한을 부여해야 합니다. scp 클레임(범위)을 사용하여 애플리케이션에 작업을 수행할 수 있는 권한이 있는지 확인합니다. scp의 권한은 사용자가 실제로 필요로 하는 것으로 제한되어야 하며 최소 권한 원칙을 따라야 합니다.

그러나 토큰에 scp가 없는 경우가 있습니다. 다음 시나리오에서는 scp 클레임이 없는지 확인해야 합니다.

  • 디먼 앱 / 앱 전용 권한
  • ID 토큰

범위 및 권한에 대한 자세한 내용은 Microsoft ID 플랫폼의 범위 및 권한을 참조하세요.

참고 항목

애플리케이션은 앱 전용 토큰(디먼 앱과 같은 사용자 없는 애플리케이션의 요청)을 처리하고 개별 서비스 주체 ID가 아닌 여러 테넌트에서 특정 애플리케이션에 권한을 부여하려고 할 수 있습니다. 이 경우 appid 클레임(v1.0 토큰의 경우) 또는 azp 클레임(v2.0 토큰의 경우)을 주체 권한 부여에 사용할 수 있습니다. 그러나 이러한 클레임을 사용하는 경우 애플리케이션은 선택적 클레임 idtyp의 유효성을 검사하여 애플리케이션에 대해 토큰이 직접 발급되도록 해야 합니다. 위임된 사용자 토큰은 애플리케이션 이외의 엔터티에서 가져올 수 있을 가능성이 있으므로 형식 app의 토큰만 이러한 방식으로 권한을 부여할 수 있습니다.

다음 단계

  • 보안 토큰의 토큰 및 클레임에 대해 자세히 알아보기