Microsoft ID 플랫폼의 OAuth 2.0 및 OIDC(OpenID Connect)

  • 아티클

Microsoft ID 플랫폼을 사용하기 위해 프로토콜 수준에서 OAuth 또는 OIDC(OpenID Connect)를 알 필요는 없습니다. 그러나 ID 플랫폼을 사용하여 앱에 인증 기능을 추가하면 프로토콜 용어 및 개념을 접하게 됩니다. Microsoft Entra 관리 센터, 설명서 및 인증 라이브러리를 사용할 때 몇 가지 기본 사항을 알고 있으면 통합 및 전반적인 환경에 도움이 될 수 있습니다.

OAuth 2.0의 역할

일반적으로 OAuth 2.0 및 OpenID Connect 인증 및 권한 부여 교환에 네 가지 요소가 관여합니다. 이러한 교환을 종종 ‘인증 흐름’이라고 합니다.

Diagram showing the OAuth 2.0 roles

  • 권한 부여 서버 - Microsoft ID 플랫폼은 권한 부여 서버입니다. ID 공급자 또는 IdP라고도 하는 이 솔루션은 최종 사용자의 정보, 액세스 권한, 인증 흐름에서 당사자 간의 신뢰 관계를 안전하게 처리합니다. 권한 부여 서버는 사용자가 로그인(권한 부여)한 후 앱 및 API가 리소스에 대한 액세스 권한 부여, 거부 또는 취소(권한 부여)에 사용하는 보안 토큰을 발급합니다.

  • 클라이언트 - OAuth 교환의 클라이언트는 보호된 리소스에 대한 액세스를 요청하는 애플리케이션입니다. 클라이언트는 서버에서 실행되는 웹앱, 사용자의 웹 브라우저에서 실행되는 단일 페이지 웹앱 또는 다른 웹 API를 호출하는 웹 API일 수 있습니다. 클라이언트 애플리케이션, 애플리케이션 또는 앱이라고 하는 클라이언트를 자주 볼 수 있습니다.

  • 리소스 소유자 - 인증 흐름의 리소스 소유자는 일반적으로 애플리케이션 사용자 또는 OAuth 용어로 ‘최종 사용자’입니다. 최종 사용자는 보호된 리소스(해당 데이터)를 "소유"하여 앱이 사용자를 대신하여 액세스합니다. 리소스 소유자는 자신이 소유한 리소스에 대한 앱(클라이언트) 액세스 권한을 부여하거나 거부할 수 있습니다. 예를 들어 앱은 외부 시스템의 API를 호출하여 해당 시스템의 프로필에서 사용자의 이메일 주소를 가져올 수 있습니다. 프로필 데이터는 최종 사용자가 외부 시스템에서 소유하는 리소스이며 최종 사용자는 앱의 데이터 액세스 요청에 동의하거나 거부할 수 있습니다.

  • 리소스 서버 - 리소스 서버는 리소스 소유자의 데이터를 호스팅하거나 액세스를 제공합니다. 대부분의 경우 리소스 서버는 데이터 저장소 앞에 있는 웹 API입니다. 리소스 서버는 인증을 수행하기 위해 권한 부여 서버에 의존하고 권한 부여 서버에서 발행한 전달자 토큰의 정보를 사용하여 리소스에 대한 액세스를 허용하거나 거부합니다.

토큰

인증 흐름의 당사자는 전달자 토큰을 사용하여 보안 주체(사용자, 호스트 또는 서비스)를 보장, 확인 및 인증하고 보호된 리소스에 대한 액세스 권한을 부여하거나 거부합니다(권한 부여). Microsoft ID 플랫폼의 전달자 토큰은JWT(JSON 웹 토큰) 형식으로 지정됩니다.

세 가지 형식의 전달자 토큰이 ID 플랫폼에서 ‘보안 토큰’으로 사용됩니다.

  • 액세스 토큰 - 액세스 토큰은 권한 부여 서버에서 클라이언트 애플리케이션에 발급합니다. 클라이언트는 액세스 토큰을 리소스 서버에 전달합니다. 액세스 토큰에는 권한 부여 서버가 클라이언트에게 부여한 권한이 포함됩니다.

  • ID 토큰 - ID 토큰은 권한 부여 서버에서 클라이언트 애플리케이션에 발급합니다. 클라이언트는 사용자 로그인 시 ID 토큰을 사용하고 사용자에 대한 기본 정보를 얻습니다.

  • 새로 고침 토큰 - 클라이언트는 새로 고침 토큰 또는 RT를 사용하여 권한 부여 서버에서 새 액세스 및 ID 토큰을 요청합니다. 코드는 권한 부여 서버에서만 사용하기 위한 것이기 때문에 새로 고침 토큰과 해당 문자열 내용을 민감한 데이터로 처리해야 합니다.

