다음을 통해 공유

제로 트러스트 대한 토큰 관리

  • 아티클

제로 트러스트 애플리케이션 개발에서는 애플리케이션의 의도 및 리소스 액세스 요구 사항을 구체적으로 정의하는 것이 중요합니다. 앱은 의도한 대로 작동하는 데 필요한 액세스만 요청해야 합니다. 이 문서는 개발자로서 앱이 Microsoft ID 플랫폼 받을 수 있는 ID 토큰, 액세스 토큰 및 보안 토큰을 사용하여 애플리케이션에 보안을 구축하는 데 도움이 됩니다.

애플리케이션이 최소 권한의 제로 트러스트 원칙을 준수하고 의도를 손상시키는 방식으로 사용을 방지하는지 확인합니다. JIT/JEA(Just-In-Time and Just-Enough-Access), 위험 기반 적응 정책 및 데이터 보호를 사용하여 사용자 액세스를 제한합니다. 앱의 중요하고 강력한 섹션을 구분하여 이러한 영역에 대한 권한 있는 사용자 액세스만 제공합니다. 애플리케이션을 사용할 수 있는 사용자와 앱에 있는 기능을 제한합니다.

애플리케이션이 Microsoft ID 플랫폼 수신하는 ID 토큰을 관리하는 방법에 대한 최소 권한을 빌드합니다. ID 토큰의 정보를 통해 사용자가 자신이 주장하는 사람인지 확인할 수 있습니다. 사용자 또는 해당 조직은 MFA 제공, 관리되는 디바이스 사용 및 올바른 위치에 있는 것과 같은 인증 조건을 지정할 수 있습니다.

고객이 앱에 대한 권한 부여를 쉽게 관리할 수 있도록 합니다. 사용자 프로비저닝 오버헤드 및 수동 프로세스의 필요성을 줄입니다. 자동 사용자 프로비저닝을 사용하면 IT 관리자가 대상 ID 저장소에서 사용자 ID 생성, 기본 테넌트 및 제거를 자동화할 수 있습니다. 고객은 Microsoft Entra ID에서 앱 프로비저닝 또는 HR 기반 프로비저닝을 사용하여 사용자 및 그룹의 변경 내용을 기반으로 자동화할 수 있습니다.

앱에서 토큰 클레임 사용

애플리케이션 내의 UX에 대한 ID 토큰의 클레임을 데이터베이스의 키로 사용하고 클라이언트 애플리케이션에 대한 액세스를 제공합니다. ID 토큰은 OpenID 커넥트(OIDC)가 OAuth 2.0으로 만드는 핵심 확장입니다. 앱은 액세스 토큰과 함께 또는 액세스 토큰 대신 ID 토큰을 받을 수 있습니다.

보안 토큰 권한 부여에 대한 표준 패턴에서 발급된 ID 토큰을 사용하면 애플리케이션이 사용자에 대한 정보를 받을 수 있습니다. ID 토큰을 권한 부여 프로세스로 사용하여 리소스에 액세스하지 마세요. 권한 부여 서버는 다음을 포함하는 사용자 정보가 포함된 클레임이 포함된 ID 토큰을 발급합니다.

  • 대상 그룹(aud) 클레임은 앱의 클라이언트 ID입니다. API 클라이언트 ID에 대한 토큰만 허용합니다.
  • 클레임은 tid 토큰을 발급한 테넌트 ID입니다. 클레임은 oid 사용자를 고유하게 식별하는 변경할 수 없는 값입니다. tid 사용자와 데이터를 연결해야 하는 경우 고유한 조합과 oid 클레임을 키로 사용합니다. 이러한 클레임 값을 사용하여 Microsoft Entra ID의 사용자 ID에 데이터를 다시 연결할 수 있습니다.
  • 클레임은 sub 사용자를 고유하게 식별하는 변경할 수 없는 값입니다. 주체 클레임은 애플리케이션에 대해서도 고유합니다. 클레임을 sub 사용하여 사용자와 데이터를 연결하는 경우 데이터에서 이동하여 Microsoft Entra ID의 사용자와 연결하는 것은 불가능합니다.

