6.1.2.1. 세션 및 OAuth 엔드포인트

BFF는 브라우저 기반 애플리케이션과 BFF 사이의 상호작용을 구현하는 데 중요한 엔드포인트 집합을 제공합니다. 이 절에서는 엔드포인트의 목적과 사용 사례를 명확히 설명하기 위해 이를 자세히 다룹니다.¶

"check session" 엔드포인트(그림 1의 (B)와 (I))는 브라우저 기반 애플리케이션이 호출하는 API 엔드포인트입니다. 사용 가능한 경우 요청에는 세션 정보가 포함되므로 BFF가 활성 세션을 확인할 수 있습니다. 응답은 브라우저 기반 애플리케이션에 세션이 활성 상태인지 알려야 합니다. 또한 BFF는 인증된 사용자의 신원 정보와 같은 다른 정보도 포함할 수 있습니다.¶

인가 코드 흐름을 시작하는 엔드포인트 (C)는 브라우저가 탐색을 통해 접속합니다. 애플리케이션이 세션을 확인한 후 인증되지 않은 상태를 감지하면(B) 브라우저를 이 엔드포인트로 이동시킬 수 있습니다. 그러면 BFF가 브라우저를 인가 서버로 이동시키는 리디렉션으로 응답할 수 있습니다. 이 흐름을 시작하는 엔드포인트는 일반적으로 웹 서버에서 실행되는 기밀 클라이언트용 OAuth 2.0을 지원하는 라이브러리에 "login" 엔드포인트로 포함됩니다. BFF가 활성 세션이 없음을 감지했을 때 (B)에서 인가 코드 흐름을 시작할 수도 있다는 점에 유의하십시오. 이 경우 BFF는 응답에 인가 URI를 반환하고 애플리케이션이 이 URI로 탐색 이벤트를 트리거할 것으로 예상합니다. 그러나 이 시나리오에는 사용자 정의 구현이 필요하며 표준 OAuth 라이브러리를 사용하기가 더 어려워집니다.¶

인가 코드를 받는 엔드포인트(E)는 브라우저 내부의 탐색 이벤트를 통해 호출됩니다. 이 시점에는 애플리케이션이 로드되지 않았으므로 리디렉션을 처리할 수 없습니다. 흐름의 시작과 마찬가지로 리디렉션을 처리하는 엔드포인트도 표준 OAuth 라이브러리에서 제공합니다. BFF는 브라우저가 애플리케이션을 로드하도록 하는 리디렉션으로 이 요청에 응답할 수 있습니다.¶

마지막으로 BFF는 그림 1에 표시되지 않은 "logout" 엔드포인트도 애플리케이션에 제공할 수 있습니다. 로그아웃 엔드포인트의 정확한 동작은 애플리케이션 요구 사항에 따라 달라집니다. 표준 OAuth 라이브러리에서도 일반적으로 "logout" 엔드포인트의 구현을 제공한다는 점에 유의하십시오.¶

6.1.2.2. 갱신 토큰

제4.14절, [RFC9700]에서 설명한 대로 갱신 토큰을 사용할 때 BFF는 갱신 토큰을 얻고(F) 이를 사용자 세션과 연결합니다.¶

BFF가 사용자의 액세스 토큰이 만료되었음을 확인하고 갱신 토큰을 보유하고 있다면, 갱신 토큰을 사용하여 새 액세스 토큰을 얻을 수 있습니다. BFF OAuth 클라이언트는 기밀 클라이언트이므로 갱신 토큰 요청에 클라이언트 인증을 사용합니다. 일반적으로 BFF는 프런트엔드의 API 호출을 처리할 때 이러한 단계를 인라인으로 수행합니다. 이 경우 그림 1에 명시적으로 표시되지 않은 이러한 단계는 (J)와 (K) 사이에서 이루어집니다. 모든 토큰 정보를 서버 측에서 사용할 수 있도록 유지하는 BFF는 API 요청의 성능을 높이기 위해 토큰 만료 이벤트를 감지했을 때 새 액세스 토큰을 요청할 수도 있습니다.¶

갱신 토큰이 만료되면 완전히 새로운 인가 코드 흐름을 실행하지 않고서는 유효한 액세스 토큰을 얻을 방법이 없습니다. 따라서 BFF가 관리하는 쿠키 기반 세션의 수명을 갱신 토큰의 최대 수명과 동일하게 구성하는 것이 합리적입니다. 또한 BFF가 활성 세션의 갱신 토큰이 더 이상 유효하지 않다는 사실을 알게 되면 세션도 무효화하는 것이 합리적입니다.¶

6.1.2.3. 쿠키 기반 세션 상태

BFF는 사용자의 토큰에 액세스하는 데 사용되는 사용자 세션을 추적하기 위해 브라우저 쿠키 [RFC6265bis]에 의존합니다. 서버 측과 클라이언트 측 쿠키 기반 세션에는 모두 몇 가지 단점이 있습니다.¶

서버 측 세션은 세션 식별자만 노출하고 모든 데이터를 서버에 보관합니다. 이렇게 하면 모든 세션을 원하는 대로 폐기할 수 있는 기능과 함께 활성 세션을 높은 수준으로 제어할 수 있습니다. 이 접근 방식의 단점은 확장성에 미치는 영향이며, "고정 세션"이나 "세션 복제"와 같은 해결책이 필요합니다. 이러한 단점을 고려하면 BFF와 함께 서버 측 세션을 사용하는 것은 소규모 시나리오에서만 권고됩니다.¶

클라이언트 측 세션은 서명되고 선택적으로 암호화된 객체에 모든 데이터를 담아 브라우저로 보냅니다. 이 패턴을 사용하면 서버가 세션 데이터를 추적할 필요가 없지만 활성 세션에 대한 제어가 크게 제한되고 세션 폐기를 처리하기가 어려워집니다. 그러나 BFF 컨텍스트에서 클라이언트 측 세션을 사용하면 이러한 속성이 크게 달라집니다. 쿠키 기반 세션은 사용자의 토큰을 얻는 데만 사용되므로 모든 제어 및 폐기 속성은 액세스 토큰과 갱신 토큰의 사용에 따라 결정됩니다. 쿠키 기반 세션을 명시적으로 무효화하지 않고도 사용자의 액세스 토큰 및/또는 갱신 토큰을 폐기하는 것만으로 보호된 리소스에 대한 지속적인 액세스를 방지할 수 있습니다.¶

세션 쿠키를 보호하기 위한 모범 사례는 제 6.1.3.2절에서 설명합니다.¶

6.1.2.4. OAuth와 OpenID Connect 결합

이 애플리케이션 아키텍처에서 사용하는 OAuth 흐름은 인가 요청(C)에 필요한 OpenID Connect 범위를 포함하여 OpenID Connect와 결합할 수 있습니다([OpenID]의 제3.1.2.1절에 정의된 openid 범위 이상). 이 경우 BFF는 (F)에서 ID 토큰을 받습니다. BFF는 ID 토큰의 정보를 사용자 세션과 연결하고 (B) 또는 (I)에서 애플리케이션에 제공할 수 있습니다.¶

