[13-2] OAuth 2.0의 주요 컴포넌트와 Authorization Code Grant의 흐름

✔️ 들어가며

우리는 매일 "Google 계정으로 로그인" 등과 같은 버튼을 클릭한다. 이 버튼 하나가 처리하는 것은 단순한 로그인이 아니다. 내 Goolge 연락처에 접근하되, 내 비밀번호는 이 앱에 주지 않겠다는 일종의 정교한 위임이다. 그리고 OAuth 2.0은 이러한 위임을 안전하게 처리하기 위한 표준 프레임워크이다.

✔️ OAuth 2.0의 4가지 주요 컴포넌트

• Resource Owner
  • 리소스의 실제 소유자, 즉 사용자이다.
• Client
  • 보호된 리소스에 접근하려는 애플리케이션으로, 우리가 개발하려는 서비스가 여기에 해당한다.
• Authorization Server
  • 사용자를 인증하고 동의를 받아 Access Token을 발급하는 곳으로, 게정을 연동하는 Google, Github 등이 여기에 해당된다.
• Resource Server
  • 보호된 리소스를 호스팅하는 서버로, Access Token을 검증하고 데이터를 반환한다.

✔️ Authorization Code Grant

OAuth 2.0에는 여러 Grant Type이 존재한다. 이때 웹 및 모바일 앱에서 가장 권장되는 방식이 Authorization Code Grant이다. 간단하게 말하자면, Access Token을 브라우저에 직접 노출하지 않고 유효한 중간 코드(Authorization Code)를 거쳐 서버 간 통신으로 교환하는 것이다. Google을 통한 로그인 예시로 그 흐름을 자세히 살펴보면 다음과 같다.

1. 로그인 요청
사용자가 "Google로 로그인" 클릭. client가 client_id, scope, state, redirect_uri 등의 
파라미터를 포함한 Authorization URL로 리다이렉트

2. 사용자 인증 및 동의
Authorization Server(Google)가 로그인 화면 ㅍ시. 사용자가 자격증명 입력 후 권한 범위 동의

3. Authorization 코드 발급
동의 완료 시 리다이렉트. 코드 유효기간은 보통 10분 이내!

4. 코드 발급
브라우저가 client 서버에 코드를 전달. client는 state 파라미터 일치 여부를 먼저 검증(CSRF 방어)

5. 토큰 교환
client 서버가 authorization server에 code + client_secret으로 POST 요청. 브라우저 없이 서버 간 직접 통신

6. Access Token 발급
authorization server가 코드 검증 후 access_token과 refresh_token 반환

7. API 호출
client가 resource server API를 호출해 보호된 리소스를 획득

✔️ 정리

OAuth 2.0은 완성된 보안 솔루션이 아니라 안전한 위임을 위한 프레임워크이다. 프로토콜 자체는 견고하지만, 보안은 구현의 디테일에서 결정된다. 실무에서는 이를 위해 Authorization Code Grant 방식을 적용한다. 추가적으로 Access Token 만료 시간을 짧게, scope을 최소화하는 원칙을 지킴으로써 보안을 강화시키는 것이 중요하다.