Post

OAuth 2.0

Posted Updated
Preview Image
By Yehoon Lee 8 min read

OAuth 2.0이란?

웹 애플리케이션이나 모바일 애플리케이션에서 사용자 자원을 안전하게 액세스하기 위한 권한 부여 프레임워크

OAuth 2.0의 주요 요소

  1. Resource Owner (자원 소유자)
    • 데이터를 소유하고 그에 대한 접근 권한을 부여할 수 있는 주체
  2. Client (클라이언트)
    • Resource Owner의 데이터에 대한 접근을 요청하는 애플리케이션 또는 서비스
  3. Authorization Server (권한 서버)
    • Resource Owner를 인증하고 Client에게 Access Token을 발급하는 서버
  4. Resource Server (자원 서버)
    • 사용자의 데이터를 보유한 서버
  5. Access Token (접근 토큰)
    • Client가 Resource Owner를 대신하여 Resource Server에 접근하는 데 사용하는 토큰

OAuth 2.0의 주요 단계

  1. Authorization Grant (권한 부여)
    • Client가 Resource Owner의 권한을 얻기 위해 Authorization Server에 요청
      • 이를 통해 얻은 권한 부여 코드를 사용하여 Access Token을 요청할 수 있음
    • 주요 권한 부여 유형
      • Authorization Code
        • 가장 안전하고 일반적으로 사용되는 흐름
        • Client는 사용자를 Authorization Server로 리디렉션하며, 사용자는 로그인하고 접근을 승인함
        • Authorization Server는 사용자를 Client로 다시 리디렉션하며 권한 코드를 제공함
        • Client는 이 코드를 Access Token으로 교환함
      • Implicit
        • Client 코드가 브라우저에서 실행되는 싱글 페이지 애플리케이션(SPA)에 사용됨
        • Access Token이 중간 권한 코드 없이 직접 Client에게 반환됨
        • 토큰이 사용자 에이전트에 노출되므로 보안성이 낮음
      • Resource Owner Password Credentials
        • Client가 직접 Resource Owner의 자격 증명(사용자 이름과 비밀번호)을 수집함
        • Client가 매우 신뢰할 수 있을 때 사용되지만 자격 증명이 Client에 노출되므로 보안성이 낮음
      • Client Credentials
        • Client가 사용자를 대신하지 않고 자신의 자원에 접근할 때 사용됨
        • Client가 Authorization Server에 자신을 인증하고 직접 Access Token을 얻음
  2. Access Token:
    • Authorization Server에서 발급된 토큰으로, Client가 Resource Server에 접근할 때 사용됨
    • 이 토큰은 일정 시간 동안 유효함
  3. Refresh Token (리프레시 토큰):
    • Access Token이 만료되었을 때 새로운 Access Token을 발급받기 위해 사용됨
    • 주로 장기적인 세션을 유지하기 위해 사용됨

OAuth 2.0의 흐름

1. Authorization Code Grant (인가 코드 부여 방식)

시나리오: 타사 웹 애플리케이션이 사용자의 구글 드라이브 파일에 접근하려고 할 때

  1. Authorization Request:
    • Client(타사 애플리케이션)는 사용자를 구글의 Authorization Server로 리디렉션하여 권한 요청을 함
    • 사용자에게 로그인 및 권한 부여 화면이 표시됨
  2. Authorization Grant:
    • 사용자가 권한을 승인하면, Authorization Server는 Client에게 권한 부여 코드를 반환함
  3. Access Token Request:
    • Client는 이 권한 부여 코드를 사용하여 Authorization Server에 Access Token을 요청함
  4. Access Token Response:
    • Authorization Server는 Access Token을 Client에게 발급함
  5. Resource Request:
    • Client는 이 Access Token을 사용하여 구글 드라이브 API를 통해 파일에 접근함

2. Implicit Grant (암시적 부여 방식)

시나리오: 단일 페이지 애플리케이션이 사용자의 페이스북 프로필에 접근하려고 할 때

흐름:

  1. Authorization Request:
    • Client(단일 페이지 애플리케이션)는 사용자를 페이스북의 Authorization Server로 리디렉션하여 권한 요청을 함
    • 사용자에게 로그인 및 권한 부여 화면이 표시됨
  2. Authorization Grant:
    • 사용자가 권한을 승인하면, Authorization Server는 Client에게 직접 Access Token을 반환함 (권한 부여 코드 생략)
  3. Resource Request:
    • Client는 이 Access Token을 사용하여 페이스북 API를 통해 사용자 프로필에 접근함

3. Resource Owner Password Credentials Grant (Resource Owner 비밀번호 자격 증명 부여 방식)

시나리오: 모바일 애플리케이션이 사용자의 자체 백엔드 서버에 접근하려고 할 때

흐름:

  1. Password Credentials Request:
    • 사용자는 Client(모바일 애플리케이션)에 자신의 사용자명과 비밀번호를 직접 입력함
  2. Access Token Request:
    • Client는 이 사용자명과 비밀번호를 사용하여 Authorization Server에 Access Token을 요청함
  3. Access Token Response:
    • Authorization Server는 Access Token을 Client에게 발급함
  4. Resource Request:
    • Client는 이 Access Token을 사용하여 백엔드 서버의 자원에 접근함

4. Client Credentials Grant (Client 자격 증명 부여 방식)

시나리오: 서버-간 통신에서 Client가 자체적으로 API에 접근할 때

흐름:

  1. Access Token Request:
    • Client는 자신의 Client ID와 비밀번호를 사용하여 Authorization Server에 Access Token을 요청함
  2. Access Token Response:
    • Authorization Server는 Access Token을 Client에게 발급함
  3. Resource Request:
    • Client는 이 Access Token을 사용하여 다른 서버의 보호된 자원에 접근함

보안 고려 사항

  • Token Expiry(토큰 만료) 및 Refresh Tokens
    • Access Token은 보통 수명이 짧음
    • Refresh Token을 사용하여 사용자 개입 없이 새로운 Access Token을 얻을 수 있음
  • Scope (범위)
    • 클라이언트가 접근할 수 있는 Resource Owner의 데이터 부분을 정의
  • Redirect URI Validation (리디렉트 URI 검증)
    • Authorization Server가 피싱을 방지하기 위해 미리 등록된 URI로만 리디렉션하도록 함
  • State Parameter (상태 매개변수)
    • 요청과 콜백 사이의 상태를 유지하여 교차 사이트 요청 위조(CSRF) 공격으로부터 보호함
Backend
Authentication
This post is licensed under CC BY 4.0 by the author.