필요한 경우 BFF는 사용자 세션과 연결된 액세스 토큰을 사용하여 UserInfo 엔드포인트로 요청을 보낼 수 있습니다.¶

6.1.2.5. 실용적인 배포 전략

정적 JavaScript 코드를 제공하는 작업은 OAuth 토큰을 처리하고 요청을 전달하는 작업과 별개의 책임입니다. 그림 1에서는 BFF와 정적 웹 호스트를 두 개의 별도 주체로 표시합니다. 실제 배포에서는 이러한 구성 요소를 하나의 서비스(즉, 정적 JavaScript 코드를 제공하는 BFF), 두 개의 별도 서비스(즉, 콘텐츠 전송 네트워크(CDN)와 BFF) 또는 하나의 서비스 내 두 구성 요소 (즉, 클라우드 플랫폼의 정적 호스팅과 서버리스 함수)로 배포할 수 있습니다.¶

특정 시나리오를 지원하도록 이 아키텍처를 추가로 사용자 정의할 수 있다는 점에 유의하십시오. 예를 들어 내부 리소스 서버와 외부 리소스 서버에 모두 의존하는 애플리케이션은 내부 리소스 서버를 BFF와 함께 호스팅할 수 있습니다. 이 시나리오에서는 내부 리소스 서버에 대한 요청을 네트워크를 통해 전달할 필요 없이 BFF에서 직접 처리합니다. 사용자 세션이 내부적으로 액세스 토큰과 그 클레임으로 변환되므로 리소스 서버 관점의 인가는 변경되지 않습니다.¶

6.1.3.1. 인가 코드 권한 부여

BFF 사용의 주요 이점은 BFF가 기밀 클라이언트로 동작할 수 있다는 것입니다. 따라서 BFF는 인가 서버와 자격 증명을 설정하여 기밀 클라이언트로 반드시 동작해야 합니다. 또한 BFF는 액세스 토큰 요청을 시작하기 위해 제2.1.1절, [RFC9700]에서 설명한 OAuth 2.0 인가 코드 권한 부여를 반드시 사용해야 합니다.¶

6.1.3.2. 쿠키 보안

BFF는 쿠키를 사용하여 사용자 세션을 만들며, 이 세션은 서버 측 또는 클라이언트 측 세션 상태를 통해 사용자의 토큰과 직접 연결됩니다. 이러한 쿠키는 민감하므로 적절히 보호해야 합니다.¶

다음 쿠키 보안 지침은 이 BFF 아키텍처와 관련이 있습니다.¶

• BFF는 쿠키에 Secure 플래그를 반드시 활성화해야 합니다.¶

• BFF는 쿠키에 HttpOnly 플래그를 반드시 활성화해야 합니다.¶

• BFF는 쿠키에 SameSite=Strict 플래그를 활성화해야 합니다.¶

• BFF는 쿠키 경로를 /로 설정해야 합니다.¶

• BFF는 쿠키에 Domain 속성을 설정해서는 안 됩니다.¶

• BFF는 쿠키가 HTTP를 통해 설정되었음을 나타내는 접두사로 쿠키 이름을 시작해야 합니다. 예를 들어 [COOKIES]에 정의된 __Host-Http- 접두사를 사용할 수 있습니다.¶

참고: 새로 배포하는 경우 위의 모든 요구 사항을 쉽게 구현할 수 있을 가능성이 높습니다. 기존 아키텍처도 준수할 수 있도록 "해야 합니다" 항목을 "반드시 해야 합니다" 항목으로 간주하지 않습니다. 이러한 요구 사항의 의미는 아래에 나열되어 있습니다.¶

이러한 쿠키 보안 지침은 HTTPS 사용과 결합하여 쿠키 기반 세션을 직접 대상으로 하는 공격에 대응하는 데 도움이 됩니다. Secure 및 HttpOnly 쿠키 플래그로 인해 세션 하이재킹이 불가능합니다. __Host-Http- 접두사는 쿠키가 하위 도메인과 공유되지 않도록 하여 하위 도메인 기반 세션 하이재킹이나 세션 고정 공격에 대응합니다. 일반적인 BFF 배포 시나리오에서는 위에 나열된 요구 사항보다 느슨한 쿠키 보안 설정을 사용할 이유가 없습니다. 이러한 설정을 벗어나려면 해당 배포 시나리오에 대한 타당한 근거가 필요합니다.¶

또한 액세스 토큰을 포함하는 클라이언트 측 세션을 사용할 때는 (토큰이 서버에만 존재하는 서버 측 세션과 달리) BFF가 쿠키 내용을 암호화해야 합니다. 쿠키 암호화를 사용해도 BFF 패턴의 보안 속성에는 영향을 주지 않지만, 쿠키에 저장된 토큰이 사용자의 로컬 영구 저장소에 평문 형식으로 기록되지 않도록 보장합니다. 이 보안 조치는 공격자가 하드 드라이브에서 쿠키를 읽을 수 있는 경우 토큰의 기밀성을 보장하는 데 도움이 됩니다. 이러한 공격은 피해자의 컴퓨터에서 실행되는 맬웨어를 통해 수행될 수 있습니다. 쿠키 내용을 암호화하면 내장된 토큰에 대한 직접 액세스를 방지하지만, 공격자는 여전히 세션 하이재킹 공격에서 암호화된 쿠키를 사용할 수 있습니다.¶

쿠키 보안 모범 사례에 관한 추가 지침은 OWASP 치트 시트 모음 [OWASPCheatSheet]을 참조하십시오.¶

6.1.3.3. 사이트 간 요청 위조 방지

브라우저 기반 애플리케이션과 BFF 간의 상호작용은 인증과 인가에 쿠키를 사용합니다. 다른 쿠키 기반 상호작용과 마찬가지로 BFF는 사이트 간 요청 위조(CSRF) 공격을 고려해야 합니다. CSRF 공격에 성공하면 공격자의 BFF 요청이 보호된 리소스로 나가는 호출을 트리거할 수 있습니다.¶

BFF는 적절한 CSRF 방어 수단을 반드시 구현해야 합니다. 정확한 메커니즘 또는 메커니즘의 조합은 아래에서 설명하는 것처럼 BFF가 배포되는 정확한 도메인에 따라 달라집니다.¶

6.1.3.4. BFF 아키텍처의 개인정보 보호 고려 사항

BFF 패턴을 사용할 때 브라우저 기반 애플리케이션은 백엔드 BFF 구성 요소를 통해 리소스 서버로 모든 요청을 전달해야 합니다. 따라서 BFF 구성 요소는 애플리케이션과 리소스 서버 사이의 모든 요청과 응답을 관찰할 수 있으며, 이는 개인정보 보호에 상당한 영향을 미칠 수 있습니다.¶

