OAuth
📋 문서 버전
이 문서는 3개의 버전이 있습니다. 현재 최신 버전을 보고 있습니다.
OAuth
개요
OAuth(Open Authorization)는 사용자의 인증 정보(예: 아이디와 비밀번호)를 공유하지 않고도 제3자 애플리케이션이 사용자의 리소스에 접근할 수 있도록 허용하는 오픈 스탠다드 인증 프로토콜입니다. 주로 웹 및 모바일 애플리케이션에서 사용자의 데이터에 안전하게 접근하기 위해 사용되며, 사용자가 소셜 로그인(예: "구글로 로그인", "페이스북으로 로그인")을 할 때 뒷단에서 동작하는 핵심 기술입니다.
OAuth는 단순한 인증(Authentication)이 아니라 권한 부여(Authorization) 에 초점을 맞추며, 사용자가 자신의 계정 정보를 노출하지 않으면서도 특정 서비스가 제한된 범위 내에서 데이터를 읽거나 조작할 수 있도록 허용합니다.
주요 개념
1. 등장 배경
전통적인 인증 방식에서는 사용자가 제3자 애플리케이션에 자신의 아이디와 비밀번호를 직접 제공해야 했습니다. 이는 보안상 큰 위험을 초래하며, 비밀번호 유출 시 여러 서비스가 동시에 위협받을 수 있습니다. OAuth는 이러한 문제를 해결하기 위해 개발되었으며, "비밀번호를 공유하지 않고 권한을 위임한다" 는 원칙을 기반으로 합니다.
2. 주요 구성 요소
OAuth 프로토콜은 다음과 같은 주요 구성 요소로 이루어져 있습니다:
- 리소스 소유자 (Resource Owner): 사용자. 자신의 데이터에 대한 접근 권한을 부여하는 주체입니다.
- 클라이언트 (Client): 권한을 요청하는 애플리케이션(예: 모바일 앱, 웹 서비스).
- 인증 서버 (Authorization Server): 사용자의 인증을 처리하고 액세스 토큰을 발급하는 서버.
- 리소스 서버 (Resource Server): 사용자의 데이터를 보유하고 있으며, 액세스 토큰을 검증하여 접근을 허용하는 서버.
OAuth 2.0 주요 흐름
현재 가장 널리 사용되는 버전은 OAuth 2.0이며, RFC 6749에 정의되어 있습니다. 주요 인증 흐름(Grant Type)은 다음과 같습니다.
1. 인가 코드 흐름 (Authorization Code Flow)
가장 일반적이고 보안성이 높은 방식으로, 웹 애플리케이션에 적합합니다.
sequenceDiagram
participant User
participant Client
participant AuthServer
participant ResourceServer
User->>Client: 로그인 요청
Client->>AuthServer: 인가 요청 (redirect)
AuthServer->>User: 로그인 및 동의 화면
User->>AuthServer: 인증 및 승인
AuthServer->>Client: 인가 코드 반환
Client->>AuthServer: 인가 코드 + 클라이언트 비밀로 토큰 요청
AuthServer->>Client: 액세스 토큰 발급
Client->>ResourceServer: 액세스 토큰으로 데이터 요청
ResourceServer->>Client: 데이터 제공
2. 임시 자격 증명 흐름 (Client Credentials Flow)
서버 간 통신에 사용되며, 사용자 대신 클라이언트 자체가 권한을 요청합니다. 예: 백엔드 서비스 간 API 호출.
3. 암시적 흐름 (Implicit Flow)
단일 페이지 애플리케이션(SPA)에서 사용되었으나, 보안상 취약하여 현재는 권장되지 않으며, PKCE(Proof Key for Code Exchange) 와 함께 인가 코드 흐름을 사용하는 것이 표준입니다.
4. 리소스 소유자 암호 자격 증명 흐름 (Password Grant)
사용자의 아이디와 비밀번호를 클라이언트가 직접 받는 방식. 보안 위험이 크므로 제한적으로만 사용되며, 일반적으로 권장되지 않습니다.
보안 고려사항
- 액세스 토큰 보호: 토큰은 민감한 정보이므로 HTTPS를 통해 전송하고, 저장 시 안전한 방법(예: HttpOnly 쿠키)을 사용해야 합니다.
- PKCE 적용: 공개 클라이언트(예: 모바일 앱)에서는 인가 코드 재생 공격을 방지하기 위해 PKCE를 반드시 사용해야 합니다.
- 스코프(Scope) 기반 접근 제어: 클라이언트는 필요한 최소한의 권한만 요청해야 하며, 사용자는 요청된 스코프를 명확히 확인할 수 있어야 합니다.
- 토큰 만료 및 갱신: 액세스 토큰은 짧은 유효기간을 가지며, 리프레시 토큰을 통해 갱신할 수 있습니다.
OAuth와 OpenID Connect의 차이
- OAuth 2.0: 권한 부여 프로토콜. "무엇을 할 수 있는가?"에 초점.
- OpenID Connect (OIDC): OAuth 2.0 위에 구축된 인증 레이어. "누구인가?"를 확인하는 데 사용되며, ID 토큰(JWT 형식)을 통해 사용자 인증을 제공합니다.
즉, OAuth는 인증이 아닌 권한 위임을 위한 것이며, 로그인 기능을 구현하려면 OpenID Connect와 함께 사용하는 것이 일반적입니다.
활용 사례
- 소셜 로그인 (Google, Facebook, GitHub 등)
- API 기반 서비스 간 데이터 공유 (예: 구글 캘린더를 타 앱에서 읽기)
- 마이크로서비스 아키텍처에서의 인증 및 권한 관리
- IoT 기기의 사용자 데이터 접근
참고 자료
- RFC 6749 - The OAuth 2.0 Authorization Framework
- OAuth.net 공식 사이트
- OpenID Connect 공식 사이트
- Google, Microsoft, GitHub 등 주요 플랫폼의 OAuth 2.0 문서
관련 문서
이 문서는 AI 모델(qwen-3-235b-a22b-instruct-2507)에 의해 생성된 콘텐츠입니다.
주의사항: AI가 생성한 내용은 부정확하거나 편향된 정보를 포함할 수 있습니다. 중요한 결정을 내리기 전에 반드시 신뢰할 수 있는 출처를 통해 정보를 확인하시기 바랍니다.