SPA(Single Page Application) 환경에서 OAuth 인증을 사용할 때, 가장 큰 보안 위협은 인가코드(Authorization Code)가 중간에 가로채여 토큰 탈취로 이어지는 것입니다. 이 문제를 해결하고 클라이언트 시크릿(Client Secret) 없이도 강력한 보안을 유지하는 가장 안전한 방법이 바로 PKCE(Proof Key for Code Exchange)를 도입하는 것입니다.
PKCE는 클라이언트가 임의로 생성한 비밀 난수(Code Verifier)를 이용해 서버와 일회성 해시값(Code Challenge)을 교환하고, 최종 토큰 요청 시 이 비밀 난수를 다시 제시하여 서버가 검증하는 과정을 통해, 인가코드 가로채기 공격을 근본적으로 차단합니다.
PKCE란 무엇인가: 공개 클라이언트 환경의 보안 표준
OAuth 2.0은 권한 위임(Delegation)을 위한 표준 프로토콜이지만, SPA나 모바일 앱과 같은 공개 클라이언트(Public Client) 환경에서는 클라이언트 시크릿(Client Secret)을 안전하게 보관할 서버 측 영역이 없습니다. 이로 인해 공격자가 인증 과정에서 인가코드를 가로채는 중간자 공격(MITM)에 취약했습니다.
PKCE(RFC 7636 기반)는 이러한 공개 클라이언트의 근본적인 취약점을 보완하기 위해 도입된 핵심 확장 기능입니다.
PKCE의 도입은 단순한 권장 사항을 넘어, 현재 OAuth 2.1 표준 및 주요 IDP(Identity Provider)의 업계 표준으로 자리 잡았습니다. PKCE는 클라이언트가 ‘나만 아는 임시 인증 키’를 인증 흐름에 추가하여, 공격자가 코드를 탈취하더라도 다음 단계인 토큰 교환 과정에서 인증 키가 없으므로 토큰을 발급받을 수 없도록 만듭니다.
PKCE 동작 원리: 8단계로 이해하는 공격 방어 메커니즘
PKCE의 동작 원리는 추가적인 비밀 키를 활용하여 인증 흐름의 각 단계를 다중으로 검증하는 정교한 과정입니다. 아래 8단계의 논리적 흐름을 이해하는 것이 핵심 보안 메커니즘을 파악하는 열쇠입니다.
- Code Verifier 생성 (Client Side): SPA가 인가 요청을 시작하기 직전, 클라이언트 측에서 암호학적 안전 난수인
code_verifier를 생성합니다. 이 값은 RFC 7636 표준에 따라 최소 256비트 엔트로피를 가져야 하며, 휘발성 저장소(예:sessionStorage)에 임시 저장하는 것이 권장됩니다. - Code Challenge 생성 (Client Side): 저장된
code_verifier를 SHA-256 알고리즘으로 해시 처리한 후, 이 해시값을code_challenge로 생성합니다. - 인가 요청 (Authorization Request): 클라이언트는 이
code_challenge와 함께 인가 서버에 사용자를 인증합니다. - 인가 코드 획득 (Authorization Code Grant): 사용자가 인증을 마치고 인가 코드를 받습니다. 이 코드는 여전히 공격자에게 노출될 수 있습니다.
- 토큰 교환 요청 (Token Exchange Request): 클라이언트는 이 인가 코드를 가지고 토큰 엔드포인트로 요청을 보낼 때, 원래의
code_challenge를 다시 함께 전송합니다. - 서버 검증 (Server Validation): 인가 서버는 전송된
code_challenge를 사용하여, 받은 인가 코드가 유효한지 검증하고 토큰을 발급합니다.
핵심: 공격자가 인가 코드를 가로채더라도, 토큰 교환 시 필요한 code_challenge가 없기 때문에 토큰을 탈취할 수 없습니다.
SPA 환경 구현 가이드 및 보안 고려사항
SPA(Single Page Application) 환경에서는 클라이언트 측에서 이 과정을 안전하게 처리하는 것이 중요합니다.
| 단계 | 구현 요소 | 보안 고려사항 |
| :— | :— | :— |
| 코드 저장 | 인가 코드(Authorization Code) | XSS 공격에 취약하므로, 클라이언트가 직접 토큰을 저장하는 방식(Local Storage)은 피해야 합니다. |
| 토큰 획득 | 토큰 교환 요청 | 반드시 HTTPS를 사용해야 하며, 백엔드 서버를 경유하여 토큰을 교환하는 백엔드 포털(Backend For Frontend, BFF) 패턴을 사용하는 것이 가장 안전합니다. |
| 최소 권한 | Scope 및 Claim | 필요한 최소한의 범위(Scope)만 요청하고, 토큰에 필요한 최소한의 권한(Claim)만 포함하도록 설계해야 합니다. |
요약 및 결론
SPA 환경에서 OAuth 2.0을 사용할 때, 단순히 인가 코드만 사용하는 것은 위험합니다. 반드시 code_challenge를 활용하는 PKCE(Proof Key for Code Exchange) 확장 기능을 적용해야 합니다. PKCE는 클라이언트가 인가 코드를 획득하는 과정과 토큰을 교환하는 과정 사이에 추가적인 증명(Proof)을 요구함으로써, 중간자 공격(Man-in-the-Middle) 및 인가 코드 가로채기 공격으로부터 애플리케이션을 보호하는 가장 효과적인 방법입니다.