OAuth 2.0

by

OAuth 2.0 정의 및 개요

📌 OAuth 2.0이란?

OAuth 2.0은 “인증(Authorization) 프레임워크”로, 사용자가 자신의 자격 증명(예: 아이디, 비밀번호)을 직접 제공하지 않고도 타사 애플리케이션이 제한된 범위 내에서 자신의 계정 정보에 접근할 수 있도록 하는 표준 프로토콜

🔹 대표적인 사용 사례:

  • 소셜 로그인 (Google, Facebook, Twitter, GitHub 등)
  • 서드파티 앱이 사용자의 데이터를 접근 (예: Google Drive API, Spotify API 등)
  • 결제 시스템 연동 (예: PayPal API, Stripe API 등)

📌 OAuth 2.0의 핵심 개념

OAuth 2.0은 Access Token(액세스 토큰)을 사용하여 권한을 위임하는 방식입니다.

  1. 리소스 소유자 (Resource Owner)
    • 사용자를 의미 (예: Google 계정을 가진 사용자)
  2. 클라이언트 (Client)
    • 사용자의 데이터를 요청하는 애플리케이션 (예: Facebook으로 로그인하는 앱)
  3. 리소스 서버 (Resource Server)
    • 사용자 데이터를 제공하는 서버 (예: Google, Facebook API 서버)
  4. 인증 서버 (Authorization Server)
    • OAuth 2.0 토큰을 발급하는 서버 (예: Google OAuth 서버)
  5. 액세스 토큰 (Access Token)
    • 클라이언트가 API를 호출할 때 사용하는 인증 키 (비밀번호를 직접 전달하지 않음)

📌 OAuth 2.0 인증 흐름 (Grant Types)

OAuth 2.0은 다양한 환경(웹, 모바일, 서버 간 통신)에서 사용되기 위해 4가지 인증 방식(Grant Type)을 제공합니다.

1️⃣ Authorization Code Flow (권장) ✅

  • 보안성이 높고 가장 많이 사용되는 방식
  • 예: Google, Facebook 로그인
  • 과정:
    1. 사용자가 로그인 후, **Authorization Code(인가 코드)**를 클라이언트에게 제공
    2. 클라이언트는 Authorization Server에 인가 코드를 전달하고 Access Token을 요청
    3. 서버는 Access Token을 발급

2️⃣ Implicit Flow (Deprecated, 비추천) ❌

  • 보안 취약점(Access Token이 URL에 노출됨)
  • 기존에 SPA(Single Page Application)에서 사용했으나, 보안 문제로 OAuth 2.1에서 제거됨

3️⃣ Client Credentials Flow

  • 사용자가 개입하지 않고, 서버 간 인증할 때 사용
  • 예: 마이크로서비스 간 API 호출

4️⃣ Password Grant (Deprecated, 비추천) ❌

  • 사용자가 직접 ID/PW를 입력하여 인증 → 보안 취약
  • OAuth 2.1에서 제거됨

OAuth 1.0, 2.0, 그리고 OAuth 2.1의 차이를 비교하면 다음과 같습니다.

1. OAuth 1.0

✅ 특징:

  • 2007년에 발표된 초판 인증 프레임워크
  • 암호화 기반 서명(Signature) 방식 사용 → 요청마다 서명을 생성해야 함
  • Access Token과 함께 Secret Key 필요
  • 복잡한 프로세스 (Nonce, Timestamp 포함)
  • HMAC-SHA1, RSA-SHA1 등의 서명 방식 사용
  • 브라우저 없이 서버-서버 간 인증 가능

✅ 단점:

  • 구현이 복잡함
  • 암호화 방식이 강제되므로 유연성이 부족
  • 서명 검증이 필요해 처리 비용이 증가

2. OAuth 2.0

✅ 특징:

  • 2012년 발표된 버전으로, OAuth 1.0보다 단순하고 확장 가능
  • Bearer Token 방식 도입 → 요청마다 서명 불필요
  • 다양한 인증 방식 지원 (Authorization Code, Implicit, Password, Client Credentials 등)
  • 보안 강화를 위해 TLS(HTTPS) 필수
  • Scope 개념 도입 → 권한 범위 지정 가능

✅ 단점:

  • Bearer Token은 탈취 시 쉽게 사용 가능 → 추가 보안 필요
  • 암호화 서명이 기본이 아님
  • RFC가 여러 개로 분리되어 있어 구현이 복잡할 수 있음

3. OAuth 2.1 (개발 중)

✅ 특징:

  • OAuth 2.0의 보안 취약점을 개선한 버전
  • Implicit Grant 제거 (보안 취약점으로 인해)
  • Proof Key for Code Exchange (PKCE) 필수 적용
  • Refresh Token 보안 강화 (One-time use 가능)
  • Bearer Token 보안 강화 (TLS 사용 강제)
  • Redirect URI 고정 → Open Redirect 공격 방지

✅ OAuth 2.1의 핵심 개선점:

  1. Implicit Flow 제거 → 기존에 보안 취약점이 있는 방식 제거
  2. PKCE 의무화 → Authorization Code Flow에서 추가 보안
  3. Refresh Token 강화 → 자동 회수 기능 추가
  4. Redirect URI 개선 → 동적으로 변경 불가

정리 비교표

OAuth 1.0OAuth 2.0OAuth 2.1
토큰 방식서명 기반 (HMAC-SHA1 등)Bearer TokenBearer Token
보안 방식요청마다 서명 필요TLS 필수, Bearer TokenTLS 필수, PKCE 필수
Implicit Flow없음있음제거됨
PKCE없음선택 사항필수
보안성강하지만 복잡간단하지만 토큰 탈취 위험2.0보다 개선됨
사용 사례서버-서버 인증웹, 모바일 앱최신 웹, 모바일 보안 강화

👉 어떤 것을 사용해야 할까?

  • ✅ OAuth 1.0 → 현재는 거의 사용되지 않음
  • ✅ OAuth 2.0 → 대부분의 서비스에서 사용 (단, 보안 설정이 필요)
  • ✅ OAuth 2.1 → 앞으로 점점 더 사용될 예정 (2.0의 보안 강화를 원한다면 추천)

OAuth 2.1은 아직 표준화 과정 중이지만, 기존 OAuth 2.0을 보완하는 방향으로 가고 있어 최신 보안 요구사항을 충족하려면 OAuth 2.1을 고려하는 것이 좋습니다. 🚀

Leave a Comment