ブラウザベースのアプリケーション向け OAuth 2.0

6.1.2.1. 세션 및 OAuth 엔드포인트

BFF는 브라우저 기반 애플리케이션과 BFF 사이의 상호 작용을 구현하는 데 핵심적인 엔드포인트 집합을 제공한다. 이 절은 이러한 엔드포인트의 목적과 사용 사례를 명확히 하기 위해 조금 더 자세히 논의한다.¶

"check session" 엔드포인트(위 그림의 B 및 I 단계)는 브라우저 기반 애플리케이션이 호출하는 API 엔드포인트이다. 요청에는 사용 가능한 경우 세션 정보가 포함되어, BFF가 활성 세션이 있는지 확인할 수 있게 한다. 응답은 세션이 활성 상태인지 여부를 브라우저 기반 애플리케이션에 표시해야 한다. 또한 BFF는 인증된 사용자에 대한 신원 정보와 같은 다른 정보를 포함할 수 있다.¶

Authorization Code 흐름을 시작하는 엔드포인트 (C 단계)는 브라우저가 내비게이션을 통해 접촉한다. 애플리케이션이 세션을 확인한 뒤(B 단계) 인증되지 않은 상태를 감지하면, 브라우저를 이 엔드포인트로 이동시킬 수 있다. 이렇게 하면 BFF가 리디렉션으로 응답하여 브라우저를 권한 부여 서버로 이동시킬 수 있다. 이 흐름을 시작하는 엔드포인트는 일반적으로 웹 서버에서 실행되는 기밀 클라이언트용 OAuth 2.0을 지원하는 라이브러리에서 "login" 엔드포인트로 포함된다. BFF가 활성 세션이 없음을 감지했을 때 B 단계에서 Authorization Code 흐름을 시작할 수도 있다는 점에 유의한다. 이 경우 BFF는 응답에 권한 부여 URI를 반환하고, 애플리케이션이 이 URI로 내비게이션 이벤트를 트리거하기를 기대한다. 그러나 이 시나리오는 사용자 지정 구현이 필요하며 표준 OAuth 라이브러리를 사용하기 더 어렵게 만든다.¶

권한 부여 코드를 수신하는 엔드포인트(E 단계)는 브라우저 내부의 내비게이션 이벤트에 의해 호출된다. 이 시점에서 애플리케이션은 로드되어 있지 않으며 리디렉션을 처리할 위치에 있지 않다. 흐름 시작과 유사하게, 리디렉션을 처리하는 엔드포인트는 표준 OAuth 라이브러리에서 제공된다. BFF는 애플리케이션을 로드하도록 브라우저를 트리거하는 리디렉션으로 이 요청에 응답할 수 있다.¶

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

6.1.2.2. 갱신 토큰

[RFC9700]의 4.14절에 설명된 것처럼 갱신 토큰을 사용할 때, BFF는 갱신 토큰(F 단계)을 획득하고 이를 사용자의 세션과 연결한다.¶

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

갱신 토큰이 만료되면, 완전히 새로운 Authorization Code 흐름을 실행하지 않고는 유효한 접근 토큰을 얻을 방법이 없다. 따라서 BFF가 관리하는 쿠키 기반 세션의 수명을 갱신 토큰의 최대 수명과 같게 구성하는 것이 타당하다. 또한 BFF가 활성 세션의 갱신 토큰이 더 이상 유효하지 않음을 알게 되면, 세션도 무효화하는 것이 타당하다.¶

6.1.2.3. 쿠키 기반 세션 상태

BFF는 사용자의 토큰에 접근하는 데 사용되는 사용자의 세션을 추적하기 위해 브라우저 쿠키([I-D.ietf-httpbis-rfc6265bis])에 의존한다. 서버 측 및 클라이언트 측 쿠키 기반 세션에는 몇 가지 단점이 있다.¶

서버 측 세션은 세션 식별자만 노출하고 모든 데이터를 서버에 보관한다. 이렇게 하면 활성 세션에 대한 높은 수준의 제어와 원하는 시점에 어떤 세션이든 폐기할 수 있는 가능성이 보장된다. 이 접근 방식의 단점은 확장성에 미치는 영향이며, "sticky sessions" 또는 "session replication"과 같은 해결책이 필요하다. 이러한 단점을 고려할 때, 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 Token을 받는다. BFF는 ID Token의 정보를 사용자의 세션과 연결하고 이를 B 단계 또는 I 단계에서 애플리케이션에 제공할 수 있다.¶

