OAuth: 웹 서비스 및 애플리케이션 인증 및 권한 관리의 핵심
현대 웹 서비스 및 애플리케이션 환경에서는 사용자 인증과 권한 관리가 중요한 역할을 한다. OAuth(Open Authorization)는 이러한 요구사항을 충족시키기 위한 표준 인증 프로토콜 중 하나이다. OAuth는 사용자의 인증 정보를 공유하지 않고도 안전하게 리소스에 접근할 수 있는 방법을 제공한다.
정의
OAuth는 웹 서비스 및 애플리케이션에서 사용자의 권한을 위임하고, 다른 서비스 또는 애플리케이션에 대한 접근 권한을 부여하기 위한 프로토콜이다. OAuth는 사용자의 비밀번호를 공유하지 않고, 대신 액세스 토큰을 사용하여 권한을 관리한다. 이를 통해 사용자의 보안과 개인 정보 보호를 강화하며, 다른 서비스 간에 안전한 데이터 공유를 가능하게 한다.
역할
OAuth의 주요 역할은 다음과 같다.
- 인증: OAuth는 클라이언트 애플리케이션이 사용자를 대신하여 인증 서버(Provider)에 요청하여 사용자의 신원을 확인한다.
- 토큰 발급: 사용자가 인증되면 인증 서버는 클라이언트에게 액세스 토큰(Access Token)을 발급한다. 이 토큰은 사용자가 특정 리소스에 접근할 수 있도록 하는 역할을 한다.
- 권한 부여: 사용자는 클라이언트 애플리케이션에 대한 권한을 부여하고, 클라이언트 애플리케이션은 해당 권한을 사용하여 리소스에 접근할 수 있다.
- 액세스 제어: OAuth는 사용자가 어떤 리소스에 대한 액세스를 허용하거나 거부하는 데 사용된다. 사용자는 언제든지 앱의 액세스를 취소할 수 있다.
OAuth의 원리는 다음과 같다.
- 사용자 인증: 클라이언트 애플리케이션은 사용자를 인증 서버로 리디렉션한다.
- 권한 부여: 사용자는 클라이언트 애플리케이션이 어떤 권한을 요청하는지 확인하고 권한을 부여한다.
- 액세스 토큰 발급: 인증 서버는 클라이언트에게 액세스 토큰을 발급한다.
- 액세스 토큰을 사용한 리소스 액세스: 클라이언트 애플리케이션은 액세스 토큰을 사용하여 보호된 리소스에 접근한다.
예시 및 보조개념
위의 나왔지만 다시 한번 프로세스를 강조해 설명해본다. OAuth 프로세스는 다음과 같은 단계로 진행된다.
- 사용자 인증 요청: 클라이언트 애플리케이션은 사용자를 인증 서버로 리디렉션한다.
- 사용자 로그인: 사용자는 인증 서버에 로그인하여 자신의 신원을 확인한다.
- 권한 부여: 사용자는 클라이언트 애플리케이션이 어떤 권한을 요청하는지 확인하고 권한을 부여한다.
- 액세스 토큰 발급: 인증 서버는 클라이언트에게 액세스 토큰을 발급한다.
- 액세스 토큰을 사용한 리소스 액세스: 클라이언트 애플리케이션은 액세스 토큰을 사용하여 보호된 리소스에 접근한다.
간단 프로세스
(1. 사용자에게 권한 요청 및 동의를 받는다. 그러면 authrization code를 획득.)
(2. authorization code를 가지고 구글에게 access token을 요청.)
(3. 발급 받은 access token을 가지고 사용자의 구글 계정에 대해 구글 api를 사용.)
OAuth 인프라 구조는 다음과 같은 세 가지 주요 구성 요소로 구성된다.
- 클라이언트 애플리케이션: 사용자가 리소스에 액세스하려고 하는 애플리케이션
- 인증 서버: 사용자의 신원을 확인하고 액세스 토큰을 발급하는 서버
- 리소스 제공자: 보호된 리소스를 보유하고 있는 서버
- 인증: 리소스에 접근 자격이 있는지 검증하는 과정이다. OAuth에서 리소스는 보호된 정보를 의미한다.
- 인가: 자원에 접근할 권한을 부여하는 과정이다. 인가가 완료되면 리소스의 접근 권한 정보가 있는 액세스 토큰을 클라이언트에게 보내준다.
- 액세스토큰: 리소스 서버에서 리소스 소유자의 보호된 정보를 획득할 때 사용하는 만료 기간이 있는 토큰이다.
- 리프레시 토큰: 액세스 토큰이 만료되었을 때 갱신하는 용도로 사용하는 토큰이다. 액세스 토큰보다 만료 기간을 길게 가져간다.
- 리소스소유자(resource owner): 리소스는 사용자의 보호된 정보를 말하며 이런 정보에 접근하도록 자격을 부여하는 사람을 말한다. 즉 ‘OAuth에서는 사용자가 리소스 소유자다’라고 생각하면 된다
이러한 구성 요소는 다음과 같은 방식으로 상호 작용한다.
- 클라이언트 애플리케이션은 사용자가 리소스에 액세스하려고 할 때 사용자를 인증 서버로 리디렉션한다.
- 인증 서버는 사용자의 신원을 확인하고 액세스 토큰을 발급한다.
- 클라이언트 애플리케이션은 액세스 토큰을 사용하여 보호된 리소스에 접근한다.
OAuth 인프라 구조는 다양한 방식으로 구현될 수 있다. 다음은 몇 가지 일반적인 구현 방법이다.
- 자체 호스팅: 클라이언트 애플리케이션, 인증 서버, 리소스 제공자를 모두 자체적으로 호스팅한다.
- 클라우드 기반: 클라이언트 애플리케이션과 인증 서버를 클라우드 기반 서비스로 호스팅하고, 리소스 제공자는 온프레미스 또는 클라우드에 위치할 수 있다.
- 하이브리드: 클라이언트 애플리케이션과 인증 서버는 클라우드 기반 서비스로 호스팅하고, 리소스 제공자는 온프레미스에 위치할 수 있다.
OAuth 인프라 구조를 선택할 때 고려해야 할 요소는 다음과 같다.
- 보안: 인프라는 사용자의 데이터를 안전하게 보호할 수 있어야 한다.
- 확장성: 인프라는 요구 사항에 따라 확장할 수 있어야 한다.
- 비용: 인프라의 구현 및 유지 관리 비용을 고려해야 한다.
활용
OAuth는 다음과 같은 다양한 분야에서 활용된다.
- 소셜 미디어 로그인: 웹 사이트 및 앱은 사용자가 소셜 미디어 계정을 통해 로그인하고, 사용자의 프로필 정보 및 친구 목록에 접근하기 위해 OAuth를 사용한다.
- API 접근 제어: 웹 서비스 및 애플리케이션은 OAuth를 사용하여 다른 서비스의 API에 접근하고, 사용자의 데이터를 안전하게 공유한다.
- 클라우드 서비스 인증: 클라우드 기반 서비스는 OAuth를 사용하여 사용자가 자신의 계정으로 다른 서비스에 연결하고 데이터를 동기화할 수 있게 한다.
- 단일 로그인(SSO): 기업 및 기관은 OAuth를 사용하여 사용자가 여러 애플리케이션에 단일 로그인으로 접근할 수 있는 단일 로그인 솔루션을 구축한다.
취약점
OAuth는 안전한 인증 및 권한 관리 프로토콜이지만, 여전히 취약점으로부터 자유롭지는 않다. OAuth의 취약점은 다음과 같다.
- 권한 부여 프로세스의 취약점: 권한 부여 프로세스는 OAuth의 핵심 단계다. 이 프로세스 중에 사용자는 클라이언트 애플리케이션에 대한 권한을 부여한다. 이때 사용자가 잘못된 결정을 내리거나, 공격자가 사용자를 속여서 권한을 부여하도록 할 수 있다.
- 토큰 관리의 취약점: OAuth는 토큰을 사용하여 권한을 관리한다. 토큰이 손상되거나 유출되면 공격자가 이를 사용하여 리소스에 무단으로 액세스할 수 있다.
-
- 클라이언트 애플리케이션의 취약점: OAuth는 클라이언트 애플리케이션이 올바르게 구현되어야 합니다. 클라이언트 애플리케이션에 취약점이 있으면 공격자가 이를 악용할 수 있다.
-
- 인증 서버의 취약점: OAuth는 인증 서버를 사용하여 사용자의 신원을 확인한다. 인증 서버에 취약점이 있으면 공격자가 이를 악용하여 사용자의 계정에 액세스할 수 있다.
-
OAuth의 취약점을 방지하기 위해 다음과 같은 조치를 취할 수 있다.
- 권한 부여 프로세스를 주의 깊게 설계하고 구현한다. 사용자는 클라이언트 애플리케이션에 대한 권한을 부여하기 전에 해당 권한이 무엇을 의미하는지 이해해야 한다.
- 토큰을 안전하게 관리한다. 토큰은 암호화하고, 안전한 저장소에 보관하고, 정기적으로 교체해야 한다.
- 클라이언트 애플리케이션을 안전하게 개발한다. OAuth 표준을 준수하고, 보안 취약점을 식별하고 수정하기 위한 프로세스를 수립한다.
- 인증 서버를 안전하게 유지 관리한다. 최신 보안 패치를 적용하고, 인증 서버에 대한 액세스를 제한한다.
OAuth는 잘 구현되면 안전한 인증 및 권한 관리 프로토콜이다. 그러나 OAuth의 취약점을 인식하고 이를 방지하기 위한 조치를 취하는 것이 중요한다.
실제 예시
또한, 실제 예시를 살펴보자
APT29가 OAuth를 악용한 공격을 통해 마이크로소프트와 HPE를 공격한 것은 OAuth의 취약점을 잘 보여주는 사례이다.
OAuth의 취약점은 크게 다음과 같이 세 가지로 나눌 수 있다.
- 권한 부여 프로세스의 취약점: APT29는 유출된 사용자 계정을 사용해 OAuth 애플리케이션을 생성하고 조작했다. 이 애플리케이션은 높은 권한을 부여하고 악의적인 활동을 숨기는 데 활용되었다. 권한 부여 프로세스가 잘 설계되지 않으면 공격자가 악성 애플리케이션에 대한 권한을 부여하도록 사용자를 속일 수 있다.
- 토큰 관리의 취약점: APT29는 유출된 OAuth 토큰을 사용하여 마이크로소프트의 기업 환경에 접근했다. 토큰이 손상되거나 유출되면 공격자가 이를 사용하여 리소스에 무단으로 액세스할 수 있다. 토큰을 안전하게 관리하지 않으면 공격자가 토큰을 탈취할 수 있다.
- 클라이언트 애플리케이션의 취약점: APT29는 레거시 테스트 OAuth 애플리케이션을 손상시켜 악성 애플리케이션을 추가로 만들었다. 이 애플리케이션은 오피스 365 익스체인지 온라인 앱 역할을 부여하고 사서함에 대한 액세스 권한을 제공했다. 클라이언트 애플리케이션이 올바르게 구현되지 않으면 공격자가 이를 악용할 수 있다.
비슷한 도구
OAuth와 유사한 인증 및 권한 관리 프로토콜로는 OpenID Connect, SAML(Security Assertion Markup Language), JWT(Json Web Tokens) 등이 있습니다. 이러한 프로토콜은 다양한 사용 사례와 요구 사항을 고려하여 선택되고 사용된다.
'보안' 카테고리의 다른 글
사기 메일로부터 안전하게 보호하는 방법 (0) | 2024.02.13 |
---|---|
버그바운티 다양한 공격 심층 분석 및 취약점 예방 가이드 (1) | 2024.02.06 |
char() , varchar()-- char() 취약점 (0) | 2023.11.06 |
CSP는 무엇인가 (0) | 2023.10.22 |
UTM ? 알아볼게요 (0) | 2023.10.21 |