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(액세스 토큰)을 사용하여 권한을 위임하는 방식입니다.
- 리소스 소유자 (Resource Owner)
- 사용자를 의미 (예: Google 계정을 가진 사용자)
- 클라이언트 (Client)
- 사용자의 데이터를 요청하는 애플리케이션 (예: Facebook으로 로그인하는 앱)
- 리소스 서버 (Resource Server)
- 사용자 데이터를 제공하는 서버 (예: Google, Facebook API 서버)
- 인증 서버 (Authorization Server)
- OAuth 2.0 토큰을 발급하는 서버 (예: Google OAuth 서버)
- 액세스 토큰 (Access Token)
- 클라이언트가 API를 호출할 때 사용하는 인증 키 (비밀번호를 직접 전달하지 않음)
📌 OAuth 2.0 인증 흐름 (Grant Types)
OAuth 2.0은 다양한 환경(웹, 모바일, 서버 간 통신)에서 사용되기 위해 4가지 인증 방식(Grant Type)을 제공합니다.
1️⃣ Authorization Code Flow (권장) ✅
- 보안성이 높고 가장 많이 사용되는 방식
- 예: Google, Facebook 로그인
- 과정:
- 사용자가 로그인 후, **Authorization Code(인가 코드)**를 클라이언트에게 제공
- 클라이언트는 Authorization Server에 인가 코드를 전달하고 Access Token을 요청
- 서버는 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의 핵심 개선점:
- Implicit Flow 제거 → 기존에 보안 취약점이 있는 방식 제거
- PKCE 의무화 → Authorization Code Flow에서 추가 보안
- Refresh Token 강화 → 자동 회수 기능 추가
- Redirect URI 개선 → 동적으로 변경 불가
정리 비교표
| OAuth 1.0 | OAuth 2.0 | OAuth 2.1 |
|---|
| 토큰 방식 | 서명 기반 (HMAC-SHA1 등) | Bearer Token | Bearer Token |
| 보안 방식 | 요청마다 서명 필요 | TLS 필수, Bearer Token | TLS 필수, 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을 고려하는 것이 좋습니다. 🚀