필요할 때 BFF는 사용자의 세션과 연결된 접근 토큰을 사용하여 UserInfo 엔드포인트로 요청을 보낼 수 있다.¶

6.1.2.5. 실용적 배포 전략

정적 JavaScript 코드를 제공하는 것은 OAuth 토큰 처리 및 요청 전달과 별도의 책임이다. 위에 제시된 그림에서 BFF와 정적 웹 호스트는 두 개의 별도 엔티티로 표시된다. 실제 배포에서는 이러한 구성 요소가 단일 서비스(즉, BFF가 정적 JS 코드를 제공), 두 개의 별도 서비스(즉, CDN과 BFF), 또는 단일 서비스 내 두 구성 요소 (즉, 클라우드 플랫폼의 정적 호스팅과 서버리스 함수)로 배포될 수 있다.¶

특정 시나리오에 맞추기 위해 이 아키텍처를 더 사용자 지정할 수 있다는 점에 유의한다. 예를 들어, 내부 및 외부 리소스 서버 모두에 의존하는 애플리케이션은 내부 리소스 서버를 BFF와 함께 호스팅하도록 선택할 수 있다. 이 시나리오에서 내부 리소스 서버로의 요청은 네트워크를 통해 요청을 전달할 필요 없이 BFF에서 직접 처리된다. 리소스 서버의 관점에서 권한 부여는 변하지 않으며, 사용자의 세션은 내부적으로 접근 토큰과 그 클레임으로 변환된다.¶

6.1.3.1. Authorization Code 권한 부여

BFF를 사용하는 주요 이점은 BFF가 기밀 클라이언트로 동작할 수 있는 능력이다. 따라서 BFF는 권한 부여 서버와 자격 증명을 설정하여 기밀 클라이언트로 동작해야 한다(MUST). 또한 BFF는 접근 토큰 요청을 시작하기 위해 [RFC9700]의 2.1.1절에 설명된 OAuth 2.0 Authorization Code 권한 부여를 사용해야 한다(MUST).¶

6.1.3.2. 쿠키 보안

BFF는 사용자 세션을 만들기 위해 쿠키를 사용하며, 이 세션은 서버 측 또는 클라이언트 측 세션 상태를 통해 사용자의 토큰과 직접 연결된다. 이러한 쿠키의 민감한 특성을 고려할 때, 쿠키는 적절히 보호되어야 한다.¶

다음 쿠키 보안 지침은 이 특정 BFF 아키텍처와 관련이 있다:¶

• BFF는 쿠키에 대해 Secure 플래그를 활성화해야 한다(MUST)¶

• BFF는 쿠키에 대해 HttpOnly 플래그를 활성화해야 한다(MUST)¶

• BFF는 쿠키에 대해 SameSite=Strict 플래그를 활성화하는 것이 좋다(SHOULD)¶

• BFF는 쿠키 경로를 /로 설정하는 것이 좋다(SHOULD)¶

• BFF는 쿠키에 Domain 속성을 설정하지 않는 것이 좋다(SHOULD NOT)¶

• BFF는 쿠키 이름을 __Host 접두사([I-D.ietf-httpbis-rfc6265bis])로 시작하는 것이 좋다(SHOULD)¶

참고: 새 배포에서는 위의 모든 요구 사항을 구현하기가 대체로 간단할 가능성이 높다. "SHOULD" 항목이 "MUST"가 아닌 유일한 이유는 기존 아키텍처도 준수할 수 있도록 하기 위해서이다. 이러한 요구 사항의 함의는 아래에 나열되어 있다.¶

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

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

쿠키 보안 모범 사례에 대한 추가 지침은 OWASP Cheat Sheet 시리즈([OWASPCheatSheet])를 참조한다.¶

6.1.3.3. 교차 사이트 요청 위조 보호

브라우저 기반 애플리케이션과 BFF 사이의 상호 작용은 인증 및 권한 부여를 위해 쿠키에 의존한다. 다른 쿠키 기반 상호 작용과 유사하게, BFF는 Cross-Site Request Forgery (CSRF) 공격을 고려해야 한다. 성공적인 CSRF 공격은 공격자의 BFF 요청이 보호된 리소스로 나가는 호출을 트리거하도록 허용할 수 있다.¶