앱은 openid 범위를 사용하여 Microsoft ID 플랫폼 ID 토큰을 요청할 수 있습니다. OIDC 표준은 ID 토큰의 openid 형식 및 내용과 함께 범위를 제어합니다. OIDC는 다음 범위를 지정합니다.

  • openid 범위를 사용하여 사용자를 로그인하고 ID 토큰에 클레임을 추가 sub 합니다. 이러한 범위는 앱과 사용자에게 고유한 사용자 ID를 제공하고 UserInfo 엔드포인트를 호출합니다.
  • 범위는 email 사용자의 이메일 주소를 포함하는 클레임을 ID 토큰에 추가합니다 email .
  • 범위는 profile 사용자의 기본 프로필 특성(이름, 사용자 이름)이 있는 클레임을 ID 토큰에 추가합니다.
  • 이 offline_access 범위를 사용하면 사용자가 없는 경우에도 앱에서 사용자 데이터에 액세스할 수 있습니다.

MSAL(Microsoft 인증 라이브러리)은 항상 모든 토큰 요청에 openid, 이메일 및 profile 범위를 추가합니다. 따라서 MSAL은 모든 호출 또는 AcquireTokenInteractive에 대한 ID 토큰 및 액세스 토큰을 AcquireTokenSilent 항상 반환합니다. MSAL은 항상 범위를 요청합니다 offline_access . Microsoft ID 플랫폼 요청 앱이 범위를 지정하지 않는 경우에도 항상 범위를 반환 offline_access 합니다offline_access.

Microsoft는 OAuth2 표준을 사용하여 액세스 토큰을 발급합니다. OAuth2 표준은 토큰을 수신한다고 말하지만 토큰 형식이나 토큰에 있어야 하는 항목은 지정하지 않습니다. 애플리케이션이 Microsoft Entra ID가 보호하는 리소스에 액세스해야 하는 경우 리소스가 정의한 범위를 사용해야 합니다.

예를 들어 Microsoft Graph는 User.Read 현재 사용자의 전체 사용자 프로필 및 테넌트 이름에 액세스하도록 애플리케이션에 권한을 부여하는 범위를 정의합니다. Microsoft Graph는 해당 API에서 사용할 수 있는 모든 기능 범위에서 사용 권한을 정의합니다.

권한 부여 시 Microsoft ID 플랫폼 애플리케이션에 대한 액세스 토큰을 반환합니다. 리소스를 호출할 때 앱은 이 토큰을 API에 대한 HTTP 요청의 권한 부여 헤더의 일부로 제공합니다.

토큰 수명 관리

애플리케이션은 인증이 Microsoft Entra ID로 성공적으로 완료된 후 사용자에 대한 세션을 만들 수 있습니다. 사용자 세션 관리는 사용자가 재인증이 필요한 빈도를 구동합니다. 앱 앞에 명시적으로 확인된 사용자를 적절한 권한과 적절한 시간 동안 유지하는 역할이 중요합니다. 세션 수명은 ID 토큰의 exp 클레임을 기반으로 해야 합니다. 클레임은 exp ID 토큰이 만료되는 시간과 더 이상 토큰을 사용하여 사용자를 인증할 수 없는 시간입니다.

액세스 토큰 또는 exp ID 토큰의 클레임에 대한 토큰 응답에 제공된 대로 항상 토큰 수명을 준수합니다. 토큰 수명을 제어하는 조건에는 엔터프라이즈에 대한 로그인 빈도가 포함될 수 있습니다. 애플리케이션에서 토큰 수명을 구성할 수 없습니다. 토큰 수명을 요청할 수 없습니다.

일반적으로 토큰은 유효하고 노출되지 않아야 합니다. 대상 클레임(aud)은 클라이언트 ID와 일치해야 합니다. 토큰이 신뢰할 수 있는 발급자에서 제공되는지 확인합니다. 다중 테넌트 API가 있는 경우 특정 테넌트만 API를 호출할 수 있도록 필터링하도록 선택할 수 있습니다. 토큰의 수명을 적용해야 합니다. (이전이 nbf 아님) 및 (만료) 클레임을 exp 확인하여 현재 시간이 해당 두 클레임의 값 내에 있는지 확인합니다.

