JWT vs. OAuth 2.0
기본 개념
- JWT (JSON Web Token)
JWT는 당사자 간에 안전하게 정보를 JSON 객체로 전송하기 위한 컴팩트하고 자체 완결적인 방식이다. 이 정보는 디지털 서명되어 있어 신뢰할 수 있다. JWT는 주로 인증(Authentication)과 정보 교환을 위해 사용된다. - OAuth 2.0
OAuth 2.0은 사용자가 자신의 정보에 대한 접근 권한을 제3자 애플리케이션에 부여할 수 있게 해주는 인가(Authorization) 프레임워크이다. 사용자가 비밀번호를 공유하지 않고도 제한된 접근 권한을 제3자에게 제공할 수 있다.
주요 목적과 용도
JWT의 목적
- 사용자 인증(Authentication)
- 인증된 사용자 간의 정보 교환
- 서명된 토큰을 통한 정보의 무결성 검증
- Stateless 서버 아키텍처 구현
OAuth 2.0의 목적
- 제3자 애플리케이션에 대한 권한 부여(Authorization)
- 리소스 소유자를 대신한 제한된 접근 제공
- 서비스 간 안전한 권한 위임
- 다양한 애플리케이션 유형(웹, 모바일, IoT 등)에 대한 인가 흐름 제공
3. 작동 원리
JWT 작동 원리
- 사용자가 로그인하면 서버는 JWT를 생성한다.
- JWT는 헤더(알고리즘, 토큰 타입), 페이로드(클레임), 서명의 세 부분으로 구성된다.
- 이 토큰을 클라이언트에게 반환한다.
- 클라이언트는 이후 요청 시 이 토큰을 Authorization 헤더에 포함시킨다.
- 토큰을 검증하고 페이로드의 정보를 기반으로 요청을 처리한다.
OAuth 2.0 작동 원리
- 클라이언트 애플리케이션이 사용자에게 특정 리소스에 대한 권한을 요청한다.
- 사용자가 동의하면 인가 서버는 인가 코드를 발급한다.
- 클라이언트는 이 인가 코드를 사용하여 인가 서버에 액세스 토큰을 요청한다.
- 인가 서버는 액세스 토큰(및 선택적으로 리프레시 토큰)을 발급한다.
- 클라이언트는 이 액세스 토큰을 사용하여 리소스 서버에 보호된 리소스를 요청한다.
- 리소스 서버는 토큰을 검증하고 요청된 리소스를 제공한다.
주요 구성 요소
- JWT 구성 요소
- 헤더(Header): 토큰 타입과 사용된 서명 알고리즘 정보
- 페이로드(Payload): 등록된 클레임, 공개 클레임, 비공개 클레임 등 사용자와 추가 데이터를 포함
- 서명(Signature): 토큰의 무결성을 검증하기 위한 서명 부분
- OAuth 2.0 구성 요소
- 리소스 소유자(Resource Owner): 보호된 리소스에 대한 접근 권한을 부여할 수 있는 사용자
- 클라이언트(Client): 리소스 소유자의 리소스에 접근하려는 애플리케이션
- 리소스 서버(Resource Server): 보호된 리소스를 호스팅하는 서버
- 인가 서버(Authorization Server): 사용자 인증 후 토큰을 발급하는 서버
- 액세스 토큰(Access Token): 리소스 접근을 위한 자격 증명
- 리프레시 토큰(Refresh Token): 새로운 액세스 토큰을 얻기 위한 토큰
주요 차이점
- 목적과 기능
- JWT: 주로 인증과 정보 교환에 중점
- OAuth 2.0: 인가(권한 부여)에 중점
- 범위
- JWT: 토큰 형식과 서명 방법을 정의하는 표준
- OAuth 2.0: 전체 인가 프레임워크와 프로토콜 정의
- 복잡성
- JWT: 상대적으로 단순한 구조와 구현
- OAuth 2.0: 여러 흐름과 역할이 포함된 복잡한 프레임워크
- 토큰 내용
- JWT: 토큰 자체에 사용자 정보와 메타데이터를 포함
- OAuth 2.0: 액세스 토큰은 일반적으로 참조 토큰이지만, JWT 형식의 토큰을 사용할 수도 있음
- 상태 관리
- JWT: 일반적으로 상태 비저장(Stateless) 방식
- OAuth 2.0: 일반적으로 상태 저장(Stateful) 방식, 특히 리프레시 토큰 관리 시
사용 사례
- JWT 적합한 사용 사례
- 단일 도메인 내 사용자 인증
- 마이크로서비스 간 정보 전달
- 일회성 이메일 확인이나 비밀번호 재설정
- 상태 비저장 API 인증
- OAuth 2.0 적합한 사용 사례
- 소셜 로그인(페이스북, 구글 등을 통한 로그인)
- 제3자 애플리케이션 API 인가
- 여러 서비스 간의 권한 위임
- 사용자의 특정 리소스에 대한 제한된 접근 제공
장단점
JWT
- 장점
- 자체 포함적: 필요한 모든 정보를 토큰 자체에 포함
- 서버 부하 감소: 세션 저장소가 필요 없음
- 확장성: 분산 시스템에서 효율적
- 간단한 구현: 대부분의 프로그래밍 언어에서 지원
- 단점
- 토큰 크기: 클레임이 많을수록 토큰 크기 증가
- 보안 위험: 클라이언트에 저장된 정보는 탈취될 수 있음
- 토큰 무효화: 발급된 토큰을 즉시 무효화하기 어려움
- 상태 저장 불가: 로그아웃 등의 기능 구현이 복잡
OAuth 2.0
- 장점
- 높은 보안성: 사용자 자격 증명을 직접 공유하지 않음
- 세분화된 권한 부여: 특정 권한(scope)에 대해서만 접근 허용
- 다양한 인가 흐름: 다양한 클라이언트 유형에 적합한 흐름 제공
- 토큰 갱신 메커니즘: 리프레시 토큰을 통한 장기 접근 지원
- 단점
- 구현 복잡성: 전체 흐름 구현이 복잡함
- 다양한 해석: 명세의 유연성으로 인한 구현 차이
- 오버헤드: 여러 요청과 응답 교환이 필요
- 중앙화된 인가 서버: 단일 장애 지점이 될 수 있음
상호 관계
JWT와 OAuth 2.0은 경쟁 관계가 아니라 보완적인 관계에 있다. OAuth 2.0은 인가 프레임워크로, JWT는 토큰 형식으로 사용될 수 있다. 실제로 많은 OAuth 2.0 구현에서는 액세스 토큰과 ID 토큰으로 JWT 형식을 사용한다. 이러한 결합을 OpenID Connect(OIDC)라고 하며, OAuth 2.0을 확장하여 인증 레이어를 추가한 프로토콜이다.
JWT vs. OAuth 2.0
특성 | JWT | OAuth 2.0 |
---|---|---|
주요 목적 | 인증(Authentication) 및 정보 교환 | 인가(Authorization) 및 권한 위임 |
형태 | 토큰 형식 표준 | 인가 프레임워크 및 프로토콜 |
복잡성 | 상대적으로 단순 | 복잡한 여러 흐름 |
상태 관리 | Stateless (상태 비저장) | 일반적으로 Stateful (상태 저장) |
토큰 내용 | 자체 포함적 (사용자 정보 포함) | 일반적으로 참조 토큰 (JWT 사용 가능) |
토큰 유효성 | 서명을 통한 로컬 검증 | 인가 서버를 통한 검증 (일반적으로) |
토큰 취소 | 어려움 (블랙리스트 필요) | 상대적으로 쉬움 |
스케일링 | 높음 (서버에 상태 저장 안 함) | 중간 (토큰 저장소 필요) |
구현 난이도 | 낮음 | 높음 |
사용 사례 | 단일 서비스 인증, API 인증 | 소셜 로그인, API 인가, 서비스 간 권한 위임 |
클라이언트 타입 | 제한 없음 | 다양한 클라이언트별 흐름 제공 |
리소스 접근 | 직접적 (토큰 내 정보 사용) | 간접적 (토큰으로 리소스 서버 접근) |
토큰 갱신 | 기본 지원 없음 | 리프레시 토큰 지원 |
권한 범위 | 토큰 내 클레임으로 정의 | Scope 파라미터로 정의 |
표준화 | RFC 7519 | RFC 6749, RFC 6750 |
보안 강점 | 무결성 보장 (서명) | 자격 증명 비공개 (권한 위임) |
확장성 | JSON 클레임으로 확장 가능 | 다양한 확장 명세 존재 (OIDC 등) |
서드파티 지원 | 직접적으로 지원하지 않음 | 핵심 기능 |
실제 구현 예시
JWT 구현 예시 (Node.js)
|
|
OAuth 2.0 구현 예시 (Node.js - 인가 코드 흐름)
|
|
용어 정리
용어 | 설명 |
---|---|