OAuth 2.0 인증 흐름 완전 정복 – 서버‑사이드, PKCE, 디바이스 코드, 클라이언트 크레덴셜까지
SEO 키워드: OAuth 2.0, 인증 흐름, PKCE
# 📌 서론 – “왜 이렇게 복잡할까?”
최근 웹·모바일 서비스가 늘어나면서 보안은 선택이 아닌 필수가 되었습니다.
그 중심에 있는 것이 바로 OAuth 2.0 입니다.
하지만 “Authorization Code”, “PKCE”, “Device Code”, “Client Credentials” 같은 용어가 난무해 초보자는 어디서부터 손을 뻗어야 할지 막막합니다.
이 글에서는 OAuth 2.0의 주요 인증 흐름을 쉽게 이해할 수 있도록 다이어그램과 함께 단계별로 풀어냅니다.
핵심 포인트
1️⃣ 인증 흐름마다 누가, 무엇을, 언제 하는지 구분한다.
2️⃣ 각 흐름이 어떤 상황에 최적화돼 있는지 기억한다.
3️⃣ 구현 시 보안 체크포인트를 놓치지 않는다.
# 🧩 본론
# 1️⃣ Authorization Code Flow (서버‑사이드 애플리케이션)
| 단계 | 설명 | 주요 파라미터 |
|------|------|--------------|
| 1. 사용자 → 클라이언트 | 로그인 버튼 클릭 → 인증 요청 URL 생성 | response_type=code, client_id, redirect_uri, scope |
| 2. 인증 서버 → 사용자 | 로그인 화면 제공 | – |
| 3. 사용자 → 인증 서버 | 아이디·비밀번호 입력 후 승인 | – |
| 4. 인증 서버 → 클라이언트 | code(인증 코드) 반환 (리다이렉트) | code |
| 5. 클라이언트 → 인증 서버 | code와 client_secret을 이용해 access token 요청 | grant_type=authorization_code, code, redirect_uri, client_id, client_secret |
| 6. 인증 서버 → 클라이언트 | access_token(및 refresh_token) 반환 | access_token, refresh_token |
mermaid
sequenceDiagram
participant User
participant Client
participant AuthServer
User->>Client: 로그인 버튼 클릭
Client->>AuthServer: Authorization Request (code)
AuthServer->>User: 로그인·동의 화면
User->>AuthServer: 인증·동의
AuthServer->>Client: Redirect with code
Client->>AuthServer: Token Request (code+secret)
AuthServer->>Client: Access Token (+Refresh)
특징
보안:
client_secret이 서버에만 존재 → 토큰 탈취 위험 낮음.사용처: 전통적인 웹 애플리케이션, 백엔드 API 서버.
# 2️⃣ PKCE (Proof Key for Code Exchange) – SPA·모바일 전용
PKCE는 공개 클라이언트(비밀키를 저장할 수 없는 환경)에서도 Authorization Code Flow를 안전하게 사용하도록 만든 확장입니다.
| 단계 | 설명 | 핵심값 |
|------|------|--------|
| 1. 클라이언트 | code_verifier(랜덤 문자열) 생성 → SHA‑256 해시 후 Base64URL 인코딩 → code_challenge 생성 | code_verifier, code_challenge |
| 2. 클라이언트 → 인증 서버 | code_challenge와 code_challenge_method=S256 포함해 인증 요청 | code_challenge, code_challenge_method |
| 3. 인증 서버 → 사용자 | 로그인·동의 화면 | – |
| 4. 인증 서버 → 클라이언트 | code 반환 (리다이렉트) | code |
| 5. 클라이언트 → 인증 서버 | code와 원본 code_verifier 전송 | code_verifier |
| 6. 인증 서버 | code_verifier를 해시해 code_challenge와 비교 → 일치하면 토큰 발급 | access_token |
mermaid
sequenceDiagram
participant SPA as SPA/모바일
participant Auth as AuthServer
SPA->>SPA: generate code_verifier & code_challenge
SPA->>Auth: Auth Request (code_challenge)
Auth->>SPA: Redirect with code
SPA->>Auth: Token Request (code + code_verifier)
Auth->>SPA: Access Token
장점
client_secret없이도 인증 코드 탈취 방지.SPA, React, Vue, iOS/Android 앱에 최적.
# 3️⃣ Device Code Flow (IoT·스마트 TV 등)
키보드가 없는 디바이스에서도 사용자가 별도 브라우저에서 인증할 수 있게 만든 흐름입니다.
디바이스 → 인증 서버에
device_code와user_code요청.인증 서버는 디바이스 코드, 사용자 코드, 검증 URL을 반환.
디바이스는 화면에 사용자 코드와 검증 URL을 표시.
사용자는 스마트폰·PC에서 URL에 접속해 user_code 입력 후 로그인·동의.
디바이스는 일정 간격(
interval)으로device_code를 사용해 토큰을 폴링.인증이 완료되면
access_token을 반환.
mermaid
sequenceDiagram
participant Device
participant Auth
participant UserBrowser
Device->>Auth: POST /device/code
Auth->>Device: device_code, user_code, verification_uri
Device->>UserBrowser: Display user_code & URL
UserBrowser->>Auth: Enter user_code + login
Auth->>UserBrowser: Consent OK
loop Polling
Device->>Auth: POST /token (device_code)
Auth-->>Device: pending / access_token
end
활용 사례
- 스마트 TV, 게임 콘솔, 라즈베리파이 기반 IoT 디바이스.
# 4️⃣ Client Credentials Flow (머신‑투‑머신)
서버 간 API 호출에서 사용자 개입 없이 토큰을 발급받는 방식.
클라이언트(서버) → 인증 서버에
client_id와client_secret전송,grant_type=client_credentials.인증 서버는 즉시
access_token반환.클라이언트는 토큰을 사용해 리소스 서버에 API 호출.
mermaid
sequenceDiagram
participant ServiceA as Client (Service A)
participant Auth as AuthServer
participant API as ResourceServer
ServiceA->>Auth: Token Request (client_id, client_secret)
Auth->>ServiceA: Access Token
ServiceA->>API: API Call (Bearer token)
API->>ServiceA: Response
특징
사용자 개입 X → 백엔드 서비스, 배치 작업, CI/CD 파이프라인에 적합.
범위(scope) 를 통해 허용된 리소스를 제한한다.
# 🏁 결론 – 오늘 당장 적용해 보세요!
| 흐름 | 언제 쓰나요? |
|------|--------------|
| Authorization Code | 전통적인 웹 서버 애플리케이션 |
| PKCE | SPA, 모바일 앱(React Native, iOS, Android) |
| Device Code | 키보드·마우스 없는 디바이스(스마트 TV, IoT) |
| Client Credentials | 서버‑간 통신, 백그라운드 작업 |
실전 팁
HTTPS는 기본 – 모든 토큰 교환은 TLS 위에서만.
Refresh Token을 활용해 장기 세션을 안전하게 유지.
Scope와 Audience를 최소 권한 원칙에 맞게 설계.
이제 여러분은 OAuth 2.0 인증 흐름을 상황에 맞게 선택하고 구현할 준비가 되었습니다.
🔗 더 깊이 파고들고 싶다면?
공식 RFC 6749, 7636( PKCE ) 문서
각 클라우드 제공자의 SDK 가이드(예: Google, Azure, AWS)
댓글로 여러분이 실제 적용한 사례를 공유해 주세요! 여러분의 경험이 다른 초보 개발자에게 큰 도움이 됩니다. 🚀
Comments
Join the discussionNo comments yet. Be the first to comment.