모바일 애플리케이션(Mobile App)이나 SPA 환경에서 OAuth 인증을 성공적으로 구현하고 클라이언트 시크릿 없이 보안을 유지하려면, PKCE(Proof Key for Code Exchange) 프로토콜을 반드시 사용해야 합니다. 핵심은 클라이언트가 무작위 생성한 code_verifier를 SHA-256 해싱하여 code_challenge를 만들고, 이 값을 인가 요청 시 서버에 포함시키는 것입니다. 최종 토큰 교환 시에는 원본 code_verifier를 함께 제출하여 서버가 일치 여부를 검증하는 2단계 과정이 필수적입니다.
PKCE가 필수적인 이유: 공개 클라이언트 보안 문제
OAuth 2.0은 권한 부여 표준이지만, 전통적인 방식은 클라이언트가 신분을 증명하기 위해 client_secret을 사용해야 했습니다. 이 방식은 서버에 안전하게 비밀 키를 보관할 수 있는 백엔드 웹 애플리케이션(Confidential Client)에만 적합했습니다.
반면, 모바일 앱이나 싱글 페이지 애플리케이션(SPA)은 코드 형태로 배포되므로, 비밀 키를 안전하게 보관하는 것이 구조적으로 불가능합니다. 이러한 ‘공개 클라이언트(Public Client)’ 환경에서 비밀 키를 노출하는 것은 심각한 보안 취약점을 만듭니다.
PKCE는 이러한 보안적 한계를 극복하기 위해 설계된 메커니즘입니다. PKCE는 비밀 키(Secret) 공유 대신, 인증 과정 중에 일회성 암호화 증명 값을 주고받아 보안을 강화합니다. 이는 OAuth 2.1 드래프트에서 모든 클라이언트 유형에 필수로 요구되는 업계 표준 보안 기제입니다.
PKCE 작동 원리 이해: 코드 체인 생성 및 검증 흐름
PKCE의 작동 원리는 ‘일회성 비밀 값 생성 및 검증’이라는 명확한 흐름을 따릅니다. 이 메커니즘을 이해하는 것이 모바일 환경 구현의 핵심입니다.
1. code_verifier 생성:
클라이언트 측에서 43자에서 128자 사이의 임의의 문자열인 code_verifier를 생성합니다. 이 값은 인증 과정에서 절대 노출되어서는 안 되는 비밀 정보입니다.
2. code_challenge 생성:
생성된 code_verifier를 SHA-256 알고리즘으로 해싱(Hashing)합니다. 이 해시 값을 Base64URL로 인코딩하여 code_challenge를 얻습니다. 이 code_challenge가 바로 첫 번째 인가 요청 시 서버에 전송되는 값입니다.
3. 서버의 검증 과정:
사용자 인증 후, 클라이언트는 획득한 authorization_code와 함께 최초에 생성했던 code_verifier를 토큰 엔드포인트로 서버에 전송합니다. 서버는 이 code_verifier를 받아 내부적으로 동일한 해싱 및 인코딩 과정을 거쳐 code_challenge를 재계산합니다. 만약 재계산된 값이 최초 요청 시 받은 code_challenge와 일치할 경우에만, 서버는 최종 access_token을 발급합니다.
모바일 환경 OAuth 2.0 인증 코드 흐름 (Code Flow) 단계별 가이드
모바일 또는 SPA 환경에서 PKCE를 적용하여 토큰을 획득하는 전체 과정은 아래의 6단계 순서로 진행되어야 합니다. 이 순서를 따르는 것이 보안 강화를 위한 핵심입니다.
| 단계 | 주체 | 수행 내용 |
|---|---|---|
| 1. 준비 (Client) | 클라이언트 앱 | `code_challenge`와 `code_challenge_method`를 생성하여 인증 요청 시작. |
| 2. 인증 요청 (Client -> Server) | 클라이언트 앱 | 인증 서버에 `code_challenge`를 포함하여 사용자 인증 요청 전송. |
| 3. 코드 발급 (Server -> Client) | 인증 서버 | 성공 시, 일회성 `authorization_code`를 클라이언트에 발급. |
| 4. 토큰 교환 (Client -> Server) | 클라이언트 앱 | 발급받은 `authorization_code`와 함께 **원래의 `code_verifier`**를 서버에 전송. |
| 5. 토큰 발급 (Server -> Client) | 인증 서버 | `code_verifier`를 검증하고, 유효성 확인 후 `access_token`과 `refresh_token`을 발급. |
핵심 보안 고려 사항
- State 매개변수 사용: CSRF 공격 방지를 위해 인증 요청 시 반드시 예측 불가능한
state매개변수를 사용하고, 응답 시 검증해야 합니다. - Code Verifier/Challenge:
code_challenge를 통해 클라이언트가 요청을 시작했음을 증명하고,code_verifier를 통해 토큰 교환 시 요청의 주체가 변조되지 않았음을 보장합니다. - 토큰 관리: 발급된
refresh_token은 서버 측에서 안전하게 저장하고, 만료 시 재발급 로직을 통해 세션 관리를 해야 합니다.