OAuth
📋 문서 버전
이 문서는 2개의 버전이 있습니다. 현재 최신 버전을 보고 있습니다.
OAuth
개요
OAuth(Open Authorization)는 사용자의 인증 정보(예: 아이디와 비밀번호)를 공유하지 않고도 제3자 애플리케이션이 사용자 대신 리소스 서버에 접근할 수 있도록 허용하는 오픈 스탠다드 기반의 인증 프로토콜입니다. 주로 웹 및 모바일 애플리케이션에서 사용자의 데이터에 안전하게 접근하기 위해 사용되며, 사용자가 자신의 계정 정보를 제3자에게 직접 제공하지 않아도 되는 장점이 있습니다.
예를 들어, 어떤 앱에서 "Google로 로그인" 또는 "Facebook 계정으로 계속하기"와 같은 기능을 제공할 때, 내부적으로 OAuth 프로토콜이 사용됩니다. 이 방식은 사용자 인증과 권한 부여를 분리함으로써 보안성을 크게 향상시킵니다.
현재 널리 사용되는 버전은 OAuth 2.0이며, 이전 버전인 OAuth 1.0은 복잡한 암호화 과정과 낮은 유연성으로 인해 점차 사용이 줄어들었습니다.
OAuth 2.0의 주요 구성 요소
OAuth 2.0은 네 가지 주요 역할(엔티티)로 구성됩니다:
| 구성 요소 | 설명 |
|---|---|
| 리소스 소유자 (Resource Owner) | 보호된 리소스(예: 사용자 프로필, 사진 등)의 소유자. 일반적으로 최종 사용자입니다. |
| 클라이언트 (Client) | 사용자의 데이터에 접근하고자 하는 애플리케이션(예: 모바일 앱, 웹 서비스). |
| 인증 서버 (Authorization Server) | 사용자의 인증을 처리하고 액세스 토큰을 발급하는 서버. |
| 리소스 서버 (Resource Server) | 사용자의 데이터를 보유하고 있으며, 액세스 토큰을 검증한 후에 데이터를 제공하는 서버. |
이러한 구성 요소들은 사용자 동의를 기반으로 토큰 기반 접근을 통해 안전한 데이터 공유를 가능하게 합니다.
OAuth 2.0의 인증 흐름 (그랜트 유형)
OAuth 2.0은 다양한 사용 사례에 맞춰 여러 가지 권한 부여 방식(Grant Type)을 제공합니다. 주요 그랜트 유형은 다음과 같습니다.
1. 인가 코드 방식 (Authorization Code Grant)
가장 일반적이고 보안성이 높은 방식으로, 웹 애플리케이션에서 주로 사용됩니다.
sequenceDiagram
사용자->>클라이언트: 로그인 요청
클라이언트->>인증 서버: 인가 요청 (redirect)
인증 서버->>사용자: 로그인 및 동의 화면
사용자->>인증 서버: 인증 및 동의
인증 서버->>클라이언트: 인가 코드 반환
클라이언트->>인증 서버: 인가 코드 + 클라이언트 비밀로 토큰 요청
인증 서버->>클라이언트: 액세스 토큰 발급
클라이언트->>리소스 서버: 액세스 토큰으로 데이터 요청
리소스 서버->>클라이언트: 데이터 제공
이 방식은 인가 코드를 중간에 사용하여 토큰이 직접 URL에 노출되지 않도록 하여 보안을 강화합니다.
2. 임시 토큰 방식 (Implicit Grant)
주로 싱글 페이지 애플리케이션(SPA)에서 사용되며, 서버 사이드가 없는 환경에 적합합니다. 그러나 보안상의 취약점이 있어 현재는 권장되지 않습니다.
- 액세스 토큰이 리디렉션 URI를 통해 직접 브라우저에 전달됨.
- 인가 코드를 거치지 않아 토큰이 로그에 남을 위험이 있음.
3. 클라이언트 자격 증명 방식 (Client Credentials Grant)
클라이언트가 자체적으로 리소스에 접근할 때 사용됩니다. 예: 서버 간 통신.
- 사용자 개입 없이 클라이언트가 자신의 자격 증명(클라이언트 ID/비밀)으로 토큰을 요청.
- 리소스 소유자가 아닌 클라이언트가 권한을 갖는 경우.
4. 리소스 소유자 자격 증명 방식 (Resource Owner Password Credentials Grant)
사용자가 클라이언트에 자신의 아이디와 비밀번호를 직접 제공하는 방식. 보안상 위험하여 제한적으로만 사용됩니다.
- 신뢰할 수 있는 클라이언트(예: 공식 앱)에서만 허용.
- 일반적인 제3자 앱에는 권장되지 않음.
보안 고려사항
OAuth는 보안을 강화하기 위해 설계되었지만, 잘못 구현하면 다양한 공격에 노출될 수 있습니다.
주요 보안 위협
- 토큰 탈취: 액세스 토큰이 네트워크를 통해 노출될 경우, 공격자가 사용자 데이터에 접근할 수 있음.
- 리디렉션 URI 조작: 잘못된 리디렉션 URI를 등록하여 인가 코드를 가로챔.
- CSRF 공격: 인증 과정 중 사용자 의사와 무관하게 인가가 발생할 수 있음.
보안 모범 사례
- PKCE(Proof Key for Code Exchange): 모바일 및 SPA 앱에서 인가 코드를 보호하기 위한 확장 기능.
- HTTPS 사용: 모든 통신은 암호화되어야 함.
- 짧은 유효기간의 토큰 + 리프레시 토큰: 액세스 토큰은 짧게, 리프레시 토큰은 안전하게 저장.
- 범위 기반 접근(Scope): 최소 권한 원칙(Principle of Least Privilege) 적용.
OAuth와 OpenID Connect의 차이
- OAuth 2.0은 권한 부여(Authorization) 프로토콜입니다. 사용자의 데이터에 접근할 수 있는 권한을 부여하는 데 초점.
- OpenID Connect(OIDC)는 OAuth 2.0 위에 구축된 인증(Authentication) 계층입니다. 사용자가 누구인지 확인하는 데 사용되며, ID 토큰(JWT 형식)을 추가로 제공합니다.
즉, OAuth는 "이 앱이 내 데이터를 볼 수 있나요?"에 답하고, OpenID Connect는 "당신이 진짜 김철수 씨 맞나요?"에 답합니다.
관련 기술 및 활용 사례
- SAML, OpenID Connect, JWT 등과 함께 현대 인증 시스템의 핵심 요소로 사용됨.
- 주요 플랫폼: Google, Facebook, GitHub, Microsoft Azure AD 등이 OAuth 2.0을 기반으로 인증을 제공.
- 클라우드 서비스, API 게이트웨이, 마이크로서비스 아키텍처에서 인증 및 권한 부여의 표준으로 자리 잡음.
참고 자료
OAuth는 현대 웹 및 모바일 애플리케이션에서 안전한 사용자 인증과 권한 부여를 가능하게 하는 핵심 기술로, 올바르게 구현될 경우 사용자 경험과 보안성을 동시에 향상시킬 수 있습니다.
이 문서는 AI 모델(qwen-3-235b-a22b-instruct-2507)에 의해 생성된 콘텐츠입니다.
주의사항: AI가 생성한 내용은 부정확하거나 편향된 정보를 포함할 수 있습니다. 중요한 결정을 내리기 전에 반드시 신뢰할 수 있는 출처를 통해 정보를 확인하시기 바랍니다.