웹 서비스 개발 - OAuth 인증 - 2 - OAuth 2.0 서비스 제공자 — 웹 서비스 개발 – OAuth 인증 – 2 – OAuth 2.0 서비스 제공자

Table of Contents

웹 서비스 개발 – OAuth 인증 – OAuth 인증 프로토콜

안녕하세요 여러분~ 😄
오늘은 지난 시간에 이어 OAuth 인증의 실질적인 핵심!
바로 OAuth 인증 프로토콜의 흐름과 구성 요소에 대해 아주 쉽고 재밌게 알려드릴게요.

“흐름이 너무 복잡해 보여요… 헷갈려요…”
라는 분들을 위해 예시와 비유를 곁들여,
하나하나 단계별로 풀어보겠습니다! 🚀

1. OAuth 프로토콜이란?

OAuth 프로토콜은 사용자의 비밀번호를 노출하지 않고,
제3의 애플리케이션(Client)이 사용자의 데이터를 접근할 수 있도록
권한 위임을 안전하게 처리하는 방법을 정해놓은 약속이에요.

마치 친구가 당신의 이름으로 택배를 대신 찾아가려고 할 때,
당신이 작성한 **위임장(Token)**을 들고 가서 찾는 것과 같아요!

2. OAuth 프로토콜에 등장하는 주요 등장인물

역할	설명
Resource Owner	자원 소유자, 즉 사용자 본인
Client	사용자 자원을 요청하는 애플리케이션
Authorization Server	권한 부여와 토큰 발급을 담당하는 서버
Resource Server	실제 사용자 데이터(API)를 보관하고 있는 서버

이 네 가지가 함께 협력해서 **“보안이 보장된 정보 전달”**을 실현합니다 🔐

3. OAuth 인증 플로우 (Authorization Code Grant 기준)

가장 많이 쓰이고 안전한 흐름인 Authorization Code 방식 기준으로 설명드릴게요.

전체 흐름 요약 그림 🧭

[사용자] → [클라이언트 앱] → [인가 서버] → [사용자 허용]
                ↓                         ↑
         [인가 코드 수신] ← [리디렉션]

[클라이언트 앱] → [인가 서버]
        (인가 코드로 토큰 요청)

[인가 서버] → [액세스 토큰 발급]

[클라이언트 앱] → [리소스 서버]
        (토큰으로 사용자 정보 요청)

4. 단계별 흐름 설명 💡

✅ Step 1: 권한 요청 (Authorization Request)

클라이언트가 사용자에게 권한 요청 화면을 띄웁니다.

GET https://auth-server.com/authorize?
  response_type=code&
  client_id=CLIENT_ID&
  redirect_uri=https://client.com/callback&
  scope=profile email&
  state=randomString

response_type=code : 인가 코드 방식이라는 의미
scope : 어떤 정보를 요청할지
state : CSRF 공격 방지를 위한 무작위 문자열

사용자는 로그인 후, 정보 제공을 ‘허용’하거나 ‘거부’합니다.

✅ Step 2: 인가 코드 수신

사용자가 허용을 클릭하면, 인가 서버는 클라이언트의 리디렉션 URL로 이동시키며
인가 코드를 전달합니다.

HTTP/1.1 302 Found
Location: https://client.com/callback?code=abc123&state=randomString

✅ Step 3: 토큰 요청

클라이언트는 전달받은 code를 이용해 Access Token을 요청합니다.

POST https://auth-server.com/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=abc123&
redirect_uri=https://client.com/callback&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET

이 단계는 클라이언트 앱과 인가 서버 간의 서버-서버 통신입니다.

✅ Step 4: Access Token 발급

인가 서버는 요청이 정당하면 다음과 같이 Access Token을 발급합니다.

{
  "access_token": "ya29.a0AfH6SMD...",
  "expires_in": 3600,
  "refresh_token": "1//04gFAp...",
  "scope": "profile email",
  "token_type": "Bearer"
}

✅ Step 5: 사용자 정보 요청

이제 Access Token을 이용해 Resource Server로부터 사용자 정보를 가져올 수 있어요.

GET https://api.resource-server.com/userinfo
Authorization: Bearer ya29.a0AfH6SMD...

5. 다양한 OAuth Grant Type (인가 방식)

인가 방식	설명	보안 수준	사용 예
Authorization Code	인가 코드로 토큰 요청	매우 높음	대부분의 서비스
Implicit	클라이언트에서 토큰 직접 수신	낮음	모바일/SPA (지양됨)
Client Credentials	앱 자체 인증 (사용자 없음)	높음	서버 간 통신
Password Credentials	사용자 ID/PW 직접 입력	매우 낮음	테스트용 (지양됨)
Device Code	디바이스 인증 (TV 등)	중간	TV, IoT 기기

실무에서는 거의 항상 Authorization Code 방식 + PKCE를 사용해요!

6. PKCE란? (강화된 OAuth 보안 방식)

PKCE(Proof Key for Code Exchange)는
OAuth 2.0의 모바일/SPA 보안 강화 버전이에요.

인가 요청 시 code_verifier, code_challenge 전송
토큰 요청 시 code_verifier로 검증

즉, 인가 코드 탈취 방지가 가능해져요!

7. OAuth 인증 프로토콜 요약 🧠

요소	설명
인가 코드 (Authorization Code)	1회용 인증용 코드
액세스 토큰 (Access Token)	API 요청에 사용되는 권한 증서
리프레시 토큰 (Refresh Token)	액세스 토큰 재발급 용도
Scope	접근 가능한 리소스 범위
Client ID/Secret	앱의 신원 인증 수단
Redirect URI	인가 후 리디렉션 받을 주소

8. 실전에서 주의할 점 ✅

항목	주의 내용
HTTPS 사용	OAuth 관련 모든 요청은 HTTPS 필수
Redirect URI 등록	사전에 정확히 등록한 URI만 허용됨
Access Token 저장	JS 환경에서는 HttpOnly 쿠키 사용 권장
State 값 사용	CSRF 공격 방지를 위해 반드시 포함
Token 유효성 확인	리소스 서버에서는 토큰 유효성 검증 필수

마무리하며 😊

OAuth 인증 프로토콜은 복잡해 보이지만,
기본 흐름만 이해하면 훨씬 쉽고 안전하게 다룰 수 있습니다!

오늘은 OAuth 프로토콜의 구조와 흐름을 단계별로 정리해봤고요,
다음 시간에는 OAuth 인증을 실제로 구현하는 방법도 보여드릴게요!
(예: 구글 로그인, 카카오 로그인 등 실습 중심)

항상 안전하고 효율적인 인증 시스템을 위해,
오늘 배운 내용을 꼭 기억해두세요! 💡

감사합니다 🙌