매우 길거나 짧은 세션 수명을 목표로 하지 마세요. 부여된 ID 토큰 수명이 이 결정을 내리도록 합니다. 토큰 유효성을 초과하여 앱 세션을 활성 상태로 유지하면 IT 관리자가 권한 없는 액세스를 방지하기 위해 토큰 유효 기간을 설정하도록 유도한 규칙, 정책 및 우려가 위반됩니다. 짧은 세션은 사용자 환경을 저하시키고 보안 상태를 반드시 증가시킬 필요는 없습니다. ASP.NET 같은 인기 있는 프레임워크를 사용하면 Microsoft Entra ID의 ID 토큰 만료 시간에서 세션 및 쿠키 시간 제한을 설정할 수 있습니다. ID 공급자의 토큰 만료 시간을 따르면 사용자의 세션이 ID 공급자가 지정하는 정책보다 길지 않습니다.

토큰 캐시 및 새로 고침

토큰을 적절하게 캐시해야 합니다. MSAL은 토큰을 자동으로 캐시하지만 토큰의 수명은 있습니다. 수명 동안 토큰을 사용하고 적절하게 캐시합니다. 동일한 토큰을 반복적으로 요청하는 경우 제한으로 인해 애플리케이션의 응답성이 떨어집니다. 앱이 토큰 발급을 남용하는 경우 앱에 새 토큰을 발급하는 데 필요한 시간이 길어지게 됩니다.

MSAL 라이브러리는 토큰 새로 고침의 메커니즘을 포함하여 OAuth2 프로토콜의 세부 정보를 관리합니다. MSAL을 사용하지 않는 경우 선택한 라이브러리가 새로 고침 토큰을 효과적으로 사용하는지 확인합니다.

클라이언트가 보호된 리소스에 액세스하기 위해 액세스 토큰을 획득하면 새로 고침 토큰을 받습니다. 새로 고침 토큰을 사용하여 현재 액세스 토큰이 만료된 후 새 액세스/새로 고침 토큰 쌍을 가져옵니다. 새로 고침 토큰을 사용하여 다른 리소스에 대한 추가 액세스 토큰을 획득합니다. 새로 고침 토큰은 리소스 또는 테넌트가 아닌 사용자와 클라이언트의 조합에 바인딩됩니다. 새로 고침 토큰을 사용하여 앱에 권한이 있는 리소스 및 테넌트 조합에서 액세스 토큰을 획득할 수 있습니다.

토큰 오류 및 버그 관리

애플리케이션은 액세스 토큰의 내용에 대한 유효성 검사, 디코딩, 검사, 해석 또는 검사를 시도해서는 안 됩니다. 이러한 작업은 엄격하게 리소스 API의 책임입니다. 앱이 액세스 토큰의 내용을 검사하려고 하면 Microsoft ID 플랫폼 암호화된 토큰을 발급할 때 애플리케이션이 중단될 가능성이 큽니다.

네트워크, 인프라 또는 인증 서비스 오류 또는 중단과 같은 문제로 인해 토큰을 검색하는 호출이 실패할 수 있는 경우는 거의 없습니다. 다음 모범 사례에 따라 토큰 획득 실패가 발생하는 경우 애플리케이션에서 인증 환경 복원력을 높입니다.

  • 암호화를 사용하여 로컬로 캐시하고 토큰을 보호합니다.
  • 안전하지 않은 채널에서 토큰과 같은 보안 아티팩트가 전달되지 않습니다.
  • ID 공급자의 예외 및 서비스 응답을 이해하고 작동합니다.

개발자는 리소스 호출에서 401 오류를 수신하는 것과 같은 문제를 디버그하기 위해 토큰 내부를 살펴보는 방법에 대한 질문이 있는 경우가 많습니다. 암호화된 토큰이 많을수록 액세스 토큰 내부를 볼 수 없으므로 내부 액세스 토큰을 찾는 대안을 찾아야 합니다. 디버깅의 경우 액세스 토큰이 포함된 토큰 응답은 필요한 정보를 제공합니다.

코드에서 개별 오류 사례가 아닌 오류 클래스에 대한 검사. 예를 들어 시스템에서 권한을 부여하지 않는 경우 개별 오류 대신 필요한 사용자 상호 작용을 처리합니다. 이러한 개별 사례를 놓칠 수 있으므로 개별 오류 코드를 살펴보는 대신 사용자 상호 작용과 같은 분류자를 검사 것이 좋습니다.

호출에 필요한 클레임 챌린지로 AcquireTokenInteractive 대체하고 제공해야 할 AcquireTokenSilent 수도 있습니다. 이렇게 하면 대화형 요청을 효과적으로 관리할 수 있습니다.

다음 단계