OAuth
개요
OAuth(Open Authorization)는 사용자의 인증 정보(예: 아이디와 비밀번호)를 공유하지 않고도 제3자 애플리케이션이 사용자 대신 리소스 서버에 접근할 수 있도록 허용하는 오픈 스탠더드 인증 프로토콜입니다. 주로 웹 및 모바일 애플리케이션에서 사용자의 데이터에 안전하게 접근하기 위해 사용되며, 사용자가 자신의 계정 정보를 외부 서비스에 직접 제공하지 않아도 되는 장점이 있습니다.
예를 들어, "Google로 로그인" 또는 "Facebook으로 계속하기"와 같은 기능은 OAuth를 기반으로 동작합니다. 이 프로토콜은 사용자, 클라이언트 애플리케이션, 인증 서버, 리소스 서버 간의 복잡한 상호작용을 정형화하여 보안과 편의성을 동시에 제공합니다.
현재 널리 사용되는 버전은 OAuth 2.0이며, 이전 버전인 OAuth 1.0은 보안상의 한계와 복잡성으로 인해 대부분 대체되었습니다.
OAuth 2.0의 주요 구성 요소
OAuth 2.0은 다음과 같은 네 가지 주요 역할(엔티티)로 구성됩니다:
1. 리소스 소유자 (Resource Owner)
사용자 본인을 의미합니다. 사용자의 데이터(예: 이메일, 프로필 정보, 사진 등)에 접근 권한을 부여할 수 있는 주체입니다.
2. 클라이언트 (Client)
사용자의 데이터에 접근하고자 하는 애플리케이션입니다. 웹 앱, 모바일 앱, 서버 앱 등이 될 수 있습니다.
3. 인증 서버 (Authorization Server)
사용자의 인증을 처리하고 접근 토큰(access token)을 발급하는 서버입니다. 예: Google, GitHub, Kakao 등의 인증 서버.
4. 리소스 서버 (Resource Server)
사용자의 데이터를 보유하고 있으며, 접근 토큰을 검증한 후에 데이터를 제공하는 서버입니다. 예: Google API, GitHub API 등.
OAuth 2.0의 작동 흐름
OAuth 2.0은 여러 가지 권한 부여 유형(Grant Type)을 제공하며, 사용 사례에 따라 적절한 방식을 선택합니다. 가장 일반적인 흐름은 인가 코드 흐름(Authorization Code Flow)입니다.
인가 코드 흐름 (Authorization Code Flow)
- 사용자 요청: 사용자가 클라이언트 앱에서 "Google로 로그인"을 클릭합니다.
- 인가 요청: 클라이언트는 인증 서버로 리다이렉트하여 사용자 인증을 요청합니다.
- 사용자 인증: 사용자가 인증 서버에서 로그인하고 권한을 허용합니다.
- 인가 코드 수신: 인증 서버는 클라이언트에 일회용 인가 코드(Authorization Code)를 리다이렉트 응답으로 전달합니다.
- 토큰 요청: 클라이언트는 인가 코드와 자신의 클라이언트 비밀을 사용해 인증 서버에 접근 토큰을 요청합니다.
- 접근 토큰 발급: 인증 서버는 유효성을 검사한 후 접근 토큰(Access Token)과 필요 시 갱신 토큰(Refresh Token)을 발급합니다.
- 리소스 접근: 클라이언트는 접근 토큰을 사용해 리소스 서버에서 사용자 데이터를 요청합니다.
이 흐름은 보안성이 높아 웹 애플리케이션에서 주로 사용됩니다.
주요 권한 부여 유형 (Grant Types)
| 유형 |
사용 사례 |
설명 |
| Authorization Code |
서버 기반 웹 앱 |
가장 안전한 방식. 인가 코드를 통해 토큰을 교환 |
| Implicit |
단일 페이지 애플리케이션(SPA) |
토큰을 직접 반환. 보안 취약, 점차 대체 중 |
| Client Credentials |
서버 간 통신 |
클라이언트 자체 인증. 사용자 없이 접근 |
| Resource Owner Password Credentials |
신뢰할 수 있는 클라이언트 |
사용자 ID/비밀번호 직접 사용. 보안 위험, 제한적 사용 |
| Refresh Token |
토큰 갱신 |
만료된 접근 토큰을 갱신하기 위한 토큰 |
⚠️ 주의: Implicit과 Password Credentials는 보안상 취약할 수 있어 최신 가이드라인(OAuth 2.1, RFC 6749)에서는 권장하지 않습니다.
보안 고려사항
OAuth는 강력한 보안 프레임워크이지만, 잘못 구현하면 다양한 공격에 노출될 수 있습니다.
- CSRF 공격 방지: 인가 요청 시
state 파라미터를 사용하여 요청 위조를 방지합니다.
- PKCE(Proof Key for Code Exchange): 모바일 및 공개 클라이언트에서 인가 코드를 보호하기 위한 확장 기능.
- HTTPS 필수: 모든 통신은 암호화되어야 하며, 토큰 노출을 방지해야 합니다.
- 토큰 만료 관리: 접근 토큰은 짧은 유효기간을 가지며, 갱신 토큰은 안전하게 저장되어야 합니다.
관련 기술 및 확장
- OpenID Connect (OIDC): OAuth 2.0 위에 구축된 인증 레이어로, 사용자 인증을 위한 표준입니다. ID 토큰(JWT 형식)을 추가하여 "누구인가?"를 확인합니다.
- JWT(JSON Web Token): 접근 토큰으로 자주 사용되며, 자체적으로 정보를 포함할 수 있는 구조입니다.
- OAuth 2.1: OAuth 2.0의 보안 개선 버전으로, PKCE를 필수화하고 위험한 권한 부여 유형을 제거합니다.
참고 자료
관련 문서
이 문서는 정보보안 분야에서 인증 프로토콜의 핵심 기술인 OAuth를 이해하고 안전하게 활용하기 위한 기초 지식을 제공합니다.
# OAuth
## 개요
OAuth(Open Authorization)는 사용자의 인증 정보(예: 아이디와 비밀번호)를 공유하지 않고도 제3자 애플리케이션이 사용자 대신 리소스 서버에 접근할 수 있도록 허용하는 **오픈 스탠더드 인증 프로토콜**입니다. 주로 웹 및 모바일 애플리케이션에서 사용자의 데이터에 안전하게 접근하기 위해 사용되며, 사용자가 자신의 계정 정보를 외부 서비스에 직접 제공하지 않아도 되는 장점이 있습니다.
예를 들어, "Google로 로그인" 또는 "Facebook으로 계속하기"와 같은 기능은 OAuth를 기반으로 동작합니다. 이 프로토콜은 사용자, 클라이언트 애플리케이션, 인증 서버, 리소스 서버 간의 복잡한 상호작용을 정형화하여 보안과 편의성을 동시에 제공합니다.
현재 널리 사용되는 버전은 **OAuth 2.0**이며, 이전 버전인 OAuth 1.0은 보안상의 한계와 복잡성으로 인해 대부분 대체되었습니다.
---
## OAuth 2.0의 주요 구성 요소
OAuth 2.0은 다음과 같은 네 가지 주요 역할(엔티티)로 구성됩니다:
### 1. 리소스 소유자 (Resource Owner)
사용자 본인을 의미합니다. 사용자의 데이터(예: 이메일, 프로필 정보, 사진 등)에 접근 권한을 부여할 수 있는 주체입니다.
### 2. 클라이언트 (Client)
사용자의 데이터에 접근하고자 하는 애플리케이션입니다. 웹 앱, 모바일 앱, 서버 앱 등이 될 수 있습니다.
### 3. 인증 서버 (Authorization Server)
사용자의 인증을 처리하고 접근 토큰(access token)을 발급하는 서버입니다. 예: Google, GitHub, Kakao 등의 인증 서버.
### 4. 리소스 서버 (Resource Server)
사용자의 데이터를 보유하고 있으며, 접근 토큰을 검증한 후에 데이터를 제공하는 서버입니다. 예: Google API, GitHub API 등.
---
## OAuth 2.0의 작동 흐름
OAuth 2.0은 여러 가지 **권한 부여 유형**(Grant Type)을 제공하며, 사용 사례에 따라 적절한 방식을 선택합니다. 가장 일반적인 흐름은 **인가 코드 흐름**(Authorization Code Flow)입니다.
### 인가 코드 흐름 (Authorization Code Flow)
1. **사용자 요청**: 사용자가 클라이언트 앱에서 "Google로 로그인"을 클릭합니다.
2. **인가 요청**: 클라이언트는 인증 서버로 리다이렉트하여 사용자 인증을 요청합니다.
3. **사용자 인증**: 사용자가 인증 서버에서 로그인하고 권한을 허용합니다.
4. **인가 코드 수신**: 인증 서버는 클라이언트에 일회용 **인가 코드**(Authorization Code)를 리다이렉트 응답으로 전달합니다.
5. **토큰 요청**: 클라이언트는 인가 코드와 자신의 클라이언트 비밀을 사용해 인증 서버에 접근 토큰을 요청합니다.
6. **접근 토큰 발급**: 인증 서버는 유효성을 검사한 후 **접근 토큰**(Access Token)과 필요 시 **갱신 토큰**(Refresh Token)을 발급합니다.
7. **리소스 접근**: 클라이언트는 접근 토큰을 사용해 리소스 서버에서 사용자 데이터를 요청합니다.
이 흐름은 보안성이 높아 웹 애플리케이션에서 주로 사용됩니다.
---
## 주요 권한 부여 유형 (Grant Types)
| 유형 | 사용 사례 | 설명 |
|------|---------|------|
| **Authorization Code** | 서버 기반 웹 앱 | 가장 안전한 방식. 인가 코드를 통해 토큰을 교환 |
| **Implicit** | 단일 페이지 애플리케이션(SPA) | 토큰을 직접 반환. 보안 취약, 점차 대체 중 |
| **Client Credentials** | 서버 간 통신 | 클라이언트 자체 인증. 사용자 없이 접근 |
| **Resource Owner Password Credentials** | 신뢰할 수 있는 클라이언트 | 사용자 ID/비밀번호 직접 사용. 보안 위험, 제한적 사용 |
| **Refresh Token** | 토큰 갱신 | 만료된 접근 토큰을 갱신하기 위한 토큰 |
> ⚠️ **주의**: `Implicit`과 `Password Credentials`는 보안상 취약할 수 있어 최신 가이드라인(OAuth 2.1, RFC 6749)에서는 권장하지 않습니다.
---
## 보안 고려사항
OAuth는 강력한 보안 프레임워크이지만, 잘못 구현하면 다양한 공격에 노출될 수 있습니다.
- **CSRF 공격 방지**: 인가 요청 시 `state` 파라미터를 사용하여 요청 위조를 방지합니다.
- **PKCE**(Proof Key for Code Exchange): 모바일 및 공개 클라이언트에서 인가 코드를 보호하기 위한 확장 기능.
- **HTTPS 필수**: 모든 통신은 암호화되어야 하며, 토큰 노출을 방지해야 합니다.
- **토큰 만료 관리**: 접근 토큰은 짧은 유효기간을 가지며, 갱신 토큰은 안전하게 저장되어야 합니다.
---
## 관련 기술 및 확장
- **OpenID Connect (OIDC)**: OAuth 2.0 위에 구축된 **인증 레이어**로, 사용자 인증을 위한 표준입니다. ID 토큰(JWT 형식)을 추가하여 "누구인가?"를 확인합니다.
- **JWT**(JSON Web Token): 접근 토큰으로 자주 사용되며, 자체적으로 정보를 포함할 수 있는 구조입니다.
- **OAuth 2.1**: OAuth 2.0의 보안 개선 버전으로, PKCE를 필수화하고 위험한 권한 부여 유형을 제거합니다.
---
## 참고 자료
- [RFC 6749 - The OAuth 2.0 Authorization Framework](https://tools.ietf.org/html/rfc6749)
- [OAuth.net 공식 사이트](https://oauth.net/)
- [OpenID Connect 공식 사이트](https://openid.net/connect/)
- [Google OAuth 2.0 문서](https://developers.google.com/identity/protocols/oauth2)
---
## 관련 문서
- [OpenID Connect](OpenID_Connect)
- [JWT (JSON Web Token)](JWT)
- [SSO (Single Sign-On)](SSO)
- [PKCE](PKCE)
> 이 문서는 정보보안 분야에서 인증 프로토콜의 핵심 기술인 OAuth를 이해하고 안전하게 활용하기 위한 기초 지식을 제공합니다.