OAuth 2.0은 사용자가 자신의 핵심 계정 비밀번호를 제3의 애플리케이션에 직접 노출하지 않으면서, 특정 서비스의 제한된 기능에 접근할 수 있도록 ‘권한(Authorization)’을 위임하는 표준 프로토콜입니다. 최근의 보안 환경 변화에 따라, 단순히 인증하는 것을 넘어 어떤 방식으로 권한을 획득하고 관리하는지가 핵심이 되었습니다. 이 가이드는 OAuth 2.0의 기본 원리와 현재 업계에서 필수로 고려해야 할 최신 보안 트렌드를 명확하게 설명합니다.
OAuth 2.0이란 무엇이며, 왜 권한 위임이 필요한가?
OAuth 2.0은 사용자 인증(Authentication) 자체를 목표로 하는 것이 아니라, ‘인가(Authorization)’ 과정을 표준화하는 프레임워크입니다. 여기서 권한 위임 메커니즘이 필요한 근본적인 이유는 사용자 비밀번호를 제3자 애플리케이션에 직접 제공하는 것이 보안상 극도의 위험을 초래하기 때문입니다.
예를 들어, 사용자가 자신의 주요 계정 비밀번호를 특정 기능을 가진 앱에 입력하는 순간, 해당 앱이 해킹당하면 사용자의 모든 계정이 위험에 처할 수 있습니다. OAuth 2.0은 이러한 위험을 회피하기 위해, 비밀번호 대신 ‘토큰’이라는 범위가 제한된 접근 권한만을 부여하는 방식을 채택합니다.
OAuth 2.0의 네 가지 핵심 주체 이해하기
이 시스템은 네 가지 핵심 역할을 수행하는 주체들로 구성되어 역할 분리를 통해 보안성을 극대화합니다.
- Resource Owner (자원 소유자): 접근 권한을 가진 최종 사용자 본인을 의미합니다. 자신이 소유한 자원(사진, 연락처, 데이터 등)에 대한 통제권을 가집니다.
- Client (클라이언트): 자원에 접근하고자 하는 애플리케이션(예: 웹사이트, 모바일 앱)입니다.
- Authorization Server (인가 서버): 사용자의 신원을 확인하고, 접근 권한을 검증한 후, 제한된 토큰을 발급하는 중앙 권한 관리 서버입니다.
- Resource Server (자원 서버): 실제로 보호되어 접근이 제한된 자원(API 엔드포인트)을 보유하고 제공하는 서버입니다.
이러한 역할 분리는 애플리케이션이 사용자 비밀번호 전체를 얻는 대신, 오직 정해진 범위의 접근 권한만을 얻게 하여 보안성을 비약적으로 강화합니다.
OAuth 2.0의 핵심 동작 원리: 권장 흐름과 PKCE의 역할
OAuth 2.0에서 가장 안전하고 현재 업계에서 가장 권장되는 인증 흐름은 ‘Authorization Code Flow’입니다. 여기에 최신 보안 기술인 PKCE(Proof Key for Code Exchange)가 결합되면서, 특히 SPA(Single Page Application)나 모바일 앱 환경에서 발생할 수 있는 보안 취약점이 크게 감소했습니다.
PKCE는 클라이언트가 요청 시 임의의 비밀 키를 생성하고 이를 인증 과정에 추가하여, 중간에 인증 코드가 탈취되더라도 공격자가 최종 토큰을 획득하는 것을 원천적으로 차단하는 메커니즘입니다.
PKCE 기반의 인증 코드 교환 6단계 프로세스
PKCE를 이용한 인증 과정은 다음과 같은 정교한 단계로 이루어집니다.
- 챌린지 생성: 클라이언트가 무작위 문자열인
code_verifier를 생성하고, 이를 해시 함수를 거쳐code_challenge를 만듭니다. - 인가 요청: 클라이언트는 이
code_challenge를 포함하여 사용자를 로그인 페이지로 리디렉션합니다. - 사용자 동의 및 코드 획득: 사용자가 로그인하고 권한을 부여하면, 서버는 일회성 코드를 발급합니다.
- 토큰 요청: 클라이언트는 발급받은 코드를 가지고 토큰 발급 엔드포인트에 요청합니다.
- 검증 및 발급: 서버는 요청된 코드와 함께 처음 생성했던 비밀 정보를 검증하고, 최종 액세스 토큰을 발급합니다.
최신 보안 트렌드: 토큰 관리와 흐름
최신 보안 트렌드는 단순히 토큰을 받는 것에서 그치지 않고, 어떻게 토큰을 관리하고 사용하는지에 초점을 맞춥니다.
1. 토큰 흐름의 이해 (Access Token vs. Refresh Token)
- 액세스 토큰 (Access Token): 실제 API 호출에 사용되는 임시 토큰입니다. 보안상의 이유로 만료 시간이 매우 짧게 설정됩니다.
- 리프레시 토큰 (Refresh Token): 액세스 토큰이 만료되었을 때, 사용자에게 재로그인을 요구하지 않고 새로운 액세스 토큰을 발급받는 데 사용되는 장기 토큰입니다.
2. 토큰 탈취 방지 전략
- Scope 기반 접근: API 요청 시 필요한 최소한의 권한(Scope)만 요청하도록 제한합니다.
- 상황별 토큰 사용: 장기간 유효한 토큰을 클라이언트 저장소에 저장하는 대신, 서버 측에서 관리하는 것이 가장 안전합니다.
요약: 개발자가 기억해야 할 핵심 사항
| 개념 | 목적 | 핵심 보안 고려 사항 |
| :— | :— | :— |
| PKCE (Proof Key for Code Exchange) | OAuth 2.0의 보안 강화. 코드 교환 과정에서 토큰 탈취를 방지. | 반드시 클라이언트 측에서 적용해야 하는 최신 표준입니다. |
| Scope | 서비스 간의 권한 범위를 최소화. | 필요한 권한만 요청하도록 설계해야 합니다. |
| Refresh Token | 사용자 경험 유지(재로그인 방지). | 탈취 시 피해가 크므로, 재발급 시마다 서버에서 검증해야 합니다. |