웹 애플리케이션을 개발하다 보면 로그인과 보안이 중요한 요소로 등장합니다.
특히, 소셜 로그인(Google, Naver, Kakao 등) 을 도입하고 싶다면 OAuth 2.0을 고려해야 하고,
API 요청을 안전하게 보호하려면 JWT를 함께 사용하는 것이 일반적입니다.

이 글에서는 OAuth 2.0과 JWT가 각각 무엇인지, 그리고 왜 이 둘을 함께 사용하는지 알아보겠습니다.
설명에서는 편의상 Google을 예시로 설명하겠습니다.

OAuth 2.0이란?

OAuth 2.0은 "인증(Authentication)"을 담당하는 프로토콜입니다.
즉, "이 사용자가 누구인지 확인하는 과정"을 처리하는 표준 방식입니다.

보통 우리가 소셜 로그인을 구현할 때 OAuth 2.0을 사용합니다.
예를 들어, Google 로그인을 사용하면 사용자가 비밀번호를 직접 입력하지 않아도 Google을 통해 본인 인증을 할 수 있습니다.

OAuth 2.0 인증 과정

  1. 사용자가 Google 로그인 버튼을 클릭
  2. Google 로그인 화면에서 이메일/비밀번호 입력 후 로그인
  3. Google이 Authorization Code(인가 코드) 를 백엔드(Spring Boot)로 전달
  4. 백엔드는 이 코드를 Google에 보내고 Access Token & ID Token 을 요청
  5. Google이 Access Token & ID Token을 반환

✅ Authorization Code는 API를 호출할 수 없으며, Access Token을 받아야만 API 요청 가능
✅ Google이 제공하는 ID Token은 JWT 형식으로 사용자 정보를 포함

JWT(JSON Web Token)란?

JWT는 사용자 정보와 권한을 안전하게 포함하는 토큰입니다.
JWT를 사용하면 백엔드가 매번 DB를 조회하지 않고도 사용자를 확인할 수 있습니다.

JWT의 특징

  • Base64로 인코딩된 JSON 데이터 (디코딩 가능)
  • Header, Payload, Signature 3가지로 구성됨
  • 서버에서 검증 가능 → 세션이 필요 없음
  • 일정 시간이 지나면 만료됨 (exp: 만료 시간 설정 가능)

👉 예제 JWT (Base64로 인코딩된 JSON 데이터)

{
  "sub": "user1234",
  "email": "user@example.com",
  "role": "USER",
  "exp": 1710000000
}

이 JWT를 클라이언트에서 저장하고 API 요청 시 함께 보내면,
백엔드는 이 정보를 디코딩하여 사용자 인증 및 인가(권한 체크)를 수행할 수 있습니다.

OAuth 2.0과 JWT를 함께 사용하는 이유

그렇다면, OAuth 2.0과 JWT를 왜 같이 사용할까요?

✅ 1. OAuth 2.0은 "인증", JWT는 "인가"를 담당

  • OAuth 2.0 → "이 사용자가 로그인했는가?" (사용자 인증)
  • JWT → "이 사용자가 어떤 권한을 가지고 있는가?" (API 요청 검증)

즉, OAuth 2.0은 사용자를 로그인시키는 역할이고,
JWT는 사용자의 권한을 체크하고 API 요청을 안전하게 처리하는 역할을 합니다.

✅ 2. OAuth 2.0이 Access Token을 반환하는데, JWT로 변환하는 이유

Google이 제공하는 Access Token을 그대로 사용할 수도 있지만,
보통 백엔드(Spring Boot)에서 JWT를 새롭게 발급하여 클라이언트에 전달합니다.

이유는 다음과 같습니다.

1️. 추가적인 사용자 정보 & 권한(Role) 포함 가능
Google이 제공하는 Access Token에는 우리 서비스에서 필요한 추가 정보가 없음
예를 들어, "이 사용자가 관리자(Admin)인지?" 같은 정보가 필요할 수도 있습니다.
그래서 백엔드에서 JWT를 생성하여 role 정보를 포함하고 클라이언트에 전달합니다.

2️. 서비스별 맞춤 만료 시간 설정 가능
Google의 Access Token은 보통 1시간짜리인데,
서비스에서는 24시간짜리 토큰을 쓰고 싶을 수도 있음
백엔드에서 JWT를 발급하면 토큰의 유효 시간을 직접 설정할 수 있음

3️. 보안적인 이유
Google이 발급한 Access Token을 클라이언트에서 직접 관리하면 보안 위험이 증가합니다.
백엔드에서 자체 JWT를 만들어 클라이언트에 제공하면 보안이 더 강화됩니다.

OAuth 2.0 + JWT 흐름 정리

  1. 화면에서 Google 로그인 버튼 클릭
  2. Google 로그인 성공 후 Authorization Code를 백엔드(Spring Boot)로 전달
  3. 백엔드가 Authorization Code를 Google에 보내고 Access Token & ID Token을 요청
  4. Google이 Access Token & ID Token(JWT 형식)를 반환
  5. 백엔드는 자체적으로 새로운 JWT를 생성하여 클라이언트에 전달
  6. 클라이언트는 이 JWT를 저장하고, API 요청 시 포함하여 보냄
  7. 백엔드는 JWT를 검증하여 사용자 권한을 체크

JWT를 이용한 인가(Authorization) 예제

JWT는 로그인된 사용자만 특정 API에 접근하도록 제한할 수 있습니다.

✅ (1) 일반 사용자가 API 요청을 보낼 때

  • 백엔드는 JWT를 검증하여 사용자가 유효한지 확인
  • 유효하면 API 응답 반환

✅ (2) 관리자(Admin) 페이지 접근 시

  • 백엔드는 JWT에서 role 정보("ADMIN")를 체크
  • 관리자가 아니면 403 Forbidden 응답

이처럼 JWT를 사용하면 별도의 세션 관리 없이도 사용자 권한을 체크할 수 있습니다.

OAuth 2.0 + JWT의 장단점

장점

  • 소셜 로그인 가능 → Google, Facebook 등의 인증 시스템 활용 가능
  • 세션이 필요 없음 → JWT 자체에 사용자 정보 포함
  • 확장성 우수 → 마이크로서비스 환경에서도 활용 가능
  • 백엔드 부하 감소 → 매 요청마다 DB 조회 없이 JWT 검증만 하면 됨

단점

  • JWT 탈취 시 보안 위험 → 토큰 유효 시간을 짧게 설정하고, Redis 등을 활용한 블랙리스트 적용 필요
  • 토큰 크기 증가 → 세션보다 크기가 크므로 네트워크 비용이 증가할 수 있음

결론: 언제 OAuth 2.0 + JWT를 사용할까?

✅ 소셜 로그인을 제공하고 싶을 때
✅ API 요청 시 사용자의 인증/권한을 간단하게 처리하고 싶을 때
✅ 마이크로서비스 아키텍처를 고려할 때
✅ 세션 관리 없이 확장성이 높은 인증 시스템이 필요할 때

'기타' 카테고리의 다른 글

AWS 요금 과다 청구 해결하기  (0) 2025.10.22
Redis란?  (0) 2025.01.14

티스토리툴바