OAuth
📋 문서 버전
이 문서는 3개의 버전이 있습니다. 현재 버전 2을 보고 있습니다.
OAuth
개요
OAuth(Open Authorization)는 사용자의 자격 증명(예: 아이디와 비밀번호)을 공유하지 않고도 제3자 애플리케이션이 사용자의 리소스에 접근할 수 있도록 허용하는 오픈 스탠다드 기반의 인증 프로토콜입니다. 주로 웹 및 모바일 애플리케이션에서 사용자의 데이터에 안전하게 접근하기 위해 사용되며, 사용자가 소셜 로그인(예: "구글로 로그인", "페이스북으로 로그인")을 할 때 뒷단에서 동작하는 핵심 기술입니다.
OAuth는 단순한 인증(Authentication)이 아닌 위임 기반의 권한 부여(Authorization) 프로토콜로, 사용자가 자신의 데이터를 제3자 서비스에 일정 범위 내에서 공유할 수 있도록 허용하는 구조를 제공합니다. 이로 인해 사용자는 비밀번호를 노출하지 않으면서도 편리하게 외부 서비스를 이용할 수 있습니다.
주요 개념
1. 등장 배경
전통적인 인증 방식에서는 사용자가 제3자 애플리케이션에 자신의 아이디와 비밀번호를 직접 제공해야 했습니다. 이는 보안상 큰 위험을 초래하며, 비밀번호 유출 시 여러 서비스가 동시에 위협받는 패스워드 재사용 문제를 야기합니다. OAuth는 이러한 문제를 해결하기 위해 개발되었으며, "접근 토큰(Access Token)" 을 통해 사용자의 자격 증명 없이도 리소스 서버에 접근할 수 있도록 설계되었습니다.
2. 주요 구성 요소
OAuth 프로토콜은 다음과 같은 네 가지 주요 구성 요소로 이루어집니다:
| 구성 요소 | 설명 |
|---|---|
| 리소스 소유자 (Resource Owner) | 사용자 본인. 자신의 데이터(예: 프로필 정보, 사진 등)에 접근 권한을 부여하는 주체입니다. |
| 클라이언트 (Client) | 사용자의 권한을 요청하는 제3자 애플리케이션입니다. 예: 모바일 앱, 웹 서비스 등. |
| 인증 서버 (Authorization Server) | 사용자의 인증을 처리하고 접근 토큰을 발급하는 서버입니다. |
| 리소스 서버 (Resource Server) | 사용자의 데이터를 보유하고 있으며, 접근 토큰을 검증한 후에 데이터를 제공하는 서버입니다. |
OAuth 2.0 주요 흐름
OAuth 2.0은 가장 널리 사용되는 버전으로, 다양한 권한 부여 유형(Grant Types) 을 제공하여 다양한 클라이언트 환경(웹, 모바일, 서버 등)에 대응합니다. 대표적인 흐름은 다음과 같습니다.
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: 접근 토큰(Access Token) 발급
Client->>ResourceServer: 접근 토큰으로 데이터 요청
ResourceServer->>Client: 사용자 데이터 제공
2. 임시 자격 증명 흐름 (Client Credentials Flow)
서버 간 통신에 사용되며, 사용자 대신 클라이언트 자체가 권한을 요청합니다. 예: 백엔드 서비스 간 API 호출.
3. 암시적 흐름 (Implicit Flow)
단일 페이지 애플리케이션(SPA)에서 사용되었으나, 보안상 취약점이 있어 현재는 권장되지 않으며 OAuth 2.1에서 제거될 예정입니다.
4. 리소스 소유자 암호 자격 증명 흐름 (Password Grant)
사용자의 아이디와 비밀번호를 클라이언트가 직접 받는 방식으로, 보안 위험이 크기 때문에 제한적으로만 사용됩니다.
보안 고려사항
OAuth는 강력한 보안 프레임워크이지만, 잘못 구현하면 다음과 같은 위험이 발생할 수 있습니다:
- 토큰 탈취: 접근 토큰이 중간자 공격(MITM)으로 유출될 수 있으므로 HTTPS 사용이 필수입니다.
- CSRF 공격: 인가 요청 시 CSRF 토큰을 사용하여 공격을 방지해야 합니다.
- 리디렉션 URI 조작: 인가 코드가 악의적인 서버로 전달되지 않도록 리디렉션 URI를 사전 등록하고 검증해야 합니다.
- PKCE (Proof Key for Code Exchange): 공개 클라이언트(예: 모바일 앱)에서 인가 코드 재생 공격을 방지하기 위한 확장 기능입니다.
OAuth 2.1 및 OpenID Connect
최근에는 OAuth 2.1이 제안되며, 보안을 강화하고 불필요한 흐름을 제거하고 있습니다. 또한, OAuth는 본질적으로 인증이 아닌 권한 부여 프로토콜이므로, 실제 사용자 인증을 위해 OpenID Connect(OIDC)가 추가로 사용됩니다. OIDC는 OAuth 2.0 위에 구축된 인증 계층으로, ID 토큰(JWT 형식)을 통해 사용자 인증을 수행합니다.
활용 사례
- 소셜 로그인 (Google, Facebook, Naver, Kakao 등)
- API 기반 서비스 간 데이터 공유 (예: 구글 캘린더를 타 앱에서 읽기)
- 기업 내 SSO(Single Sign-On) 시스템 구축
- IoT 기기의 사용자 권한 관리
참고 자료
- RFC 6749 - The OAuth 2.0 Authorization Framework
- RFC 7636 - Proof Key for Code Exchange (PKCE)
- OpenID Connect 공식 사이트
- OAuth Working Group (IETF)
관련 문서
이 문서는 AI 모델(qwen-3-235b-a22b-instruct-2507)에 의해 생성된 콘텐츠입니다.
주의사항: AI가 생성한 내용은 부정확하거나 편향된 정보를 포함할 수 있습니다. 중요한 결정을 내리기 전에 반드시 신뢰할 수 있는 출처를 통해 정보를 확인하시기 바랍니다.