브라우저 기반 애플리케이션과 BFF를 동일한 당사자가 구축하고 배포한다면 개인정보 보호에 미치는 영향은 미미할 가능성이 높습니다. 그러나 서드 파티가 제공하거나 호스팅하는 BFF 구성 요소를 사용하여 이 패턴을 구현할 때는 개인정보 보호에 미치는 영향을 고려해야 합니다.¶

6.1.3.5. 운영 고려 사항

BFF가 프런트엔드를 대신하여 모든 요청을 리소스 서버로 전달하므로, 리소스 서버가 이 구성 요소를 인식하고 속도 제한 및 기타 악용 방지 조치에 적합한 정책을 사용하도록 주의해야 합니다. 예를 들어 BFF가 단일 인스턴스 서비스로 배포되고 리소스 서버가 IP 주소를 기준으로 요청 속도를 제한한다면, 많은 사용자의 브라우저가 BFF의 단일 IP 주소에서 오는 것으로 보이기 때문에 서버가 요청을 차단하기 시작할 수 있습니다.¶

6.1.3.6. 프록시 제한

BFF는 프런트엔드의 요청을 받아 리소스 서버로 전달하는 프록시 서비스로 동작합니다. 들어오는 요청에는 쿠키가 포함되며, BFF는 나가는 요청에서 이를 액세스 토큰으로 변환합니다. (이 때문에 HTTP 프록시보다는 애플리케이션 계층 역방향 프록시에 더 가깝다는 점에 유의하십시오.) CSRF 공격 외에도 공격자는 BFF가 의도하지 않은 호스트로 요청을 전달하도록 조작하려 할 수 있습니다. 공격자가 이를 성공적으로 악용하면 BFF를 임의의 서버로 리디렉션하여 사용자의 액세스 토큰이 노출될 수 있습니다.¶

