OAuth 2.0 Authorization Code Flow를 다시 읽어보며

꽉·2025년 12월 24일
BackendPKCERedirect URIState-Parameteraccess tokenauthenticationauthorizationauthorization codeoauth2security

OAuth 2.0 보안 다시읽기 (Flow · OIDC · PKCE)

목록 보기
1/2
post-thumbnail

✨ TL;DR

OAuth 2.0 Authorization Code Flow는
단순히 구현 가이드에 따라 사용하기에는 다소 복잡해 보이지만,
실제 서비스 환경에서 인증 기능을 안전하게 제공하기 위해
의도적으로 설계된 구조다.

이 글은 OAuth를 사용해본 경험은 있지만,
그 내부 구조와 설계 배경을 깊이 고민해보지 못했던 개발자가
공식 문서와 보안 권고안을 다시 읽으며 정리한 기록이다.

🔍 배경 — “가이드대로는 썼지만, 질문은 해보지 않았다”

소셜 로그인이나 외부 인증 연동을 도입할 때
OAuth는 거의 표준처럼 사용된다.

보통의 도입 과정은 다음과 같다.

  • 공식 문서 또는 샘플 코드 참고
  • redirect URI 설정
  • authorization code 수신
  • token API 호출
  • user info 조회

이 과정은 비교적 수월하게 따라갈 수 있다.
실제로도 “이렇게 하면 된다”는 안내는 충분히 잘 정리돼 있다.

다만 구현을 마친 뒤에도 한 가지 질문은 남는다.

“왜 굳이 이런 구조일까?”

  • 왜 토큰을 바로 주지 않고 code만 전달할까
  • 왜 브라우저를 거치는데 이렇게 많은 단계를 둘까

이 글은 그 질문에 대한 개인적인 정리다.

🧭 Authorization Code Flow를 이해하기 위한 전제

Front Channel 과 Back Channel

이 흐름을 이해하기 위해 가장 먼저 짚고 가야 할 개념은
통신 경로의 성격 차이다.

Front Channel (브라우저 경로)

  • 사용자의 브라우저를 거치는 통신
  • redirect, query parameter, URL 기반
  • 노출·변조·탈취 가능성이 항상 존재

👉 신뢰할 수 없는 경로

Back Channel (서버 ↔ 서버)

  • HTTPS 기반 서버 간 통신
  • 인증 정보 전달 가능
  • 로그·통제·검증이 상대적으로 용이

👉 민감한 정보는 이 경로로 전달하는 것이 안전

🔄 Authorization Code Flow 전체 흐름 (서비스 관점)

  1. 사용자가 서비스에서 로그인 요청
  2. 서비스가 인증 제공자의 로그인 페이지로 redirect
  3. 사용자가 인증 완료
  4. 인증 제공자가 authorization code를 redirect URI로 전달
  5. 서비스 서버가 Back Channel로 code와 인증 정보를 전달
  6. 인증 제공자가 Access Token / ID Token 반환
  7. 필요 시 UserInfo API 호출

이 흐름에서 눈여겨볼 점은 다음이다.

  • 브라우저를 통해 전달되는 것은 code까지만
  • 실제 토큰 교환은 서버 간 통신으로만 수행

❓ 왜 authorization code만 전달하고, 토큰은 바로 주지 않을까

1️⃣ 토큰 노출을 최소화하기 위해

브라우저를 거치는 경로는 다음과 같은 위험을 가진다.

  • URL 히스토리 노출
  • 로그 또는 리퍼러 헤더 노출
  • 중간자 공격 가능성

Access Token은 권한 자체를 의미하므로
이 경로로 전달되는 것은 매우 위험하다.

그래서 OAuth는 다음을 선택했다.

  • 브라우저에는 짧고 1회성인 code만 전달
  • 실제 토큰은 서버 간 통신으로 교환

2️⃣ 요청 위조와 코드 탈취를 방어하기 위해

Authorization Code Flow는
추가적인 보안 장치와 함께 사용되는 것을 전제로 한다.

  • state 파라미터
    → 요청과 응답을 매칭해 위조 요청 방지
  • PKCE
    → authorization code 탈취 시에도 토큰 교환 불가

즉,

“code가 노출돼도 바로 사고로 이어지지 않도록”
설계된 구조다.

3️⃣ 요청 주체를 검증하기 위해

토큰 교환 단계에서는

  • client 식별 정보
  • 사전에 등록된 redirect URI
  • 추가 검증 정보(PKCE 등)

을 함께 검증할 수 있다.

이를 통해 인증 제공자는

“이 요청이 신뢰 가능한 클라이언트에서 왔는가”

를 서버 단에서 판단할 수 있다.

🧠 “그럼 callback에서 사용자 정보를 바로 주면 안 될까?”

구조적으로는 가능해 보일 수 있다.
하지만 실제 서비스 환경에서는 여러 문제가 생긴다.

  • 사용자 정보는 민감 데이터
  • 브라우저 경로는 통제가 어렵다
  • 토큰 수명 관리, 회수, 감사 로그가 불가능하다

OAuth는 이를 피하기 위해
역할을 명확히 분리한다.

역할책임
인증 제공자사용자 인증
서비스 서버토큰 관리 및 권한 판단
브라우저최소 정보 전달

⚠️ OAuth를 도입할 때 구현자가 고민해야 할 지점들

Authorization Code Flow를 적용할 때는
다음과 같은 설계 포인트도 함께 고려해야 한다.

  • 토큰 저장 위치와 수명 관리
  • refresh token 사용 여부
  • logout / revoke 처리 방식
  • 로그 및 추적 가능성
  • 장애 상황에서의 인증 우회 방지

OAuth는 단순히 “연동이 된다”로 끝나는 기능이 아니다.

📦 마무리

Authorization Code Flow는
처음 보면 다소 복잡하게 느껴질 수 있다.

하지만 공식 문서와 보안 권고안을 따라가다 보면
이 구조가 불편함이 아니라 안전장치의 집합이라는 점이 보인다.

이 글은 OAuth를 사용해본 경험을
조금 더 구조적으로 이해해보려는 시도에 가깝다.

📚 참고 문헌

profile
꽉
하나씩 꽉꽉 눌러 담는 실무 개발 노트 ✍️📦
다음 포스트

OAuth 2.0 vs OpenID Connect

0개의 댓글