Azure AD(Active Directory)의 OAuth2 암시적 허용 흐름 이해

OAuth2 암시적 허용은 OAuth2 사양에서 가장 긴 보안 문제 목록을 가진 권한 부여로 악명이 높습니다. 그럼에도 불구하고 ADAL JS에서 구현하는 접근 방식과 SPA 애플리케이션을 작성할 때 권장하는 방법입니다. 무엇을 제공하나요? 이는 모두 절충의 문제입니다. 그리고 알고 보니 암시적 허용은 브라우저에서 JavaScript를 통해 Web API를 사용하는 애플리케이션에 대해 추구할 수 있는 가장 좋은 방법입니다.

OAuth2 암시적 허용이란?

전형적인 OAuth2 권한 부여 코드 부여 는 두 개의 별도 엔드포인트를 사용하는 권한 부여입니다. 권한 부여 엔드포인트는 사용자 상호 작용 단계에 사용되므로 권한 부여 코드가 생성됩니다. 그런 다음, 토큰 엔드포인트는 클라이언트에서 액세스 토큰에 대한 코드를 교환하는 데 사용되며 종종 새로 고침 토큰도 사용합니다. 웹 애플리케이션은 권한 부여 서버가 클라이언트를 인증할 수 있도록 자체 애플리케이션 자격 증명을 토큰 엔드포인트에 제공해야 합니다.

OAuth2 암시적 권한 부여는 다른 권한 부여의 변형입니다. 이를 통해 클라이언트는 토큰 엔드포인트에 연결하거나 클라이언트를 인증하지 않고 권한 부여 엔드포인트에서 직접 액세스 토큰(및 OpenId Connect를 사용하는 경우 id_token)을 가져올 수 있습니다. 이 변형은 웹 브라우저에서 실행되는 JavaScript 기반 애플리케이션용으로 설계되었습니다. 원래 OAuth2 사양에서는 토큰이 URI 조각에 반환됩니다. 이렇게 하면 클라이언트의 JavaScript 코드에서 토큰 비트를 사용할 수 있지만 서버로의 리디렉션에 포함되지 않습니다. OAuth2 암시적 권한 부여에서 권한 부여 엔드포인트는 이전에 제공된 리디렉션 URI를 사용하여 클라이언트에 직접 액세스 토큰을 발급합니다. 또한 JavaScript 애플리케이션이 토큰 엔드포인트에 연결해야 하는 경우 필요한 원본 간 호출에 대한 요구 사항을 제거하는 이점이 있습니다.

OAuth2 암시적 권한 부여의 중요한 특징은 이러한 흐름이 새로 고침 토큰을 클라이언트에 반환하지 않는다는 사실입니다. 다음 섹션에서는 이것이 필요하지 않고 실제로 보안 문제가 되는 방법을 보여줍니다.

OAuth2 암시적 허용에 적합한 시나리오

OAuth2 사양은 사용자 에이전트 애플리케이션을 사용하도록 암시적 허용이 고안되었음을 선언합니다. 즉, 브라우저 내에서 실행되는 JavaScript 애플리케이션입니다. 이러한 애플리케이션의 특징은 JavaScript 코드가 서버 리소스(일반적으로 Web API)에 액세스하고 그에 따라 애플리케이션 사용자 환경을 업데이트하는 데 사용된다는 것입니다. Gmail 또는 Outlook Web Access와 같은 애플리케이션을 생각해 보세요. 받은 편지함에서 메시지를 선택하면 메시지 시각화 패널만 변경되어 새 선택 영역이 표시되고 나머지 페이지는 수정되지 않은 상태로 유지됩니다. 이 특성은 기존의 리디렉션 기반 웹앱과는 대조적으로, 모든 사용자 상호 작용으로 인해 전체 페이지 포스트백 및 새 서버 응답의 전체 페이지 렌더링이 발생합니다.

JavaScript 기반 접근 방식을 극단적으로 사용하는 애플리케이션을 단일 페이지 애플리케이션 또는 SPA라고 합니다. 이러한 애플리케이션은 초기 HTML 페이지와 연결된 JavaScript만 제공하며, 모든 후속 상호 작용은 JavaScript를 통해 수행되는 Web API 호출에 의해 구동됩니다. 그러나 애플리케이션이 대부분 포스트백 기반이지만 가끔 JS 호출을 수행하는 하이브리드 접근 방식은 드문 일이 아닙니다. 암시적 흐름 사용에 대한 논의도 관련이 있습니다.

리디렉션 기반 애플리케이션은 일반적으로 쿠키를 통해 요청을 보호합니다. 그러나 이러한 접근 방식은 JavaScript 애플리케이션에서도 잘 작동하지 않습니다. 쿠키는 생성된 도메인에 대해서만 작동하지만 JavaScript 호출은 다른 도메인으로 전달될 수 있습니다. 실제로 Microsoft Graph API, Office API, Azure API를 호출하는 애플리케이션을 생각해 보세요. 모두 애플리케이션이 제공되는 도메인 외부에 상주합니다. JavaScript 애플리케이션의 추세는 백 엔드가 전혀 없는 것으로, 타사 Web API에 100% 사용하여 비즈니스 기능을 구현하는 것입니다.

현재 Web API에 대한 호출을 보호하는 기본 방법은 모든 호출에 OAuth2 액세스 토큰이 수반되는 OAuth2 전달자 토큰 접근 방식을 사용하는 것입니다. Web API는 들어오는 액세스 토큰을 검사하고 필요한 범위를 찾으면 요청된 작업에 대한 액세스 권한을 부여합니다. 암시적 흐름은 JavaScript 애플리케이션이 Web API에 대한 액세스 토큰을 가져올 수 있는 편리한 메커니즘을 제공하여 쿠키와 관련하여 다양한 이점을 제공합니다.