이러한 위험을 완화하기 위해 BFF는 요청을 전달하기 전에 대상 호스트를 검증하여 엄격한 나가는 요청 제어를 반드시 적용해야 합니다. 이를 위해서는 승인된 리소스 서버의 명시적인 허용 목록을 유지하여 요청이 사전에 정의된 백엔드로만 프록시되도록 보장해야 합니다(예: /bff/orders/create는 https://order-api.example.com/create에만 매핑됨). 경로에 따른 동적 라우팅 (예: /bff/orders/{id})이 필요하다면 BFF는 인가된 대상에만 액세스할 수 있도록 엄격한 검증을 반드시 적용해야 합니다. 또한 엔드포인트별로 허용되는 HTTP 메서드를 제한하면 공격 벡터를 더욱 줄일 수 있습니다.¶

동적으로 구성할 수 있는 프록시를 구현할 때 BFF는 명시적으로 허용된 호스트와 경로에 대한 요청만 허용하도록 반드시 보장해야 합니다. 이러한 제한을 적용하지 않으면 무단 액세스와 액세스 토큰 유출이 발생할 수 있습니다.¶

6.1.3.7. 고급 보안

BFF 패턴에서는 모든 OAuth 관련 작업이 기밀 클라이언트로 동작하는 서버 측 구성 요소인 BFF로 이동합니다. 서버 측 애플리케이션은 브라우저 기반 애플리케이션보다 더 통제된 환경에서 실행되므로 고급 OAuth 보안 사례를 도입하기가 더 쉬워집니다. 예로는 키 기반 클라이언트 인증과 송신자 제한 토큰이 있습니다.¶

6.1.4.1. 공격 시나리오 및 결과

공격자가 애플리케이션의 실행 컨텍스트에서 악성 코드 (예: JavaScript 또는 WASM)를 실행할 수 있다면 다음 공격 시나리오가 관련됩니다.¶

• 사용자 브라우저를 통한 요청 프록시 처리(제 5.1.4절)¶

이 공격 시나리오는 다음 결과를 초래한다는 점에 유의하십시오.¶

• 클라이언트 하이재킹(제 5.2.3절)¶

클라이언트 하이재킹은 브라우저 기반 애플리케이션의 특성에 내재된 공격 시나리오라는 점에 유의하십시오. 따라서 처음부터 악성 코드의 실행을 차단하는 것 외에는 이러한 공격을 방지할 수 있는 방법이 없습니다. 이를 달성하는 데 도움이 되는 기법에는 안전한 코딩 지침 준수, 코드 분석 및 콘텐츠 보안 정책 [W3C.CSP3]과 같은 심층 방어 메커니즘 배포가 있습니다.¶

이 아키텍처에서 BFF는 다양한 보안 관련 책임과 프록시 기반 동작을 처리하는 핵심 구성 요소입니다. 프록시 기반 애플리케이션의 안전한 구현을 논의하는 것은 이 문서의 범위를 벗어나지만, BFF의 보안 취약점이 애플리케이션에 상당한 영향을 미칠 수 있다는 점에 유의해야 합니다.¶

마지막으로 BFF는 브라우저 기반 애플리케이션과 리소스 서버 사이의 모든 트래픽을 관찰하기에 적합한 고유한 위치에 있습니다. 높은 보안 수준이 필요한 애플리케이션에서 이상 징후 탐지나 속도 제한을 구현하려 한다면 BFF가 이를 수행하기에 이상적인 위치입니다. 이러한 제한은 클라이언트 하이재킹의 결과를 더욱 완화하는 데 도움이 될 수 있습니다.¶

6.1.4.2. 완화된 공격 시나리오

아래에 나열된 다른 공격 시나리오는 BFF 애플리케이션 아키텍처를 통해 효과적으로 완화됩니다.¶

• 단일 실행 토큰 탈취(제 5.1.1절)¶

• 지속적인 토큰 탈취(제 5.1.2절)¶

• 새로운 토큰의 획득 및 추출(제 5.1.3절)¶

BFF는 브라우저 기반 애플리케이션에 어떠한 토큰도 노출하지 않아 처음 두 공격 시나리오에 대응합니다. 공격자가 애플리케이션을 완전히 제어하더라도 탈취할 토큰이 전혀 없습니다.¶

공격자가 자동 흐름을 실행하여 새로운 액세스 토큰(및 선택적으로 갱신 토큰)을 얻는 세 번째 시나리오는 BFF를 기밀 클라이언트로 만들어 완화합니다. 공격자가 인가 코드를 얻더라도 클라이언트 자격 증명이 없으므로 이 코드를 교환할 수 없습니다. 또한 PKCE를 사용하면 인가 코드에 대한 다른 공격을 방지할 수 있습니다.¶

갱신 토큰과 액세스 토큰은 BFF에서 관리하며 브라우저에 노출되지 않으므로 잠재적인 공격이 초래하는 다음 두 결과는 관련이 없습니다.¶

• 탈취된 갱신 토큰 악용(제 5.2.1절)¶

• 탈취된 액세스 토큰 악용(제 5.2.2절)¶

6.1.4.3. 요약

BFF 아키텍처는 브라우저 전용 애플리케이션보다 훨씬 복잡합니다. 서버 측 BFF 구성 요소를 배포하고 운영해야 합니다. 또한 이 패턴에서는 애플리케이션과 리소스 서버 사이의 모든 상호작용을 BFF가 프록시해야 합니다. 배포 패턴에 따라 이러한 프록시 동작이 서버 측 구성 요소에 상당한 부담을 줄 수 있습니다. BFF가 리소스 서버로 동작하는 경우의 추가 참고 사항은 제 6.2.2.6절을 참조하십시오.¶

그러나 BFF 아키텍처 패턴의 특성으로 인해 강력한 보안을 보장합니다. 또한 BFF를 사용하면 OAuth 사용으로 인해 애플리케이션의 공격 표면이 증가하지 않습니다. 실행 가능한 유일한 공격 패턴은 사용자의 브라우저에서 클라이언트 애플리케이션을 하이재킹하는 것으로, 이는 웹 애플리케이션에 내재된 문제입니다.¶

이 아키텍처는 비즈니스 애플리케이션, 민감한 애플리케이션 및 개인정보를 처리하는 애플리케이션에 적극 권고됩니다.¶

6.2.2.1. 세션 및 OAuth 엔드포인트

토큰 중개 백엔드 엔드포인트의 구현 대부분은 BFF에 관해 설명한 구현과 유사합니다.¶

• "check session" 엔드포인트(그림 2의 (B)와 (I))는 브라우저 기반 애플리케이션이 호출하는 API 엔드포인트입니다. 사용 가능한 경우 요청에는 세션 정보가 포함되므로 백엔드가 활성 세션을 확인할 수 있습니다. 응답은 브라우저 기반 애플리케이션에 세션이 활성 상태인지 알려야 합니다. 활성 세션이 발견되면 백엔드는 응답에 액세스 토큰을 포함합니다. 또한 백엔드는 인증된 사용자의 신원 정보와 같은 다른 정보도 포함할 수 있습니다.¶

• 인가 코드 흐름을 시작하는 엔드포인트 (C)는 BFF 아키텍처에서 설명한 엔드포인트와 동일합니다. 자세한 내용은 제6.1.2.1절을 참조하십시오.¶

• 인가 코드를 받는 엔드포인트 (E)는 BFF 아키텍처에서 설명한 엔드포인트와 동일합니다. 자세한 내용은 제6.1.2.1절을 참조하십시오.¶

• 로그아웃을 지원하는 엔드포인트는 BFF 아키텍처에서 설명한 엔드포인트와 동일합니다. 자세한 내용은 제6.1.2.1절을 참조하십시오.¶

6.2.2.2. 갱신 토큰

제4.14절, [RFC9700]에서 설명한 대로 갱신 토큰을 사용할 때 토큰 중개 백엔드는 (F)에서 갱신 토큰을 얻고 이를 사용자 세션과 연결합니다.¶

리소스 서버가 액세스 토큰을 거부하면 애플리케이션은 토큰 중개 백엔드에 접속하여 새 액세스 토큰을 요청할 수 있습니다. 토큰 중개 백엔드는 이 요청과 연결된 쿠키를 사용하여 사용자의 갱신 토큰을 조회하고 갱신 토큰을 사용해 토큰 요청을 보냅니다. 이러한 단계는 그림 2에 표시되지 않습니다. 이 갱신 토큰 요청은 기밀 클라이언트인 백엔드에서 전송하므로 클라이언트 인증이 필요하다는 점에 유의하십시오.¶

갱신 토큰이 만료되면 완전히 새로운 인가 코드 권한 부여를 시작하지 않고서는 유효한 액세스 토큰을 얻을 방법이 없습니다. 따라서 해당 정보를 미리 알고 있다면 쿠키 기반 세션의 수명을 갱신 토큰의 최대 수명과 동일하게 구성하는 것이 합리적입니다. 또한 토큰 중개 백엔드가 활성 세션의 갱신 토큰이 더 이상 유효하지 않다는 사실을 알게 되면 세션을 무효화하는 것이 합리적입니다.¶

6.2.2.3. 액세스 토큰 범위

액세스하는 리소스 서버와 인가 서버의 범위 구성에 따라 애플리케이션은 서로 다른 범위 구성을 가진 액세스 토큰을 요청할 수 있습니다. 이 동작을 통해 애플리케이션은 최소한의 범위가 지정된 액세스 토큰을 사용하는 모범 사례를 따를 수 있습니다.¶

애플리케이션은 활성 세션을 확인할 때((A) 및 (I)) 원하는 범위를 토큰 중개 백엔드에 알릴 수 있습니다. 이전에 얻은 액세스 토큰이 원하는 범위 기준을 충족하는지는 토큰 중개 백엔드가 결정합니다.¶

토큰 중개 백엔드의 이러한 액세스 토큰 캐싱 메커니즘을 무분별하게 적용하면 범위 상승 위험이 발생할 수 있다는 점에 유의해야 합니다. 캐시된 액세스 토큰의 범위가 프런트엔드에서 요청한 범위의 상위 집합이라면 토큰 중개 백엔드는 이를 프런트엔드로 반환해서는 안 됩니다. 대신 갱신 토큰을 사용하여 인가 서버로부터 더 작은 범위 집합을 가진 액세스 토큰을 요청해야 합니다. 이러한 액세스 토큰 범위 축소 메커니즘의 지원 여부는 인가 서버가 결정한다는 점에 유의하십시오.¶

토큰 중개 백엔드는 특정 리소스 서버용 액세스 토큰을 얻기 위해 [RFC8707]에 설명된 확장에 의존할 때 범위 축소 메커니즘과 유사한 메커니즘을 사용할 수 있습니다.¶

6.2.2.4. 쿠키 기반 세션 상태

BFF와 마찬가지로 토큰 중개 백엔드는 사용자 세션을 추적하기 위해 브라우저 쿠키에 의존합니다. 쿠키 기반 세션의 구현 지침과 보안 고려 사항은 제6.1.2.3절에서 설명한 BFF의 경우와 동일합니다.¶

6.2.2.5. OAuth와 OpenID Connect 결합

BFF와 마찬가지로 토큰 중개 백엔드는 OAuth와 OpenID Connect를 단일 흐름으로 결합할 수 있습니다. 자세한 내용은 제6.1.2.4절을 참조하십시오.¶

6.2.2.6. 실용적인 배포 시나리오

정적 JavaScript 또는 WASM 코드를 호스팅하는 것은 인가 서버와의 상호작용을 처리하는 것과 별개의 책임입니다. 그림 2에서는 토큰 중개 백엔드와 정적 웹 호스트를 별도의 두 주체로 표시합니다. 실제 배포 시나리오에서는 이러한 구성 요소를 하나의 서비스(즉, 정적 코드를 제공하는 토큰 중개 백엔드), 두 개의 별도 서비스(즉, CDN과 토큰 중개 백엔드) 또는 하나의 서비스 내 두 구성 요소(즉, 클라우드 플랫폼의 정적 호스팅과 서버리스 함수)로 배포할 수 있습니다. 이러한 배포상의 차이는 이 패턴에서 설명한 관계에 영향을 주지 않지만, 교차 오리진 통신을 활성화하기 위한 올바른 CORS 구성의 필요성과 같은 다른 실무적인 사항에는 영향을 줄 수 있습니다.¶

6.2.3.1. 인가 코드 권한 부여

토큰 중개 백엔드 사용의 주요 이점은 백엔드가 기밀 클라이언트로 동작할 수 있다는 것입니다. 따라서 토큰 중개 백엔드는 기밀 클라이언트로 반드시 동작해야 합니다. 또한 토큰 중개 백엔드는 액세스 토큰 요청을 시작하기 위해 제2.1.1절, [RFC9700]에 설명된 OAuth 2.0 인가 코드 권한 부여를 반드시 사용해야 합니다.¶

6.2.3.2. 쿠키 보안

토큰 중개 백엔드는 쿠키를 사용하여 사용자 세션을 만들며, 이 세션은 서버 측 또는 클라이언트 측 세션 상태를 통해 사용자의 토큰과 직접 연결됩니다. BFF에 대해 수립된 것과 동일한 쿠키 보안 지침이 적용되며, 이에 관한 내용은 제 6.1.3.2절에서 설명합니다.¶

6.2.3.3. 사이트 간 요청 위조 방지

브라우저 기반 애플리케이션과 토큰 중개 백엔드 간의 상호작용은 인증과 인가에 쿠키를 사용합니다. BFF와 마찬가지로 토큰 중개 백엔드는 CSRF 공격을 고려해야 합니다.¶

제6.1.3.3절에서는 다양한 CSRF 공격 완화 전략의 세부적인 차이를 설명합니다. 특히 토큰 중개 백엔드에서 이러한 CSRF 방어 수단은 애플리케이션이 액세스 토큰을 얻을 수 있는 엔드포인트에만 적용됩니다.¶

6.2.3.4. 고급 OAuth 보안

토큰 중개 백엔드는 서버 측 구성 요소로 실행되는 기밀 클라이언트입니다. 토큰 중개 백엔드는 키 기반 클라이언트 인증과 같은 기밀 클라이언트용 보안 모범 사례를 도입할 수 있습니다.¶

6.2.4.1. 공격 시나리오 및 결과

공격자가 애플리케이션의 실행 컨텍스트에서 악성 코드를 실행할 수 있다면 다음 공격 시나리오가 관련됩니다.¶

• 액세스 토큰에 대한 단일 실행 토큰 탈취(제 5.1.1절)¶

• 액세스 토큰에 대한 지속적인 토큰 탈취(제 5.1.2절)¶

• 사용자 브라우저를 통한 요청 프록시 처리(제 5.1.4절)¶

이러한 공격 시나리오는 다음 결과를 초래한다는 점에 유의하십시오.¶

• 탈취된 액세스 토큰 악용(제 5.2.2절)¶

• 클라이언트 하이재킹(제 5.2.3절)¶

액세스 토큰을 브라우저 기반 애플리케이션에 노출하는 것은 토큰 중개 백엔드 아키텍처 패턴의 핵심 개념입니다. 따라서 액세스 토큰은 악성 브라우저 기반 코드에 의한 토큰 탈취에 취약해집니다.¶

6.2.4.2. 완화된 공격 시나리오

아래에 나열된 다른 공격 시나리오는 토큰 중개 백엔드를 통해 효과적으로 완화됩니다.¶

• 갱신 토큰에 대한 단일 실행 토큰 탈취(제 5.1.1절)¶

• 갱신 토큰에 대한 지속적인 토큰 탈취(제 5.1.2절)¶

• 새로운 토큰의 획득 및 추출(제 5.1.3절)¶

토큰 중개 백엔드는 브라우저 기반 애플리케이션에 갱신 토큰을 노출하지 않아 처음 두 공격 시나리오에 대응합니다. 공격자가 애플리케이션을 완전히 제어하더라도 탈취할 갱신 토큰이 전혀 없습니다.¶

공격자가 자동 흐름을 실행하여 새로운 액세스 토큰(및 선택적으로 갱신 토큰)을 얻는 세 번째 시나리오는 토큰 중개 백엔드를 기밀 클라이언트로 만들어 완화합니다. 공격자가 인가 코드를 얻더라도 클라이언트 자격 증명이 없으므로 이 코드를 교환할 수 없습니다. 또한 PKCE를 사용하면 인가 코드에 대한 다른 공격을 방지할 수 있습니다.¶

토큰 중개 백엔드의 특성으로 인해 잠재적인 공격이 초래하는 다음 결과는 관련이 없습니다.¶

• 탈취된 갱신 토큰 악용(제 5.2.1절)¶

6.2.4.3. 추가 방어 수단

이 아키텍처는 본질적으로 액세스 토큰을 노출하지만 애플리케이션의 보안 태세를 강화하는 데 도움이 되는 몇 가지 추가 방어 수단이 있습니다.¶

6.2.4.4. 요약

토큰 중개 백엔드의 아키텍처는 브라우저 전용 애플리케이션보다 복잡하지만 프록시 BFF를 실행하는 것보다는 덜 복잡합니다. 마찬가지로 토큰 중개 백엔드가 제공하는 보안 속성도 BFF를 사용하는 경우와 브라우저 전용 애플리케이션을 실행하는 경우 사이에 있습니다.¶

토큰 중개 백엔드는 공격자에게 사용자를 대신하는 장기적인 액세스를 부여하는 일반적인 시나리오에 대응합니다. 그러나 액세스 토큰 탈취의 결과로 공격자는 여전히 리소스 서버에 직접 액세스할 수 있습니다.¶

토큰 중개 백엔드 아키텍처를 고려할 때는 제6.1절에서 설명한 완전한 BFF를 도입하는 것이 실행 가능한 대안인지 평가할 것을 적극 권고합니다. 사용 사례나 시스템 요구 사항으로 인해 프록시 BFF를 사용할 수 없는 경우에만 완전한 BFF 대신 토큰 중개 백엔드를 고려해야 합니다.¶

6.3.2.1. 인가 코드 권한 부여

공개 클라이언트인 브라우저 기반 애플리케이션은 액세스 토큰을 얻을 때 PKCE [RFC7636] 확장을 반드시 구현해야 하며, 인가 서버는 이러한 클라이언트에 PKCE를 반드시 지원하고 적용해야 합니다.¶

PKCE 확장은 인가 서버가 인가 코드를 교환하는 클라이언트 인스턴스와 흐름을 시작한 인스턴스가 동일한지 검증할 수 있도록 하여 인가 코드가 가로채지고 악성 클라이언트에 의해 액세스 토큰으로 교환되는 공격을 방지합니다.¶

6.3.2.2. 사이트 간 요청 위조 방지

브라우저 기반 애플리케이션은 리디렉션 URI에 대한 CSRF 공격을 반드시 방지해야 합니다. 다음 방법 중 하나로 이를 수행할 수 있습니다.¶

• 이 클라이언트에 PKCE를 요구하도록 인가 서버를 구성합니다.¶

• CSRF 토큰을 전달하도록 OAuth state 매개변수에 고유한 값을 사용하고 검증합니다.¶

• 애플리케이션이 OpenID Connect도 사용한다면 [OpenID]에 설명된 OpenID Connect nonce 매개변수를 사용하고 검증합니다.¶

인가 코드 흐름에 적절한 CSRF 방어 수단을 선택하는 방법에 관한 자세한 내용은 제2.1절, [RFC9700]을 참조하십시오.¶

6.3.2.3. 갱신 토큰

애플리케이션이 DPoP [RFC9449]를 명시적으로 사용하지 않는 한, 브라우저 기반 클라이언트의 갱신 토큰은 일반적으로 베어러 토큰입니다. 따라서 유출된 갱신 토큰의 위험은 유출된 액세스 토큰보다 큽니다. 공격자가 탈취한 갱신 토큰을 계속 사용하여 인가 서버에서 탐지되지 않은 채 새로운 액세스 토큰을 얻을 가능성이 있기 때문입니다.¶

인가 서버는 브라우저 기반 애플리케이션에 갱신 토큰을 발급할지 선택할 수 있습니다. 그러나 서드 파티 쿠키 차단 메커니즘의 영향을 고려하면 갱신 토큰 사용의 이점이 훨씬 커졌습니다. [RFC9700]에서는 [RFC6749]의 권고 사항에 더하여 갱신 토큰에 관한 몇 가지 추가 요구 사항을 설명합니다. 이 BCP를 준수하는 애플리케이션과 인가 서버는 브라우저 기반 애플리케이션에 갱신 토큰을 발급하는 경우 [RFC9700]의 갱신 토큰 관련 권고 사항도 반드시 따라야 합니다.¶

특히 인가 서버는 다음 요구 사항을 따라야 합니다.¶

• 갱신 토큰을 사용할 때마다 반드시 순환시키거나 제4.14.2절, [RFC9700]에 설명된 송신자 제한 갱신 토큰을 반드시 사용해야 합니다.¶

• 갱신 토큰에 최대 수명을 설정하거나 일정 기간 갱신 토큰이 사용되지 않으면 만료되도록 반드시 해야 합니다.¶

• 갱신 토큰에 미리 설정된 만료 시간이 있다면 순환된 갱신 토큰을 발급할 때 새 갱신 토큰의 수명을 최초 갱신 토큰의 수명 이후로 연장해서는 안 됩니다.¶

전체 갱신 토큰 수명을 최초 갱신 토큰의 수명으로 제한하면 탈취된 갱신 토큰이 무기한 사용되지 않도록 보장할 수 있습니다.¶

예를 들면 다음과 같습니다.¶

• 사용자가 애플리케이션을 인가하여 10분 동안 유효한 액세스 토큰과 8 시간 동안 유효한 갱신 토큰이 발급됩니다.¶

• 10분 후 최초 액세스 토큰이 만료되므로 애플리케이션이 갱신 토큰을 사용하여 새 액세스 토큰을 얻습니다.¶

• 인가 서버는 10분 동안 유효한 새 액세스 토큰과 7시간 50분 동안 유효한 새 갱신 토큰을 반환합니다.¶

• 최초 인가 시점으로부터 8시간이 지날 때까지 이 과정이 계속됩니다.¶

• 이 시점에 애플리케이션이 8시간 후 갱신 토큰을 사용하려 하면 요청이 실패하며, 애플리케이션은 사용자의 인증 또는 이전에 설정된 세션에 의존하는 인가 코드 흐름을 다시 시작해야 합니다.¶

인가 서버는 갱신 토큰의 수명을 인가 서버에 설정된 사용자의 인증 세션과 연결해야 합니다. 이렇게 하면 사용자가 로그아웃할 때 브라우저 기반 애플리케이션에 이전에 발급된 갱신 토큰이 무효화되어 단일 로그아웃 시나리오와 같은 동작을 합니다. 인가 서버는 브라우저 기반 애플리케이션과 다른 공개 클라이언트에 서로 다른 갱신 토큰 발급, 수명 및 만료 정책을 설정할 수 있습니다.¶

6.3.3.1. 클라이언트 인증

브라우저 기반 애플리케이션의 소스 코드는 최종 사용자의 브라우저로 전달되므로 프로비저닝된 비밀 값을 포함하기에 적합하지 않습니다. 따라서 브라우저 기반 애플리케이션은 일반적으로 제2.1절, [RFC6749]에 정의된 공개 클라이언트로 배포됩니다.¶

여러 사용자에게 배포되는 앱의 일부로 정적으로 포함된 비밀 값은 기밀 비밀 값으로 취급해서는 안 됩니다. 한 사용자가 자신의 사본을 검사하여 공유 비밀 값을 알아낼 수 있기 때문입니다. 이러한 이유와 제5.3.1절, [RFC6819]에 명시된 이유로 인가 서버는 공유 비밀 값을 사용하는 브라우저 기반 애플리케이션의 클라이언트 인증을 요구해서는 안 됩니다. 이는 client_id 매개변수에서 이미 제공하는 클라이언트 식별 이외에는 아무런 가치가 없기 때문입니다.¶

SPA 클라이언트에 정적으로 포함된 공유 비밀 값을 여전히 요구하는 인가 서버는 해당 클라이언트를 공개 클라이언트로 반드시 취급해야 하며 그 비밀 값을 클라이언트 신원의 증거로 받아들여서는 안 됩니다. 추가 조치가 없다면 이러한 클라이언트는 클라이언트 사칭의 대상이 됩니다 (제 6.3.3.2절 참조).¶

6.3.3.2. 클라이언트 사칭

제10.2절, [RFC6749]에 명시된 대로 인가 서버는 클라이언트 애플리케이션의 신원을 보장할 수 있는 경우를 제외하고 사용자의 동의나 상호작용 없이 인가 요청을 자동으로 처리해서는 안 됩니다.¶

인가 서버가 리디렉션 URI를 와일드카드 도메인, 와일드카드 경로 또는 와일드카드 쿼리 문자열 구성 요소의 사용을 방지하는 고정된 절대 HTTPS URI 집합으로 제한한다면, 등록된 절대 HTTPS URI의 이러한 정확한 일치를 인가 서버에서 client_id에 대한 이전 요청이 이미 승인된 경우 인가 요청을 자동으로 처리할지 결정하기 위한 클라이언트 신원의 증거로 받아들일 수 있습니다.¶

6.3.3.3. 브라우저 내 통신 흐름의 보안

브라우저 기반 애플리케이션에서는 기본 창을 리디렉션하는 대신 팝업이나 iframe 같은 보조 창에서 OAuth 흐름을 실행하는 것이 일반적입니다. 이러한 흐름에서 브라우저 기반 앱은 페이지 새로고침을 방지하거나 프레임 기반 흐름을 자동으로 실행하는 등의 목적으로 기본 창을 계속 제어합니다.¶

브라우저 기반 앱과 인가 서버가 서로 다른 프레임에서 호출된다면 최상위 리디렉션 대신 postMessage API(즉, [WebMessaging])와 같은 브라우저 내 통신 기법을 사용해야 합니다. 메시지의 기밀성과 진위성을 보장하려면 postMessage의 발신자 오리진과 수신자 오리진을 모두 postMessage API에서 기본적으로 제공하는 메커니즘을 사용하여 반드시 검증해야 합니다 ([WebMessaging]의 제9.3.2절).¶

제4.17절, [RFC9700]에서는 브라우저 내 통신 흐름의 보안과 이러한 공격을 방어하기 위해 브라우저 기반 애플리케이션과 인가 서버에서 반드시 적용해야 하는 대응책을 자세히 설명합니다.¶

6.3.3.4. 교차 오리진 요청

이 시나리오에서 애플리케이션은 브라우저 API를 사용하여 인가 서버와 리소스 서버로 요청을 보냅니다. OAuth 2.0의 특성상 이러한 요청은 일반적으로 교차 오리진 요청이므로 브라우저에서 적용하는 교차 오리진 통신 제한의 대상이 됩니다. 인가 서버와 리소스 서버는 애플리케이션이 필요한 교차 오리진 요청을 보낼 수 있도록 필요한 CORS 헤더([Fetch]에 정의됨)를 반드시 전송해야 합니다. 브라우저 기반 OAuth 클라이언트가 인가 서버 또는 리소스 서버와 동일한 오리진에서 실행되는 예외적인 시나리오에서는 필요한 상호작용을 활성화하기 위한 CORS 정책이 필요하지 않다는 점에 유의하십시오.¶

인가 서버의 CORS 구성은 브라우저 기반 애플리케이션이 인가 코드를 토큰으로 교환하는 토큰 엔드포인트와 관련이 있습니다. 또한 인가 서버가 검색 메타데이터 URL, JSON 웹 키 집합, 동적 클라이언트 등록, 폐기, 인트로스펙션 또는 사용자 정보 엔드포인트와 같은 추가 엔드포인트를 애플리케이션에 제공한다면 브라우저 기반 애플리케이션이 이러한 엔드포인트에도 액세스할 수 있습니다. 따라서 인가 서버는 이러한 엔드포인트에서 CORS를 지원할 책임이 있습니다.¶

이 명세에는 와일드카드 오리진이나 더 제한적인 구성으로 이루어질 수 있는 구체적인 CORS 정책 구현을 결정하기 위한 지침이 포함되어 있지 않습니다. CORS에는 서로 다른 보안 속성을 지닌 두 가지 동작 모드가 있다는 점에 유의하십시오. 첫 번째 모드는 브라우저가 요청을 보내고 CORS 응답 헤더를 사용하여 응답을 클라이언트 측 실행 컨텍스트에 노출할 수 있는지 결정하는 CORS 안전 목록 요청 (이전에는 단순 요청이라고 함)에 적용됩니다. 사용자 정의 요청 헤더가 있는 요청과 같은 CORS 안전 목록에 없는 요청의 경우 브라우저는 먼저 프리플라이트를 사용하여 CORS 정책을 확인합니다. 브라우저는 서버가 프리플라이트 응답에서 승인한 경우에만 실제 요청을 보냅니다.¶

인가 서버의 특정 구성으로 인해 프리플라이트에 대한 CORS 응답과 실제 요청에 대한 CORS 응답이 다를 수 있다는 점에 유의하십시오. 프리플라이트 중에는 인가 서버가 제공된 오리진만 검증할 수 있지만, 실제 요청 중에는 클라이언트 ID와 같은 전체 요청 데이터를 확인할 수 있습니다. 따라서 인가 서버는 프리플라이트 중에는 알려진 오리진을 승인하지만, 오리진을 해당 클라이언트에 사전 등록된 오리진 목록과 비교한 후 실제 요청을 거부할 수 있습니다.¶

6.3.4.1. 공격 시나리오 및 결과

공격자가 애플리케이션의 실행 컨텍스트에서 악성 코드를 실행할 수 있다면 다음 공격 시나리오가 관련됩니다.¶

• 단일 실행 토큰 탈취(제 5.1.1절)¶

• 지속적인 토큰 탈취(제 5.1.2절)¶

• 새로운 토큰의 획득 및 추출(제 5.1.3절)¶

• 사용자 브라우저를 통한 요청 프록시 처리(제 5.1.4절)¶

가장 위험한 공격 시나리오는 새로운 토큰의 획득 및 추출입니다. 이 공격 시나리오에서 공격자는 인가 서버와만 상호작용하므로 클라이언트에서 OAuth 기능을 실제로 구현한 세부 방식은 중요하지 않습니다. 적법한 클라이언트 애플리케이션이 공격자로부터 토큰을 완전히 격리하는 방법을 찾더라도 공격자는 여전히 인가 서버로부터 토큰을 얻을 수 있습니다.¶

이러한 공격 시나리오는 다음 결과를 초래한다는 점에 유의하십시오.¶

• 탈취된 갱신 토큰 악용(제 5.2.1절)¶

• 탈취된 액세스 토큰 악용(제 5.2.2절)¶

• 클라이언트 하이재킹(제 5.2.3절)¶

6.3.4.2. 추가 방어 수단

이 아키텍처는 본질적으로 악성 브라우저 기반 코드에 취약하지만 애플리케이션의 보안 태세를 강화하는 데 도움이 되는 몇 가지 추가 방어 수단이 있습니다. 이러한 방어 수단 중 어느 것도 공격자가 새로운 흐름을 실행하여 토큰을 얻을 수 있도록 하는 근본적인 문제를 해결하지 못한다는 점에 유의하십시오.¶

6.3.4.3. 요약

요약하면 브라우저 기반 OAuth 클라이언트 애플리케이션의 아키텍처는 간단하지만 애플리케이션의 공격 표면을 크게 증가시킵니다. 공격자는 클라이언트를 하이재킹할 수 있을 뿐만 아니라 브라우저 기반 애플리케이션에서 완전한 기능을 갖춘 토큰 집합을 추출할 수도 있습니다.¶

이 아키텍처는 비즈니스 애플리케이션, 민감한 애플리케이션 및 개인정보를 처리하는 애플리케이션에 권고되지 않습니다.¶

7.2.3.1. 리디렉션 URI 조작

공격자가 인가 응답을 자신이 제어하는 URI로 전송되게 할 수 있다면 액세스 토큰을 포함한 인가 응답에 직접 액세스할 수 있습니다. 이 공격을 수행하는 여러 방법은 [RFC9700]에 자세히 설명되어 있습니다.¶

7.2.3.2. 브라우저 기록의 액세스 토큰 유출

공격자는 브라우저 기록에서 액세스 토큰을 얻을 수 있습니다. [RFC6819]에서 권고하는 대응책은 토큰에 짧은 만료 시간을 사용하고 브라우저에서 응답을 캐시하지 않도록 하는 것으로 제한됩니다. 이들 중 어느 것도 공격을 완전히 방지하지 못하며 잠재적인 피해만 줄일 수 있습니다.¶

또한 많은 브라우저가 이제 브라우저 기록을 클라우드 서비스 및 여러 기기와 동기화하므로 URL에서 액세스 토큰을 추출할 수 있는 공격 표면이 더욱 넓어집니다.¶

이에 관한 자세한 내용은 제4.3.2절, [RFC9700]에서 설명합니다.¶

7.2.3.3. 스크립트 조작

공격자는 기업 네트워크 등에서 브라우저의 HTTPS 연결을 가로채는 경우를 포함해 여러 수단을 통해 페이지를 수정하거나 브라우저에 스크립트를 삽입할 수 있습니다. 일반적으로 TLS 계층에 대한 공격을 방지하는 것은 기본 보안 권고 사항의 범위를 벗어나지만, 브라우저 기반 애플리케이션에서는 이러한 공격을 훨씬 쉽게 수행할 수 있습니다. 삽입된 스크립트를 통해 공격자는 페이지의 모든 것에 액세스할 수 있습니다.¶

애플리케이션이 액세스 토큰을 얻는 알려진 표준 방식을 사용할 때 페이지에서 실행되는 악성 스크립트의 위험이 커질 수 있습니다. 즉, 공격자는 언제든 window.location 변수를 확인하여 액세스 토큰을 찾을 수 있습니다. 이러한 위협 프로필은 인가 코드 흐름을 통해 얻은 액세스 토큰이 어디에 또는 어떻게 저장되는지 알고 개별 애플리케이션을 구체적으로 대상으로 삼는 공격자와 다릅니다.¶

7.2.3.4. 서드 파티 스크립트로의 액세스 토큰 유출

브라우저 기반 애플리케이션에서는 분석 도구, 충돌 보고, 소셜 미디어 "좋아요" 버튼 등의 서드 파티 스크립트를 사용하는 것이 비교적 일반적입니다. 이러한 상황에서 애플리케이션 작성자는 애플리케이션에서 실행되는 모든 코드를 완전히 파악하지 못할 수 있습니다. 액세스 토큰이 프래그먼트에 반환되면 페이지의 모든 서드 파티 스크립트에 노출됩니다.¶

7.4.1.1. 서비스 워커 공격

서비스 워커 사용이 제공하는 유망해 보이는 보안 이점의 한계는 더 자세히 논의할 필요가 있습니다. 관련 공격 시나리오(제5.1절)로부터 애플리케이션을 완전히 보호하려면 서비스 워커가 다음 두 가지 보안 요구 사항을 충족해야 합니다.¶

1. 공격자가 토큰을 외부로 유출하지 못하도록 합니다.¶

2. 공격자가 새로운 토큰 집합을 얻지 못하도록 합니다.¶

서비스 워커가 등록되면 인가 코드 흐름을 실행하여 토큰을 얻습니다. 서비스 워커는 자체적으로 격리된 실행 환경에서 토큰을 추적하므로 잠재적인 악성 코드를 포함한 모든 애플리케이션 코드가 토큰에 접근할 수 없습니다. 따라서 서비스 워커는 토큰 외부 유출을 방지한다는 첫 번째 요구 사항을 충족합니다. 이는 본질적으로 제5.1절에서 설명한 처음 두 공격 시나리오를 무력화합니다.¶

두 번째 보안 요구 사항을 충족하려면 서비스 워커가 적법한 애플리케이션을 제어하는 공격자가 새로운 인가 코드 권한 부여를 실행할 수 없도록 보장해야 합니다. 이 공격은 제 5.1.3절에서 설명합니다. 서비스 워커의 특성상 등록된 서비스 워커는 프레임이나 새 창에서 발생하더라도 이러한 새로운 흐름을 시작하는 모든 외부 요청을 차단할 수 있습니다.¶

그러나 애플리케이션 내부에서 실행되는 악성 코드는 이 서비스 워커의 등록을 해제할 수 있습니다. 서비스 워커의 등록을 해제하면 애플리케이션 기능에 상당한 영향을 미칠 수 있으므로 브라우저가 가볍게 처리하는 작업은 아닙니다. 따라서 등록이 해제된 서비스 워커는 그 상태로 표시되지만 현재 실행 중인 모든 인스턴스는 해당 브라우징 컨텍스트가 종료될 때까지 활성 상태를 유지합니다(예: 탭 또는 창을 닫는 경우). 따라서 공격자가 서비스 워커의 등록을 해제하더라도 서비스 워커는 활성 상태를 유지하며 공격자가 인가 서버에 접근하는 것을 계속 방지할 수 있습니다.¶

서비스 워커의 등록을 해제하면 새로운 브라우징 컨텍스트를 열 때 서비스 워커가 존재하지 않는다는 결과가 발생합니다. 따라서 공격자가 먼저 서비스 워커의 등록을 해제한 다음 프레임에서 새 흐름을 시작하면 프레임의 브라우징 컨텍스트와 연결된 서비스 워커가 없습니다. 이에 따라 공격자는 자체적인 새로운 인가 코드 권한 부여를 실행하고 프레임의 URL에서 인가 코드를 추출한 다음 토큰으로 교환할 수 있습니다. 본질적으로 서비스 워커는 두 번째 보안 요구 사항을 충족하지 못하므로 공격자가 새로운 토큰 집합을 얻는 시나리오(제5.1.3절)에 취약합니다.¶

이러한 단점과 서비스 워커를 등록하고 유지 관리하는 데 따르는 상당한 복잡성 때문에 이 패턴은 권고되지 않습니다.¶

마지막으로 서비스 워커 사용 자체는 애플리케이션의 공격 표면을 증가시키지 않는다는 점에 유의하십시오. 실제로 서비스 워커는 기존 애플리케이션이 나가는 요청에 OAuth 액세스 토큰을 포함하도록 지원 기능을 추가하는 데 자주 사용됩니다. 이러한 시나리오의 서비스 워커는 애플리케이션의 보안 속성을 변경하지 않으며 단지 애플리케이션의 개발과 유지 관리를 단순화할 뿐입니다.¶