인증에 처음 입문했거나 로그인, 결제, 사용자 데이터를 다루는 앱을 만들고 있다면 JWT와 OAuth라는 용어를 한 번쯤 들어봤을 것입니다. 이 용어들이 복잡하고 "백엔드 전용"처럼 들릴 수 있지만, 사실 보안 엔지니어만을 위한 주제가 아닙니다.
API, 서드파티 연동, AI, MCP, 에이전트 기반 시스템 등 신기술의 등장으로 인해 이 둘은 제품의 사용성, 보안, 성장과 직접적으로 연결되어 있습니다. 기본을 이해하면 다음과 같습니다:
- 처음부터 안전한 기능을 설계할 수 있습니다
- 엔지니어링 팀과 효과적으로 소통할 수 있습니다
- 인증 및 사용자 흐름과 관련된 제품 결정을 더 잘 내릴 수 있습니다
- 사용자 신뢰를 해치는 비용이 많이 드는 보안 실수를 피할 수 있습니다
예를 들어, 최신 MCP 스펙에서 권한 시스템은 검증된 표준 위에 구축됩니다:
왜 중요한가#
백엔드 코드를 작성하지 않는 입장에서도:
- 개발자들은 API 보안, 세션 관리, 서드파티 연동 방법을 배웁니다.
- 프로덕트 매니저는 로그인 흐름, 연동, 컴플라이언스에 대해 팀 및 파트너와 소통할 수 있는 용어를 익힙니다.
- 창업자 및 초기 팀은 연동에 취약하거나 침해에 노출되는 허술한 로그인 시스템 구축을 피할 수 있습니다.
JWT vs OAuth: 두 핵심 개념#
JWT (JSON Web Token)와 OAuth (Open Authorization)는 종종 함께 사용되지만 목적이 다릅니다.
비유하자면:
- OAuth는 누군가에게 키를 주는 방식이지만, 들어갈 수 있는 방에만 들어가게 합니다.
- JWT는 그들이 지닌 신분증으로, 신원과 권한 증명입니다.
다음 섹션에서 두 기술을 나란히 비교해 차이점과 상호 보완 관계를 명확히 설명합니다.
OAuth 2.0이란?#
OAuth 2.0은 애플리케이션(클라이언트)이 사용자의 인증정보(패스워드 등)를 노출하지 않고 제한된 권한으로 사용자 리소스에 접근할 수 있게 해주는 널리 채택된 권한 부여 프레임워크입니다.
OAuth의 핵심 역할#
- 클라이언트: 접근을 요청하는 애플리케이션
- 리소스 소유자: 보통 사용자이며, 권한을 부여합니다
- 권한 서버: 인증 후 액세스 토큰을 발급합니다
- 리소스 서버: 보호된 리소스를 호스팅하고, 토큰을 검증합니다
자주 쓰이는 OAuth 그랜트 타입(Flow)#
- Authorization Code Grant: 가장 안전하고 권장됨, PKCE와 함께 브라우저, SPA, 모바일 앱에 추천
- Implicit Grant: 보안상의 이유로 OAuth 2.1에서 비권장
- Resource Owner Password Credentials (ROPC): 사용자 이름과 패스워드를 직접 교환, 보안이 약함
- Client Credentials Grant: 서버-서버 또는 머신-머신 통신용
- Device Flow: 키보드가 없는 기기 (스마트 TV 등)에서, 사용자가 두 번째 기기로 인증할 때
JWT (JSON Web Token)란?#
JWT는 두 주체 간에 클레임을 안전하게 전달하기 위한 오픈 스탠다드(RFC 7519)입니다. 작고 URL-safe하며, 여러 시스템에서 널리 사용됩니다.
JWT의 구조#
JWT는 점(.)으로 구분된 3개의 base64url 인코딩 파트로 구성됩니다:
- 헤더: 알고리즘(e.g. HS256, RS256) 및 토큰 타입(JWT) 지정
- 페이로드: 다음과 같은 클레임 포함
- iss (발급자)
- sub (주제, 예: 사용자 ID)
- aud (대상)
- exp (만료시간)
- 필요에 따른 커스텀 클레임
- 서명: 토큰이 변조되지 않았음을 검증
예시:
JWT 예시#
아래는 일반적인 JWT의 인코딩된 형태와 이를 디코딩한 구조 예시입니다. 각 파트가 무엇을 의미하는지 보여줍니다.
인코딩된 JWT (Base64URL)
점으로 구분된 3개 파트(헤더.페이로드.서명)로 구성됩니다.
디코딩된 구조
페이로드에는 클레임이 담깁니다
서명은 토큰이 변조되지 않았음을 보장합니다.
주요 특징#
- 자기완결적: 필요한 정보가 모두 토큰 안에 포함됨
- 스테이트리스: 서버 측 세션 스토리지 불필요
- 서명됨: (필요에 따라 암호화도 가능) 진위 검증 가능
JWT vs OAuth: 핵심 차이점#
| 측면 | JWT | OAuth 2.0 |
|---|
| 정의 | 토큰 포맷 | 권한 부여 프레임워크 |
| 목적 | 신원/클레임의 안전한 전달 | 접근 권한 부여와 관리 방식을 정의 |
| 범위 | 데이터 구조 표현 | 프로세스와 흐름 |
| 단독 사용? | 예, 독자적으로 토큰 발급/검증 | 아니오, 토큰 포맷 (예: JWT)이 필요함 |
| 사용 예시 | API가 JWT를 직접 발급 | 앱이 OAuth 플로우로 접근 토큰 획득 |
요약:
- JWT는 컨테이너: 신원 정보가 담긴 여권과 같음
- OAuth는 시스템: 출입국 관리처럼 누가 여권을 받는지와 어디에 접근할 수 있는지 결정
JWT 단독 사용 시점#
다음과 같은 경우 JWT만 사용합니다:
- 단일 시스템 인증: 외부 ID 제공자 없이 앱이 직접 토큰을 발급/검증
- 스테이트리스 세션 관리: 서버에 세션 저장 없이 사용자 신원 검증
- 심플한 API 인증: 간단한 내부 API에서 복잡한 동의 흐름 없이 기본 권한 확인
- 성능 중심 검증: 리소스 서버가 인증 서버에 접속하지 않고 로컬에서 검증
예시:
SPA와 백엔드 API를 모두 직접 소유하고 관리할 때. API가 sub(사용자 ID), role, exp(만료) 클레임이 담긴 JWT를 발급합니다.
OAuth 단독 사용 시점#
JWT 없이 OAuth만 사용하는 경우:
- 자기완결적 토큰이 필요 없고, 조회가 필요한 불투명 토큰이 허용될 때
- 리소스 서버가 접근 전에 항상 권한 서버에 확인해야 하는 경우
- JWT가 적합하지 않은 레거시나 규제 환경
- 서드파티 앱에 제한적 액세스를 안전하게 위임 제공이 목표일 때
예시:
API가 불투명한 접근 토큰(opaque token)을 발급하고, 각 요청마다 권한 서버를 조회해 검증
JWT와 OAuth를 함께 써야 할 때#
둘을 결합해 사용하는 상황:
- 여러 서비스나 API가 있고, OAuth로 보안 플로우를 제공하면서 서비스 간 검증 가능한 JWT가 필요할 때
- “구글로 로그인” 같은 서드파티 로그인 제공. OAuth가 동의를 처리하고 JWT가 접근 토큰/ID 토큰으로 사용됨
- 마이크로서비스 아키텍처. 각 서비스가 JWT를 자체 검증
- OAuth의 위임 구조와 JWT의 스케일러블/스테이트리스 검증을 결합할 필요가 있을 때
예시:
앱에서 구글로 로그인 제공. OAuth가 권한 부여 플로우 관리, 구글이 JWT 접근 토큰을 발급, API가 이를 자체 검증 후 데이터 반환
JWT와 OAuth의 상호작용 원리#
현대 인증/권한 시스템에서:
- OAuth가 접근 권한 부여 플로우를 담당
- 권한 서버가 접근 토큰(대개 JWT)을 발급
- JWT가 API 요청에 첨부되어 신원과 권한 증명
OAuth에서의 특별 토큰#
- ID 토큰: OpenID Connect에서 사용자 신원 증명용, 항상 JWT
- 액세스 토큰: JWT 또는 불투명 토큰일 수 있음
JWT와 OAuth 사용 시 모범 사례#
- HTTPS 사용: 토큰 전송 시 보호
- JWT 만료 시간 짧게 설정: 장기 세션에는 리프레시 토큰 사용
- 서명 검증: 모든 클레임 신뢰 전 반드시 검증
- aud 클레임 확인: 내 앱 대상 토큰인지 체크
- 로컬스토리지에 토큰 저장 지양: XSS 위험이 있으면 보안 쿠키 사용 권장
마지막 생각#
- OAuth 2.0은 어떻게 토큰을 얻고 사용할지를 정의합니다.
- JWT는 토큰의 형태와 정보 전달 방식을 정의합니다.
- 둘은 상호보완적이며, 대체 관계가 아닙니다.
대부분의 현대 API는 권한 부여 플로우에 OAuth를, 토큰 표현에는 JWT를 사용합니다. 둘 다 이해하면 안전하고 확장성 있는 인증 시스템을 설계할 수 있게 됩니다.