BFF는 적절한 CSRF 방어를 구현해야 한다(MUST). 정확한 메커니즘 또는 메커니즘의 조합은 아래에서 논의한 것처럼 BFF가 배포된 정확한 도메인에 따라 달라진다.¶

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

BFF 패턴은 브라우저 기반 애플리케이션이 리소스 서버로 보내는 모든 요청을 백엔드 BFF 구성 요소를 통해 전달하도록 요구한다. 그 결과 BFF 구성 요소는 애플리케이션과 리소스 서버 사이의 모든 요청과 응답을 관찰할 수 있으며, 이는 상당한 개인정보 보호 영향을 가질 수 있다.¶

브라우저 기반 애플리케이션과 BFF가 같은 당사자에 의해 구축되고 배포되는 경우, 개인정보 보호 영향은 대체로 미미할 가능성이 높다. 그러나 이 패턴이 제3자가 제공하거나 호스팅하는 BFF 구성 요소를 사용하여 구현되는 경우, 이러한 개인정보 보호 영향을 고려해야 한다.¶

6.1.3.5. 운영 고려 사항

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

6.1.3.6. 프록시 제한

BFF는 프런트엔드의 요청을 수락하고 리소스 서버로 전달함으로써 프록시 서비스로 동작한다. 들어오는 요청은 쿠키를 포함하며, BFF는 이를 나가는 요청의 접근 토큰으로 변환한다. (이는 HTTP 프록시라기보다 애플리케이션 계층 리버스 프록시에 더 가깝다는 점에 유의한다.) CSRF 공격 외에도, 공격자는 BFF를 조작하여 의도하지 않은 호스트로 요청을 전달하게 하려 시도할 수 있다. 공격자가 이를 성공적으로 악용하면, BFF를 임의의 서버로 리디렉션하여 사용자의 접근 토큰을 잠재적으로 노출할 수 있다.¶

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

동적으로 구성 가능한 프록시를 구현할 때, BFF는 명시적으로 허용된 호스트와 경로에 대한 요청만 허용하도록 보장해야 한다(MUST). 이러한 제한을 강제하지 못하면 무단 접근과 접근 토큰 유출로 이어질 수 있다.¶

6.1.3.7. 고급 보안

BFF 패턴에서는 모든 OAuth 책임이 기밀 클라이언트로 동작하는 서버 측 구성 요소인 BFF로 이동되었다. 서버 측 애플리케이션은 브라우저 기반 애플리케이션보다 더 통제된 환경에서 실행되므로, 고급 OAuth 보안 관행을 채택하기가 더 쉬워진다. 예에는 키 기반 클라이언트 인증 및 송신자 제한 토큰이 포함된다.¶

6.1.4.1. 공격 시나리오 및 결과

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

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

이 공격 시나리오는 다음 결과로 이어진다는 점에 유의한다:¶

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