• 토큰은 원본 간 호출 없이 안정적으로 가져올 수 있습니다. 토큰이 반환되는 리디렉션 URI의 필수 등록은 토큰이 변위되지 않도록 보장합니다.
• JavaScript 애플리케이션은 도메인에 대한 제한 없이 대상 웹 API에 대해 필요한 만큼의 액세스 토큰을 가져올 수 있습니다.
• 세션 또는 로컬 스토리지와 같은 HTML5 기능은 토큰 캐싱 및 수명 관리에 대한 모든 권한을 부여하지만 쿠키 관리는 앱에 불투명합니다.
• 액세스 토큰은 CSRF(교차 사이트 요청 위조) 공격에 취약하지 않습니다.

암시적 권한 부여 흐름은 주로 보안상의 이유로 새로 고침 토큰을 발급하지 않습니다. 새로 고침 토큰은 액세스 토큰만큼 범위가 좁지 않으므로 유출될 경우 훨씬 더 많은 피해를 입힐 수 있습니다. 암시적 흐름에서 토큰은 URL에 전달되므로 가로채기의 위험이 권한 부여 코드 부여보다 높습니다.

그러나 JavaScript 애플리케이션에는 사용자에게 자격 증명을 반복적으로 요청하지 않고 액세스 토큰을 갱신하기 위한 다른 메커니즘이 있습니다. 애플리케이션은 숨겨진 iframe을 사용하여 Azure AD의 권한 부여 엔드포인트에 대해 새 토큰 요청을 수행할 수 있습니다. 브라우저에 여전히 Azure AD 도메인에 대한 활성 세션(읽기: 세션 쿠키 포함)이 있는 한 사용자 상호 작용 없이 인증 요청이 성공적으로 수행될 수 있습니다.

이 모델은 JavaScript 애플리케이션에 액세스 토큰을 독립적으로 갱신하고 새 API에 대한 새 토큰을 획득할 수 있는 기능을 부여합니다(사용자가 이전에 동의한 경우). 이렇게 하면 새로 고침 토큰과 같은 높은 가치의 아티팩트를 획득, 유지 관리 및 보호하는 추가적인 부담을 방지할 수 있습니다. 자동 갱신을 가능하게 하는 아티팩트인 Azure AD 세션 쿠키는 애플리케이션 외부에서 관리됩니다. 이 방법의 또 다른 장점은 사용자가 브라우저 탭에서 실행되는 Azure AD에 로그인한 애플리케이션을 사용하여 Azure AD에서 로그아웃할 수 있다는 것입니다. 이로 인해 Azure AD 세션 쿠키가 삭제되고 JavaScript 애플리케이션에서 로그아웃된 사용자에 대한 토큰을 갱신하는 기능이 자동으로 손실됩니다.

암시적 허용이 내 앱에 적합합니까?

암시적 권한 부여는 다른 권한 부여보다 더 많은 위험을 표시하며 주의해야 하는 영역이 잘 문서화되어 있습니다(예: 암시적 흐름 및 OAuth 2.0 위협 모델 및 보안 고려 사항에서 리소스 소유자를 가장하기 위한 액세스 토큰 오용). 그러나 위험 수준이 높은 프로필은 주로 원격 리소스에서 브라우저로 제공하는 활성 코드를 실행하는 애플리케이션을 사용하도록 설정하기 위한 것입니다. SPA 아키텍처를 계획하거나 백 엔드 구성 요소가 없거나 JavaScript를 통해 Web API를 호출하려는 경우 토큰 획득을 위해 암시적 흐름을 사용하는 것이 좋습니다.

애플리케이션이 네이티브 클라이언트인 경우 암시적 흐름이 적합하지 않습니다. 네이티브 클라이언트의 컨텍스트에서 Azure AD 세션 쿠키가 없으면 수명이 긴 세션을 유지 관리하는 수단에서 애플리케이션이 박탈됩니다. 즉, 새 리소스에 대한 액세스 토큰을 가져올 때 애플리케이션에서 사용자에게 반복적으로 메시지를 표시합니다.

백 엔드를 포함하는 웹 애플리케이션을 개발하고 백 엔드 코드에서 API를 사용하는 경우 암시적 흐름도 적합하지 않습니다. 다른 보조금은 당신에게 훨씬 더 많은 힘을 제공합니다. 예를 들어 OAuth2 클라이언트 자격 증명 부여는 사용자 위임이 아니라 애플리케이션 자체에 할당된 권한을 반영하는 토큰을 가져오는 기능을 제공합니다. 즉, 클라이언트는 사용자가 세션에 적극적으로 참여하지 않는 경우에도 리소스에 대한 프로그래밍 방식 액세스를 유지할 수 있습니다. 뿐만 아니라, 하지만 이러한 보조금은 더 높은 보안 보장을 제공합니다. 예를 들어 액세스 토큰은 사용자 브라우저를 통해 전송되지 않으며 브라우저 기록에 저장될 위험이 없습니다. 또한 클라이언트 애플리케이션은 토큰을 요청할 때 강력한 인증을 수행할 수 있습니다.

다음 단계

• 애플리케이션 통합 프로세스에 대한 자세한 내용은 Azure AD와 애플리케이션을 통합하는 방법을 참조하세요.