Skip to main content

OAuth 2.0 인증 흐름 완전 정복 – 서버‑사이드, PKCE, 디바이스 코드, 클라이언트 크레덴셜까지

Published 4 min readMarkdown

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 등)

키보드가 없는 디바이스에서도 사용자가 별도 브라우저에서 인증할 수 있게 만든 흐름입니다.

  1. 디바이스 → 인증 서버에 device_code와 user_code 요청.

  2. 인증 서버는 디바이스 코드, 사용자 코드, 검증 URL을 반환.

  3. 디바이스는 화면에 사용자 코드와 검증 URL을 표시.

  4. 사용자는 스마트폰·PC에서 URL에 접속해 user_code 입력 후 로그인·동의.

  5. 디바이스는 일정 간격(interval)으로 device_code를 사용해 토큰을 폴링.

  6. 인증이 완료되면 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 호출에서 사용자 개입 없이 토큰을 발급받는 방식.

  1. 클라이언트(서버) → 인증 서버에 client_id와 client_secret 전송, grant_type=client_credentials.

  2. 인증 서버는 즉시 access_token 반환.

  3. 클라이언트는 토큰을 사용해 리소스 서버에 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 | 서버‑간 통신, 백그라운드 작업 |

실전 팁

  1. HTTPS는 기본 – 모든 토큰 교환은 TLS 위에서만.

  2. Refresh Token을 활용해 장기 세션을 안전하게 유지.

  3. Scope와 Audience를 최소 권한 원칙에 맞게 설계.

이제 여러분은 OAuth 2.0 인증 흐름을 상황에 맞게 선택하고 구현할 준비가 되었습니다.

🔗 더 깊이 파고들고 싶다면?

  • 공식 RFC 6749, 7636( PKCE ) 문서

  • 각 클라우드 제공자의 SDK 가이드(예: Google, Azure, AWS)

댓글로 여러분이 실제 적용한 사례를 공유해 주세요! 여러분의 경험이 다른 초보 개발자에게 큰 도움이 됩니다. 🚀

No comments yet. Be the first to comment.

More from this blog