Hunny's Daily

개발과 일상에서의 달콤한 순간들을 기록하며, 유용한 팁과 인사이트를 공유합니다.

OAuth 2.0 동작 흐름 정리

인증과 인가가 실제로 처리되는 과정

OAuth 2.0은 외부 서비스에 사용자의 비밀번호를 직접 전달하지 않고도, 제한된 권한을 위임할 수 있도록 설계된 인가 프레임워크다. 로그인 방식으로 자주 사용되지만, OAuth 2.0의 핵심 목적은 인증이 아니라 인가다. 이 글에서는 OAuth 2.0의 주요 구성 요소와 가장 많이 사용되는 동작 흐름을 중심으로 정리한다.

OAuth 2.0이 등장한 배경

OAuth 2.0이 등장하기 전에는 다음과 같은 방식이 흔했다.

  • 외부 서비스에 아이디와 비밀번호 직접 전달
  • 하나의 계정 정보로 여러 서비스 접근

이 방식은 보안 위험이 크고, 권한 범위 제어가 어렵다는 문제가 있었다. OAuth 2.0은 이러한 문제를 해결하기 위해 권한 위임이라는 개념을 도입했다.

OAuth 2.0의 핵심 개념

OAuth 2.0을 이해하려면 먼저 등장하는 주체들을 구분해야 한다.

  • Resource Owner
    • 사용자
  • Client
    • 사용자를 대신해 자원 접근을 요청하는 애플리케이션
  • Authorization Server
    • 인증 및 토큰 발급 담당
  • Resource Server
    • 실제 자원을 제공하는 서버

이 네 가지 역할을 기준으로 OAuth 2.0의 흐름이 구성된다.

OAuth 2.0에서 사용하는 토큰

OAuth 2.0에서는 토큰을 통해 권한을 위임한다.

  • Access Token
    • 자원 접근을 위한 토큰
    • 유효 기간이 짧음
  • Refresh Token
    • Access Token 재발급 용도
    • 상대적으로 긴 유효 기간

토큰을 사용함으로써 사용자 비밀번호는 외부에 노출되지 않는다.

가장 많이 사용되는 Authorization Code 흐름

OAuth 2.0에는 여러 흐름이 있지만, 현재 가장 표준적으로 사용되는 방식은 Authorization Code Flow다.
특히 웹 서비스와 모바일 앱에서 가장 많이 사용된다.

Authorization Code Flow 전체 흐름

OAuth 2.0의 대표적인 동작 흐름은 다음과 같다.

  1. 사용자가 클라이언트 애플리케이션에 접근
  2. 클라이언트가 Authorization Server로 인증 요청
  3. 사용자가 로그인 및 권한 동의
  4. Authorization Server가 Authorization Code 발급
  5. 클라이언트가 Authorization Code를 사용해 토큰 요청
  6. Authorization Server가 Access Token 발급
  7. 클라이언트가 Access Token으로 Resource Server 접근

이 흐름을 통해 권한이 안전하게 위임된다.

1단계: 인증 및 권한 요청

클라이언트는 사용자를 Authorization Server의 인증 페이지로 리다이렉트한다.
이 요청에는 다음 정보가 포함된다.

  • client_id
  • redirect_uri
  • response_type=code
  • scope

이 단계에서 사용자는 어떤 권한을 허용할지 명시적으로 확인한다.

2단계: 사용자 인증과 동의

사용자는 Authorization Server에서 로그인한다.
로그인이 완료되면, 요청된 권한(scope)에 대한 동의 화면이 표시된다.

이 단계의 핵심은 다음과 같다.

  • 사용자 인증
  • 권한 범위 확인 및 동의

OAuth 2.0은 사용자의 명시적 동의를 중요하게 다룬다.

3단계: Authorization Code 발급

사용자가 동의하면 Authorization Server는 Authorization Code를 발급한다.
이 코드는 redirect_uri를 통해 클라이언트로 전달된다.

Authorization Code는 다음 특징을 가진다.

  • 짧은 유효 시간
  • 1회성 사용

코드 자체로는 자원에 접근할 수 없다.

4단계: Access Token 요청

클라이언트는 Authorization Code를 사용해 Authorization Server에 토큰을 요청한다.
이때 클라이언트 인증 정보가 함께 전달된다.

서버는 코드의 유효성을 검증한 뒤 Access Token을 발급한다.

5단계: Resource Server 접근

클라이언트는 발급받은 Access Token을 사용해 Resource Server에 요청을 보낸다.
Resource Server는 토큰의 유효성과 권한 범위를 검증한 뒤 요청을 처리한다.

이 단계에서 실제 서비스 기능이 수행된다.

Refresh Token의 역할

Access Token이 만료되면 사용자는 다시 로그인하지 않아도 된다.
클라이언트는 Refresh Token을 사용해 새로운 Access Token을 발급받을 수 있다.

이를 통해 다음이 가능해진다.

  • 사용자 경험 개선
  • Access Token 수명 단축
  • 보안 강화

OAuth 2.0을 로그인처럼 사용하는 이유

OAuth 2.0은 본래 인가 프레임워크지만, 인증 결과를 함께 제공하기 때문에 로그인처럼 사용된다.

예를 들면 다음과 같다.

  • Google 로그인
  • GitHub 로그인
  • Kakao 로그인

이 경우 OAuth 2.0 위에 사용자 식별 정보를 추가로 제공하는 방식이 사용된다.

OAuth 2.0 사용 시 자주 발생하는 오해

다음과 같은 오해가 자주 발생한다.

  • OAuth 2.0은 인증 프로토콜이다
  • Access Token은 항상 JWT다
  • OAuth 2.0을 쓰면 보안이 자동으로 해결된다

OAuth 2.0은 구조와 흐름을 올바르게 이해하고 설계해야 효과를 발휘한다.

OAuth 2.0을 언제 사용해야 하는가

OAuth 2.0은 다음과 같은 경우에 적합하다.

  • 외부 서비스와 연동이 필요한 경우
  • 사용자 비밀번호를 직접 다루고 싶지 않은 경우
  • 권한 범위를 제한적으로 위임해야 하는 경우

인증과 인가를 분리해서 설계해야 하는 시스템에서 특히 효과적이다.

정리

OAuth 2.0은 사용자 비밀번호를 노출하지 않고 권한을 위임하기 위한 인가 프레임워크다. Authorization Code Flow는 가장 널리 사용되는 방식으로, 인증과 권한 동의를 분리해 안전한 토큰 기반 접근을 가능하게 한다. 인증과 인가의 차이를 이해한 상태에서 OAuth 2.0의 흐름을 살펴보면, 왜 이런 구조를 가지는지 명확하게 이해할 수 있다.