JWT vs OAuth: 주요 차이점, 상호 작동 원리, 그리고 모범 사례

인증에 처음 입문했거나 로그인, 결제, 사용자 데이터를 다루는 앱을 만들고 있다면 JWT와 OAuth라는 용어를 한 번쯤 들어봤을 것입니다. 이 용어들이 복잡하고 "백엔드 전용"처럼 들릴 수 있지만, 사실 보안 엔지니어만을 위한 주제가 아닙니다.

API, 서드파티 연동, AI, MCP, 에이전트 기반 시스템 등 신기술의 등장으로 인해 이 둘은 제품의 사용성, 보안, 성장과 직접적으로 연결되어 있습니다. 기본을 이해하면 다음과 같습니다:

• 처음부터 안전한 기능을 설계할 수 있습니다
• 엔지니어링 팀과 효과적으로 소통할 수 있습니다
• 인증 및 사용자 흐름과 관련된 제품 결정을 더 잘 내릴 수 있습니다
• 사용자 신뢰를 해치는 비용이 많이 드는 보안 실수를 피할 수 있습니다

예를 들어, 최신 MCP 스펙에서 권한 시스템은 검증된 표준 위에 구축됩니다:

• OAuth 2.1 IETF Draft (draft-ietf-oauth-v2-1-13)
• OAuth 2.0 Authorization Server Metadata (RFC8414)
• OAuth 2.0 Dynamic Client Registration Protocol (RFC7591)
• OAuth 2.0 Protected Resource Metadata (RFC9728)

왜 중요한가#

백엔드 코드를 작성하지 않는 입장에서도:

• 개발자들은 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 인코딩 파트로 구성됩니다:

1. 헤더: 알고리즘(e.g. HS256, RS256) 및 토큰 타입(JWT) 지정
2. 페이로드: 다음과 같은 클레임 포함
   • iss (발급자)
   • sub (주제, 예: 사용자 ID)
   • aud (대상)
   • exp (만료시간)
   • 필요에 따른 커스텀 클레임
3. 서명: 토큰이 변조되지 않았음을 검증

예시:

JWT 예시#

아래는 일반적인 JWT의 인코딩된 형태와 이를 디코딩한 구조 예시입니다. 각 파트가 무엇을 의미하는지 보여줍니다.

인코딩된 JWT (Base64URL)

점으로 구분된 3개 파트(헤더.페이로드.서명)로 구성됩니다.

디코딩된 구조

• 헤더

• 페이로드

페이로드에는 클레임이 담깁니다

• 서명

서명은 토큰이 변조되지 않았음을 보장합니다.

주요 특징#

• 자기완결적: 필요한 정보가 모두 토큰 안에 포함됨
• 스테이트리스: 서버 측 세션 스토리지 불필요
• 서명됨: (필요에 따라 암호화도 가능) 진위 검증 가능

JWT vs 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의 상호작용 원리#

현대 인증/권한 시스템에서:

1. OAuth가 접근 권한 부여 플로우를 담당
2. 권한 서버가 접근 토큰(대개 JWT)을 발급
3. JWT가 API 요청에 첨부되어 신원과 권한 증명

OAuth에서의 특별 토큰#

• ID 토큰: OpenID Connect에서 사용자 신원 증명용, 항상 JWT
• 액세스 토큰: JWT 또는 불투명 토큰일 수 있음

JWT와 OAuth 사용 시 모범 사례#

• HTTPS 사용: 토큰 전송 시 보호
• JWT 만료 시간 짧게 설정: 장기 세션에는 리프레시 토큰 사용
  • https://auth.wiki/offline-access
• 서명 검증: 모든 클레임 신뢰 전 반드시 검증
• aud 클레임 확인: 내 앱 대상 토큰인지 체크
• 로컬스토리지에 토큰 저장 지양: XSS 위험이 있으면 보안 쿠키 사용 권장

마지막 생각#

• OAuth 2.0은 어떻게 토큰을 얻고 사용할지를 정의합니다.
• JWT는 토큰의 형태와 정보 전달 방식을 정의합니다.
• 둘은 상호보완적이며, 대체 관계가 아닙니다.

대부분의 현대 API는 권한 부여 플로우에 OAuth를, 토큰 표현에는 JWT를 사용합니다. 둘 다 이해하면 안전하고 확장성 있는 인증 시스템을 설계할 수 있게 됩니다.