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

WeeklyPaper: OAuth 2.0의 주요 컴포넌트와 Authorization Code Grant 흐름을 설명하세요.

---

OAuth 2.0

OAuth 2.0은 인증(Authentication)을 위한 프로토콜이 아니라, 권한 허가(Authorization)를 위한 산업 표준 프레임워크다. 사용자가 특정 애플리케이션(제3자 앱)에게 자신의 비밀번호 같은 민감한 자격 증명을 직접 제공하지 않으면서, 자신이 소유한 자원(Resource)에 접근할 수 있는 제한된 권한을 위임(Delegate)하는 방법을 정의한다.

 

호텔에 비유하면 이해하기 쉽다. 우리는 호텔방에 들어가기 위해 마스터키를 복사해서 주차 관리원에게 주지 않는다. 대신, 프런트 데스크(권한 서버)에 가서 신원을 확인받고, 주차 관리원이 '주차장 출입'만 가능한 제한된 시간 동안 쓸 수 있는 카드키(Access Token)를 받도록 허가한다. 이 과정에서 주차 관리원은 우리의 마스터키(비밀번호)를 절대 알 수 없다.

주요 컴포넌트

1. 리소스 소유자 (Resource Owner)
   • 바로 사용자 본인이다 (자원의 실제 소유자) -> Resource Owner는 서비스 사용자(User)를 의미한다.
   • 자신의 데이터에 대한 접근 권한을 부여할 수 있는 주체다.
   • 예: Bob이라는 사용자가 Google 계정으로 Google Calendar에 접근한다면, Bob이 Resource Owner이다.
2. 클라이언트 (Client)
   • 리소스 소유자의 데이터에 접근하고자 하는 제3자 애플리케이션이다.
   • 서버, 웹, 모바일 등 다양한 형태가 될 수 있습니다.
   • 예: Bob이 일정 관리 앱(A)을 사용하고, 이 앱이 Google Calendar API에 접근한다면, 앱 A가 Client다.
3. 권한 서버 (Authorization Server)
   • 리소스 소유자를 인증하고, 사용자의 동의를 받아 클라이언트에게 접근 토큰(Access Token)을 발급하는 서버다.
   • OAuth 2에서 가장 중요한 역할을 맡고 있으며, 자격 증명의 신뢰성을 보장한다.
   • 예: Google의 로그인 서버가 Authorization Server다.
4. 리소스 서버 (Resource Server)
   • 사용자의 데이터를 실제로 저장하고 있는 API 서버다. 클라이언트로부터 접근 토큰을 받은 후, 토큰이 유효한지 확인하고 요청된 데이터를 제공한다. 
   • 예: Google Photo API 서버는 Resource Server다.

기본적인 흐름

OAuth 2는 사용자의 비밀번호를 제3자 앱이 알 필요가 없도록 만들었다는 점이 큰 핵심이다.

신뢰 가능한 인증 서버(예: Google)가 인증을 담당하고, 애플리케이션(클라이언트)에게 Access Token을 발급한다. 애플리케이션은 이 토큰으로 리소스(API)를 사용하는 것이다.

 

이렇게 OAuth 2를 사용하는 어플리케이션 유형은 주로:

• 3rd party를 직접 사용하는 서비스
  • 예: 우리 서비스가 Google Drive, Calendar, GitHub, Slack 등의 API를 호출
  • 흐름: 사용자가 해당 서비스에 로그인/동의 → Access Token 발급 → 우리 서비스가 API 호출
  • 효과: 비밀번호는 몰라도 되고, 허용된 Scope 내에서만 접근 가능
• 로그인 수단으로 제공 (소셜 로그인)
  • 예: "구글로 로그인", "네이버로 로그인", "GitHub로 로그인"
  • 효과: 회원가입/로그인이 간편해지고, 서비스는 자체 비밀번호 저장소를 최소화 가능
  • 선택 가이드: 자사 계정 체계가 필요하되 편의성도 중요하면 소셜 로그인을 보조 수단으로 제공

Authorization Code Grant 흐름

• Authorization Grant
  • Client 애플리케이션이 Access Token을 얻기 위한 Resource Owner의 권한을 표현하는 크리덴셜(Credential)을 의미한다.
  • Client가 Access Token을 얻기 위한 수단이라고 생각하면 된다.
  • 네 가지 유형
    • Authorization Code
    • Implicit
    • Client Credentials
    • Resource Owner Password Credentials
  • 그중에서 우리는 Authorization Code Grant에 자세히 다루어볼 예정이다. 다음은 Authorization Code Grant의 흐름이다.

 

 

1. Resource Owner는 소셜 로그인 버튼을 누르는 등의 서비스 요청을 Client(애플리케이션)에게 전송한다.
2. Client는 Authorization Server에 Authorization Code를 요청합니다. 이때 미리 생성한 Client ID, Redirect URI, 응답 타입을 함께 전송한다.
3. Resource Owner는 로그인 페이지를 통해 로그인을 진행합니다.
4. 로그인이 확인되면 Authorization Server는 Authorization Code를 Client에게 전달한다. (이 전에 요청과 함께 전달한 Redirect URI로 Code를 전달한다.)
5. Client는 전달받은 Authorization Code를 이용해 Access Token 발급을 요청한다. Access Token을 요청할 때 미리 생성한 Client Secret, Redirect URI, 권한 부여 방식, Authorization Code를 함께 전송한다.
6. 요청 정보를 확인한 후 Redirect URI로 Access Token을 발급한다.
7. Client는 발급받은 Access Token을 이용해 Resource Server에 Resource를 요청한다.
8. Access Token을 확인한 후 요청받은 Resource를 Client에게 전달한다.