앱 등록

클라이언트 앱에는 Microsoft ID 플랫폼에서 발급한 보안 토큰을 신뢰할 수 있는 방법이 필요합니다. 트러스트를 설정하는 첫 번째 단계는 앱을 등록하는 것입니다. 앱을 등록하면 ID 플랫폼에서 자동으로 일부 값을 할당하고 다른 값은 애플리케이션 형식을 기반으로 구성합니다.

가장 일반적으로 참조되는 두 가지 앱 등록 설정은 다음과 같습니다.

  • 애플리케이션(클라이언트) ID - ‘애플리케이션 ID’ 및 ‘클라이언트 ID’고도 하는 이 값은 ID 플랫폼에서 앱에 할당합니다. 클라이언트 ID는 ID 플랫폼에서 앱을 고유하게 식별하며 플랫폼 문제의 보안 토큰에 포함됩니다.
  • 리디렉션 URI - 권한 부여 서버는 상호 작용을 완료한 후 리디렉션 URI를 사용하여 리소스 소유자의 사용자 에이전트(웹 브라우저, 모바일 앱)를 다른 대상으로 보냅니다. 예를 들어 최종 사용자가 권한 부여 서버를 사용하여 인증한 후입니다. 모든 클라이언트 형식이 리디렉션 URI를 사용하는 것은 아닙니다.

앱 등록에는 코드에서 ID 및 액세스 토큰을 가져오는 데 사용할 인증 및 권한 부여 엔드포인트에 대한 정보도 포함됩니다.

끝점

Microsoft ID 플랫폼은 OAuth 2.0 및 OIDC(OpenID Connect) 1.0의 표준 준수 구현을 사용하여 인증 및 권한 부여 서비스를 제공합니다. ID 플랫폼과 같은 표준 준수 권한 부여 서버는 권한 부여 흐름의 당사자가 흐름을 실행하는 데 사용할 HTTP 엔드포인트 집합을 제공합니다.

앱에 대한 엔드포인트 URI는 앱을 등록하거나 구성할 때 자동으로 생성됩니다. 앱의 코드에서 사용하는 엔드포인트는 애플리케이션의 형식과 지원해야 하는 ID(계정 형식)에 따라 다릅니다.

일반적으로 사용되는 두 가지 엔드포인트는 권한 부여 엔드포인트와 토큰 엔드포인트입니다. 다음은 authorize 및 token 엔드포인트의 예입니다.

# Authorization endpoint - used by client to obtain authorization from the resource owner.
https://login.microsoftonline.com/<issuer>/oauth2/v2.0/authorize
# Token endpoint - used by client to exchange an authorization grant or refresh token for an access token.
https://login.microsoftonline.com/<issuer>/oauth2/v2.0/token

# NOTE: These are examples. Endpoint URI format may vary based on application type,
#       sign-in audience, and Azure cloud instance (global or national cloud).

#       The {issuer} value in the path of the request can be used to control who can sign into the application. 
#       The allowed values are **common** for both Microsoft accounts and work or school accounts, 
#       **organizations** for work or school accounts only, **consumers** for Microsoft accounts only, 
#       and **tenant identifiers** such as the tenant ID or domain name.

등록한 애플리케이션의 엔드포인트를 찾으려면 Microsoft Entra 관리 센터에서 다음으로 이동합니다.

ID>애플리케이션>앱 등록><내 애플리케이션>>엔드포인트

다음 단계

다음으로 각 애플리케이션 형식에서 사용하는 OAuth 2.0 인증 흐름과 이를 수행하기 위해 앱에서 사용할 수 있는 라이브러리에 대해 알아봅니다.

인증 흐름을 실행할 때는 고유한 라이브러리 또는 원시 HTTP 호출을 작성하지 않을 것을 강력히 권장합니다. Microsoft 인증 라이브러리가 더 안전하고 쉽습니다. 그러나 라이브러리를 사용할 수 없는 시나리오이거나 Microsoft ID 플랫폼의 구현에 대해 자세히 알아보려는 경우 프로토콜 참조가 있습니다.