클라이언트 하이재킹은 브라우저 기반 애플리케이션의 본질에 내재한 공격 시나리오라는 점에 유의한다. 따라서 애초에 악성 코드 실행을 막는 것 외에는 이러한 공격을 방지할 수 있는 것이 없다. 이를 달성하는 데 도움이 되는 기법으로는 보안 코딩 지침 준수, 코드 분석, Content Security Policy([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" 엔드포인트(위 그림의 B 및 I 단계)는 브라우저 기반 애플리케이션이 호출하는 API 엔드포인트이다. 요청에는 사용 가능한 경우 세션 정보가 포함되어, 백엔드가 활성 세션이 있는지 확인할 수 있게 한다. 응답은 세션이 활성 상태인지 여부를 브라우저 기반 애플리케이션에 표시해야 한다. 활성 세션이 발견되면, 백엔드는 응답에 접근 토큰을 포함한다. 또한 백엔드는 인증된 사용자에 대한 신원 정보와 같은 다른 정보를 포함할 수 있다.¶

• Authorization Code 흐름을 시작하는 엔드포인트 (C 단계)는 BFF 아키텍처에 대해 설명한 엔드포인트와 동일하다. 자세한 내용은 6.1.2.1절을 참조한다.¶

• 권한 부여 코드를 수신하는 엔드포인트 (E 단계)는 BFF 아키텍처에 대해 설명한 엔드포인트와 동일하다. 자세한 내용은 6.1.2.1절을 참조한다.¶

• logout을 지원하는 엔드포인트는 BFF 아키텍처에 대해 설명한 엔드포인트와 동일하다. 자세한 내용은 6.1.2.1절을 참조한다.¶

6.2.2.2. 갱신 토큰

[RFC9700]의 4.14절에 설명된 것처럼 갱신 토큰을 사용할 때, 토큰 중개 백엔드는 F 단계에서 갱신 토큰을 획득하고 이를 사용자의 세션과 연결한다.¶

리소스 서버가 접근 토큰을 거부하면, 애플리케이션은 토큰 중개 백엔드에 연락하여 새 접근 토큰을 요청할 수 있다. 토큰 중개 백엔드는 이 요청과 연결된 쿠키에 의존하여 사용자의 갱신 토큰을 조회하고, 갱신 토큰을 사용하여 토큰 요청을 한다. 이러한 단계는 그림에 표시되어 있지 않다. 이 Refresh Token 요청은 기밀 클라이언트인 백엔드에서 이루어지므로 클라이언트 인증이 필요하다는 점에 유의한다.¶

갱신 토큰이 만료되면, 완전히 새로운 Authorization Code 권한 부여를 시작하지 않고는 유효한 접근 토큰을 얻을 방법이 없다. 따라서 그러한 정보를 사전에 알고 있다면 쿠키 기반 세션의 수명을 갱신 토큰의 최대 수명과 같게 구성하는 것이 타당하다. 또한 토큰 중개 백엔드가 활성 세션의 갱신 토큰이 더 이상 유효하지 않음을 알게 되면, 세션을 무효화하는 것이 타당하다.¶

6.2.2.3. 접근 토큰 범위

접근하는 리소스 서버와 권한 부여 서버의 범위 구성에 따라, 애플리케이션은 서로 다른 범위 구성을 가진 접근 토큰을 요청하기를 원할 수 있다. 이 동작은 애플리케이션이 최소 범위의 접근 토큰을 사용하는 모범 사례를 따를 수 있게 한다.¶

애플리케이션은 활성 세션을 확인할 때(단계 A/I) 원하는 범위를 토큰 중개 백엔드에 알릴 수 있다. 이전에 획득한 접근 토큰이 원하는 범위 기준에 들어맞는지 결정하는 것은 토큰 중개 백엔드의 책임이다.¶

이 접근 토큰 캐싱 메커니즘이 토큰 중개 백엔드에서 무분별하게 적용되면 범위 상승 위험을 유발할 수 있다는 점에 유의해야 한다. 캐시된 접근 토큰이 프런트엔드가 요청한 범위의 상위 집합을 포함하는 경우, 토큰 중개 백엔드는 이를 프런트엔드에 반환하지 않는 것이 좋다(SHOULD NOT). 대신 갱신 토큰을 사용하여 권한 부여 서버에서 더 작은 범위 집합을 가진 접근 토큰을 요청하는 것이 좋다(SHOULD). 이러한 접근 토큰 downscoping 메커니즘의 지원은 권한 부여 서버의 재량에 따른다는 점에 유의한다.¶

토큰 중개 백엔드는 특정 리소스 서버에 대한 접근 토큰을 얻기 위해 [RFC8707]에 의존할 때, downscoping과 유사한 메커니즘을 사용할 수 있다.¶

6.2.2.4. 쿠키 기반 세션 상태

BFF와 유사하게, 토큰 중개 백엔드는 사용자의 세션을 추적하기 위해 브라우저 쿠키에 의존한다. BFF와 동일한 구현 지침 및 보안 고려 사항이 적용되며, 이는 6.1.2.3절에서 논의된다.¶

6.2.2.5. OAuth와 OpenID Connect 결합

BFF와 유사하게, 토큰 중개 백엔드는 OAuth와 OpenID Connect를 단일 흐름으로 결합하도록 선택할 수 있다. 자세한 내용은 6.1.2.4절을 참조한다.¶

6.2.2.6. 실용적 배포 시나리오

정적 JavaScript 또는 WASM 코드를 제공하는 것은 권한 부여 서버와의 상호 작용을 처리하는 것과 별도의 책임이다. 위에 제시된 그림에서 토큰 중개 백엔드와 정적 웹 호스트는 두 개의 별도 엔티티로 표시된다. 실제 배포 시나리오에서 이러한 구성 요소는 단일 서비스(즉, 토큰 중개 백엔드가 정적 코드를 제공), 두 개의 별도 서비스(즉, CDN과 토큰 중개 백엔드), 또는 단일 서비스 내 두 구성 요소(즉, 클라우드 플랫폼의 정적 호스팅과 서버리스 함수)로 배포될 수 있다. 이러한 배포 차이는 이 패턴에서 설명한 관계에 영향을 주지 않지만, cross-origin 통신을 가능하게 하기 위해 CORS를 적절히 구성해야 하는 필요성과 같은 다른 실무적 사항에는 영향을 줄 수 있다.¶

6.2.3.1. Authorization Code 권한 부여

토큰 중개 백엔드를 사용하는 주요 이점은 백엔드가 기밀 클라이언트로 동작할 수 있는 능력이다. 따라서 토큰 중개 백엔드는 기밀 클라이언트로 동작해야 한다(MUST). 또한 토큰 중개 백엔드는 접근 토큰 요청을 시작하기 위해 [RFC9700]의 2.1.1절에 설명된 OAuth 2.0 Authorization Code 권한 부여를 사용해야 한다(MUST).¶

6.2.3.2. 쿠키 보안

토큰 중개 백엔드는 사용자 세션을 만들기 위해 쿠키를 사용하며, 이 세션은 서버 측 또는 클라이언트 측 세션 상태를 통해 사용자의 토큰과 직접 연결된다. BFF와 동일한 쿠키 보안 지침이 적용되며, 이는 6.1.3.2절에서 논의된다.¶

6.2.3.3. 교차 사이트 요청 위조 보호

브라우저 기반 애플리케이션과 토큰 중개 백엔드 사이의 상호 작용은 인증 및 권한 부여를 위해 쿠키에 의존한다. BFF와 마찬가지로, 토큰 중개 백엔드는 Cross-Site Request Forgery (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. Authorization Code 권한 부여

공개 클라이언트인 브라우저 기반 애플리케이션은 접근 토큰을 얻을 때 Proof Key for Code Exchange (PKCE [RFC7636]) 확장을 구현해야 하며(MUST), 권한 부여 서버는 이러한 클라이언트를 위해 PKCE를 지원하고 강제해야 한다(MUST).¶

PKCE 확장은 권한 부여 코드가 가로채여 악성 클라이언트에 의해 접근 토큰으로 교환되는 공격을 방지한다. 이는 권한 부여 코드를 교환하는 클라이언트 인스턴스가 흐름을 시작한 동일한 인스턴스인지 권한 부여 서버가 확인할 수 있는 방법을 제공함으로써 이루어진다.¶

6.3.2.2. 교차 사이트 요청 위조 보호

브라우저 기반 애플리케이션은 redirect URI에 대한 CSRF 공격을 방지해야 한다(MUST). 이는 아래 중 하나로 달성할 수 있다:¶

• 이 클라이언트에 대해 PKCE를 요구하도록 권한 부여 서버를 구성하기¶

• CSRF 토큰을 전달하기 위해 OAuth state 매개변수에 고유 값을 사용하고 검증하기¶

• 애플리케이션이 OpenID Connect도 사용하는 경우, [OpenID]에 설명된 대로 OpenID Connect nonce 매개변수를 사용하고 검증하기¶

Authorization Code 흐름을 위한 적절한 CSRF 방어를 선택하는 데 대한 추가 세부 사항은 [RFC9700]의 2.1절을 참조한다.¶

6.3.2.3. 갱신 토큰

브라우저 기반 클라이언트의 경우, 애플리케이션이 명시적으로 DPoP [RFC9449]를 사용하지 않는 한, 갱신 토큰은 일반적으로 bearer token이다. 그 결과, 유출된 갱신 토큰의 위험은 유출된 접근 토큰보다 더 크다. 공격자가 훔친 갱신 토큰을 사용하여 권한 부여 서버에 탐지되지 않을 가능성이 있는 상태로 새 접근 토큰을 계속 얻을 수 있기 때문이다.¶

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

특히 권한 부여 서버는 다음을 수행해야 한다:¶

• 각 사용 시 갱신 토큰을 회전시키거나, [RFC9700]의 4.14.2절에 설명된 송신자 제한 갱신 토큰을 사용해야 한다(MUST)¶

• 갱신 토큰에 최대 수명을 설정하거나, 갱신 토큰이 일정 시간 동안 사용되지 않은 경우 만료되도록 해야 한다(MUST)¶

• 회전된 갱신 토큰을 발급할 때, 갱신 토큰에 사전 설정된 만료 시간이 있는 경우, 새 갱신 토큰의 수명을 초기 갱신 토큰의 수명을 넘어 연장해서는 안 된다(MUST NOT)¶

전체 갱신 토큰 수명을 초기 갱신 토큰의 수명으로 제한하면, 훔친 갱신 토큰이 무기한 사용될 수 없도록 보장한다.¶

예를 들면 다음과 같다:¶

• 사용자가 애플리케이션을 승인하여, 10분 동안 지속되는 접근 토큰과 8시간 동안 지속되는 갱신 토큰이 발급된다¶

• 10분 후 초기 접근 토큰이 만료되므로, 애플리케이션은 갱신 토큰을 사용하여 새 접근 토큰을 얻는다¶

• 권한 부여 서버는 10분 동안 지속되는 새 접근 토큰과 7시간 50분 동안 지속되는 새 갱신 토큰을 반환한다¶

• 이는 초기 권한 부여 시점부터 8시간이 지날 때까지 계속된다¶

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

권한 부여 서버는 갱신 토큰의 수명을 권한 부여 서버와의 사용자의 인증된 세션에 연결하는 것이 좋다(SHOULD). 이렇게 하면 사용자가 로그아웃할 때, 브라우저 기반 애플리케이션에 이전에 발급된 갱신 토큰이 무효화되어 단일 로그아웃 시나리오를 모방한다. 권한 부여 서버는 다른 공개 클라이언트와 비교하여 브라우저 기반 애플리케이션에 대해 갱신 토큰 발급, 수명 및 만료에 관한 서로 다른 정책을 설정할 수 있다(MAY).¶

6.3.3.1. 클라이언트 인증

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

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

SPA 클라이언트에 정적으로 포함된 공유 비밀을 여전히 요구하는 권한 부여 서버는 클라이언트를 공개 클라이언트로 취급해야 하며(MUST), 그 비밀을 클라이언트 신원의 증명으로 받아들여서는 안 된다. 추가 조치가 없다면 이러한 클라이언트는 클라이언트 가장(아래 6.3.3.2절 참조)에 취약하다.¶

6.3.3.2. 클라이언트 가장

[RFC6749]의 10.2절에 명시된 것처럼, 권한 부여 서버는 클라이언트 애플리케이션의 신원을 보장할 수 있는 경우를 제외하고, 사용자 동의 또는 상호 작용 없이 권한 부여 요청을 자동으로 처리하지 않는 것이 좋다(SHOULD NOT).¶

권한 부여 서버가 redirect URI를 고정된 절대 HTTPS URI 집합으로 제한하여 와일드카드 도메인, 와일드카드 경로 또는 와일드카드 query string 구성 요소의 사용을 방지하는 경우, 등록된 절대 HTTPS URI의 정확한 일치는 client_id에 대한 이전 요청이 이미 승인된 경우 권한 부여 요청을 자동으로 처리할지 결정하기 위한 클라이언트의 신원 증명으로 권한 부여 서버에 의해 받아들여질 수 있다(MAY).¶

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

브라우저 기반 애플리케이션에서는 기본 창을 리디렉션하는 대신 팝업이나 iframe과 같은 보조 창에서 OAuth 흐름을 실행하는 것이 일반적이다. 이러한 흐름에서 브라우저 기반 앱은 예를 들어 페이지 새로고침을 피하거나 프레임 기반 흐름을 조용히 실행하기 위해 기본 창의 제어를 유지한다.¶

브라우저 기반 앱과 권한 부여 서버가 서로 다른 프레임에서 호출되는 경우, top-level 리디렉션 대신 postMessage API(a.k.a. [WebMessaging])와 같은 브라우저 내 통신 기법을 사용해야 한다. 메시지의 기밀성과 진정성을 보장하기 위해, postMessage의 송신자 origin과 수신자 origin은 postMessage API가 본질적으로 제공하는 메커니즘([WebMessaging]의 9.3.2절)을 사용하여 모두 검증해야 한다(MUST).¶

[RFC9700]의 4.18절은 브라우저 내 통신 흐름의 보안과 이러한 공격을 방어하기 위해 브라우저 기반 애플리케이션 및 권한 부여 서버가 적용해야 하는(MUST) 대응책에 대한 추가 세부 사항을 제공한다.¶

6.3.3.4. Cross-Origin 요청

이 시나리오에서 애플리케이션은 브라우저 API를 사용하여 권한 부여 서버와 리소스 서버로 요청을 보낸다. OAuth 2.0의 특성상 이러한 요청은 일반적으로 cross-origin이며, 브라우저가 강제하는 cross-origin 통신 제한의 대상이 된다. 권한 부여 서버와 리소스 서버는 애플리케이션이 필요한 cross-origin 요청을 할 수 있도록 필요한 CORS 헤더([Fetch]에 정의됨)를 보내야 한다(MUST). 브라우저 기반 OAuth 클라이언트가 권한 부여 서버 또는 리소스 서버와 동일한 출처에서 실행되는 이례적인 시나리오에서는, 필요한 상호 작용을 가능하게 하기 위해 CORS 정책이 필요하지 않다는 점에 유의한다.¶

권한 부여 서버의 경우, CORS 구성은 브라우저 기반 애플리케이션이 권한 부여 코드를 토큰으로 교환하는 토큰 엔드포인트와 관련이 있다. 또한 권한 부여 서버가 discovery metadata URL, JSON Web Key Sets, dynamic client registration, revocation, introspection 또는 user info 엔드포인트와 같은 추가 엔드포인트를 애플리케이션에 제공하는 경우, 이러한 엔드포인트도 브라우저 기반 애플리케이션에서 접근될 수 있다. 따라서 권한 부여 서버는 이러한 엔드포인트에서 CORS를 지원할 책임이 있다.¶

이 명세는 구체적인 CORS 정책 구현을 결정하기 위한 지침을 포함하지 않는다. 이는 와일드카드 origin 또는 더 제한적인 구성으로 이루어질 수 있다. CORS에는 서로 다른 보안 속성을 가진 두 가지 동작 모드가 있다는 점에 유의한다. 첫 번째 모드는 이전에 simple requests로 알려진 CORS-safelisted 요청에 적용되며, 브라우저는 요청을 보내고 CORS 응답 헤더를 사용하여 응답을 클라이언트 측 실행 컨텍스트에 노출할 수 있는지 결정한다. 사용자 지정 요청 헤더가 있는 요청과 같은 non-CORS-safelisted 요청의 경우, 브라우저는 먼저 preflight를 사용하여 CORS 정책을 확인한다. 브라우저는 서버가 preflight 응답에서 승인을 보낼 때에만 실제 요청을 보낸다.¶

권한 부여 서버의 특정 구성 때문에, preflight에 대한 CORS 응답이 실제 요청에 대한 CORS 응답과 다를 수 있다는 점에 유의한다. preflight 동안 권한 부여 서버는 제공된 origin만 검증할 수 있지만, 실제 요청 동안에는 권한 부여 서버가 클라이언트 ID와 같은 전체 요청 데이터를 가진다. 따라서 권한 부여 서버는 preflight 중에는 알려진 origin을 승인할 수 있지만, 실제 요청에서는 origin을 이 특정 클라이언트의 사전 등록된 origin 목록과 비교한 뒤 거부할 수 있다.¶

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. Redirect URI の操作

攻撃者が認可レスポンスを自身の制御下にある URI へ 送信させることができる場合、 アクセストークンを含む認可レスポンスへ直接アクセスできます。 この攻撃を実行するいくつかの方法は、[RFC9700] で詳しく 説明されています。¶

7.2.3.2. ブラウザ履歴における アクセストークン漏えい

攻撃者はブラウザの履歴からアクセストークンを 取得できる可能性があります。 [RFC6819] によって推奨される対策は、 トークンに短い有効期限を使用すること、およびブラウザがレスポンスを キャッシュすべきでないことを示すことに限られます。 これらはいずれもこの攻撃を完全には防止せず、潜在的な被害を軽減するだけです。¶

さらに、多くのブラウザは現在、ブラウザ履歴を クラウドサービスや複数のデバイスにも同期しており、URL からアクセストークンを 抽出するためのさらに広い攻撃面を提供しています。¶

これは [RFC9700] の Section 4.3.2 で、より詳しく説明されています。¶

7.2.3.3. スクリプトの操作

攻撃者は、たとえば企業ネットワークによって ブラウザの HTTPS 接続が傍受されている場合など、さまざまな手段を通じて ページを変更したり、ブラウザへスクリプトを注入したりできる可能性があります。 TLS 層への攻撃は通常、防止のための基本的なセキュリティ推奨事項の範囲外ですが、 ブラウザベースのアプリケーションの場合、それらははるかに実行しやすくなります。 注入されたスクリプトにより、攻撃者はページ上のすべてにアクセスできるようになります。¶

アプリケーションがアクセストークンを取得する既知の 標準的な方法を使用する場合、ページ上で悪意あるスクリプトが実行されるリスクは 増幅される可能性があります。すなわち、攻撃者は常に window.location 変数を見てアクセストークンを見つけることができます。この脅威プロファイルは、 Authorization Code フローによって取得されたアクセストークンがどこに、 またはどのように保存され得るかを知ったうえで、個別のアプリケーションを 特に標的にする攻撃者とは異なります。¶

7.2.3.4. サードパーティ スクリプトへのアクセストークン漏えい

ブラウザベースのアプリケーションでは、 分析ツール、クラッシュレポート、さらにはソーシャルメディアの "like" ボタンのようなものなど、サードパーティスクリプトを使用することは比較的一般的です。 このような状況では、アプリケーションの作者は、アプリケーション内で実行される コード全体を完全には把握できない可能性があります。アクセストークンが fragment で 返される場合、それはページ上の任意のサードパーティスクリプトから見えます。¶

7.4.1.1. Service Worker への攻撃

Service Worker を使用することによる一見有望な セキュリティ上の利点は、そのセキュリティ上の制限についてより詳細な議論を 必要とします。関連する攻撃シナリオ（Section 5.1）から アプリケーションを完全に保護するために、Service Worker は 2 つのセキュリティ要件を 満たす必要があります。¶

1. 攻撃者がトークンを流出させることを防ぐ¶

2. 攻撃者が新しいトークンセットを 取得することを防ぐ¶

登録されると、Service Worker は Authorization Code フローを実行し、トークンを取得します。Service Worker は自身の分離された 実行環境内でトークンを追跡するため、潜在的に悪意あるコードを含むいかなる アプリケーションコードからもそれらに手が届きません。その結果、Service Worker は トークン流出を防ぐという最初の要件を満たします。これは、Section 5.1 で説明した 最初の 2 つの攻撃シナリオを本質的に無力化します。¶

2 つ目のセキュリティ要件を満たすためには、 Service Worker は、正当なアプリケーションを制御する攻撃者が新しい Authorization Code grant を実行できないことを保証できなければなりません。 これは Section 5.1.3 で 議論される攻撃です。Service Workers の性質上、登録された Service Worker は、 そのような新しいフローを開始するすべての送信リクエストを、frame や新しい window で 発生する場合であってもブロックできます。¶

しかし、アプリケーション内で実行されている悪意あるコードは、 この Service Worker の登録を解除できます。Service Worker の登録解除は アプリケーションに大きな機能的影響を与える可能性があるため、ブラウザが軽く扱う 操作ではありません。したがって、登録解除された Service Worker はそのように マークされますが、現在実行中のすべてのインスタンスは、対応する browsing context が 終了するまで（例: タブやウィンドウを閉じるまで）アクティブなままです。 そのため、攻撃者が Service Worker の登録を解除しても、それはアクティブなままであり、 攻撃者が認可サーバーに到達することを防止できます。¶

Service Worker の登録解除の結果の 1 つは、 新しい browsing context が開かれたときに、それが存在しないことです。 そのため、攻撃者がまず Service Worker の登録を解除し、その後 frame で新しい フローを開始すると、その frame の browsing context に関連付けられた Service Worker は存在しません。その結果、攻撃者は自身の新しい Authorization Code grant を実行し、frame の URL から認可コードを抽出し、それをトークンと 交換できるようになります。本質的に、Service Worker は 2 つ目のセキュリティ要件を 満たせず、攻撃者が新しいトークンセットを取得するシナリオ（Section 5.1.3）に対して脆弱なままとなります。¶

これらの欠点に加えて、Service Worker の登録と 維持のかなりの複雑さを考慮すると、このパターンは推奨されません。¶

最後に、Service Worker の使用自体は アプリケーションの攻撃面を増加させないことに注意してください。実際には、 Service Workers は、送信リクエストに OAuth アクセストークンを含めるサポートを 既存の legacy application に後付けするためによく使用されます。これらのシナリオにおける Service Worker は、アプリケーションのセキュリティ特性を変えるものではなく、 アプリケーションの開発と保守を単に簡素化するだけです。¶