오픈 인증(OAuth)은 사용자 계정의 로그인이나 비밀번호 없이도 애플리케이션이 사진, 캘린더 또는 소셜 미디어 게시물과 같은 최종 사용자의 보호된 리소스에 액세스할 수 있는 권한을 부여하는 개방형 표준 인증 프레임워크입니다.
사용자에게 "Google로 로그인하시겠습니까?" 또는 "계정 정보에 대한 액세스를 허용하시겠습니까?"라고 묻는 웹사이트 및 타사 애플리케이션이 OAuth의 일반적인 사용 사례입니다. OAuth 프로토콜을 사용하면 사용자는 사용자 자격 증명을 공유하지 않고도 이러한 애플리케이션에 계정 데이터에 대한 액세스 권한을 쉽게 부여할 수 있습니다.
OAuth는 웹 애플리케이션 외에도 API, 서버 측 애플리케이션, OS 네이티브 앱, 모바일 앱 및 디바이스(예: 스마트 TV 및 가전제품)에 대한 리소스 액세스 권한을 부여할 수 있습니다. 경우에 따라 OAuth가 조직 또는 비즈니스 계정을 대신하여 애플리케이션 액세스를 승인할 수 있으므로 사람이 개입하지 않는 경우도 있습니다.
Think 뉴스레터
Think 뉴스레터를 통해 AI, 사이버 보안, 데이터 및 자동화에 대한 선별된 뉴스를 제공하는 보안 리더들과 함께하세요. 받은 편지함으로 직접 제공되는 전문가 튜토리얼과 설명서를 통해 빠르게 배울 수 있습니다. IBM 개인정보 보호정책을 참고하세요.
구독한 뉴스레터는 영어로 제공됩니다. 모든 뉴스레터에는 구독 취소 링크가 있습니다. 여기에서 구독을 관리하거나 취소할 수 있습니다. 자세한 정보는 IBM 개인정보 보호정책 을 참조하세요.
OAuth는 로그인 데이터에 액세스할 수 없도록 하고 다른 민감한 정보에 대한 액세스를 제한함으로써 사용자, 개발자 및 비즈니스에 중요한 액세스 관리 이점을 제공합니다. 또한 사용자 자격 증명 공유에 따른 보안 취약점 없이 애플리케이션이 필요한 계정 정보에 더 쉽게 액세스할 수 있습니다.
OAuth는 안전한 액세스를 단순화함으로써 조직이 가장 큰 보안 문제 중 일부를 해결하는 데 도움을 줄 수 있습니다. 예를 들어, IBM 기업가치연구소(IBV)의 연구에 따르면, 52%의 경영진이 복잡성이 사이버 보안 운영에 대한 가장 큰 장애물이라고 말했습니다.
소규모 소프트웨어 개발자 팀이 2007년에 OAuth 1.0을 출시했습니다. 이 프로토콜의 첫 번째 버전은 사용자가 사용자 이름과 비밀번호를 타사 서비스와 공유해야 하는 웹 기반 인증에 대한 대안으로 설계되었습니다. 그러나 OAuth 1.0은 웹사이트에 대한 권한 부여 흐름만 제공했습니다.
2012년, 인터넷 엔지니어링 태스크 포스(IETF)는 OAuth 2.0을 RFC 6749 및 RFC 6750으로 출시했습니다. RFC(의견 요청)는 인터넷 통신 프로토콜을 설명하는 IETF 문서입니다. RFC 6749는 OAuth 2.0의 핵심 프레임워크이며, RFC 6750은 프레임워크가 액세스 토큰을 사용하는 방법을 정의합니다.
업데이트된 버전의 OAuth는 웹 브라우저를 넘어 애플리케이션, API 및 디바이스에 대한 권한 부여 기능을 포함하도록 프로토콜을 확장했습니다. OAuth 2.0은 OAuth 1.0을 대체하여 현재 업계 표준으로 자리 잡았습니다.
사용자 이름과 비밀번호에 의존하는 다른 프레임워크와 달리 OAuth는 액세스 토큰을 기반으로 하는 인증 프로토콜입니다. 액세스 토큰은 애플리케이션이 액세스할 수 있는 특정 리소스를 결정하는 정보입니다. OAuth 프로토콜은 권한 부여 요청 프로세스의 각 구성 요소가 액세스 토큰을 승인, 정의 및 관리하는 방법을 정의합니다.
OAuth 토큰은 데이터를 안전하게 전송할 수 있기 때문에 일반적으로 JSON 웹 토큰(JWT) 표준을 사용합니다.
OAuth 프레임워크의 기본 구성 요소는 다음과 같습니다.
애플리케이션이 액세스하려는 계정(예: Facebook 또는 Google 계정)을 소유한 최종 사용자입니다. 리소스 소유자는 애플리케이션이 사진이나 개인 데이터 등 해당 계정의 특정 보호된 리소스에 액세스할 수 있도록 동의합니다. 경우에 따라 리소스 소유자는 회사 또는 비즈니스 계정일 수 있습니다.
사용자를 대신하여 보호된 리소스를 저장하는 서버입니다. 리소스 서버는 클라이언트로부터 받은 OAuth 토큰을 수락하고 유효성을 검사한 다음 리소스 소유자가 공개에 동의한 사용자 데이터를 제공합니다.
클라이언트는 액세스를 요청하는 애플리케이션, 웹사이트, API 또는 디바이스입니다. 클라이언트 ID를 제시하여 권한 부여 서버에 권한 부여를 요청합니다. 그런 다음, 리소스 소유자가 동의를 제공하면 클라이언트는 리소스 서버의 보호된 리소스에 액세스하는 데 사용할 수 있는 액세스 토큰을 받습니다.
OAuth 프로토콜을 구동하는 기본 서버입니다. 두 개의 엔드포인트를 운영하여 리소스 서버에 대한 액세스 권한을 부여합니다.
권한 부여 엔드포인트 는 리소스 소유자에게 보호된 특정 리소스에 대한 동의를 제공하라는 메시지를 표시합니다. 그런 다음 토큰 엔드포인트는 OAuth 클라이언트로부터 토큰 요청을 수신하고 리소스에 대한 액세스 권한을 부여하는 새 액세스 토큰을 생성합니다.
범위는 리소스 서버의 보호된 리소스에 대한 액세스 매개변수입니다.
예를 들어 리소스 소유자에게 이메일, 파일 또는 사진과 같은 데이터 액세스에 대한 동의를 요청할 수 있습니다. 범위는 클라이언트의 접근을 해당 항목으로만 제한합니다.
다음은 OAuth 흐름의 작동 방식에 대한 기본 개요입니다.
애플리케이션에 액세스 토큰을 제공하는 절차를 권한 부여 또는 권한 부여 흐름이라고 합니다. 다음과 같은 다양한 유형의 애플리케이션, 디바이스 또는 API에 사용할 수 있는 다양한 권한 부여 유형과 OAuth 흐름이 있습니다.
이 부여 유형은 일반적으로 웹 애플리케이션 및 모바일 앱에 사용됩니다. 권한 부여 코드 흐름에서 권한 부여 서버는 클라이언트에 일회성 권한 부여 코드를 제공합니다. 그런 다음 클라이언트는 해당 권한 부여 코드를 권한 부여 서버의 토큰 엔드포인트에서 액세스 토큰으로 교환할 수 있습니다.
이 흐름은 코드 삽입 공격으로부터 앱을 보호하기 위해 권한 코드 부여에 보안을 추가합니다. 이러한 유형의 공격은 앱을 속여 악성 코드를 실행하여 앱의 작동 방식을 변경하도록 만들 수 있습니다.
PKCE는 액세스 토큰이 발급되기 전에 권한 부여 서버로 클라이언트를 인증하는 '클라이언트 비밀'을 추가합니다. 합법적인 클라이언트만 비밀을 가지고 있기 때문에 악의적인 공격자가 클라이언트로 가장하여 악성 코드를 삽입할 수 없습니다.
이 권한 부여 유형은 자동화된 프로세스, 기계 간 상호 작용 및 마이크로서비스와 같이 사람이 개입하지 않는 상황을 위해 설계되었습니다.
애플리케이션에는 기능을 수행하는 데 필요한 시스템 리소스에 대한 액세스 권한이 부여되지만 최종 사용자 리소스에 대한 액세스 권한은 부여되지 않습니다. 예를 들어 클라이언트 자격 증명을 부여하면 날씨 앱이 API에 액세스하여 최신 일기 예보에 대한 데이터를 검색할 수 있습니다.
이 권한 부여 유형은 JavaScript 웹 애플리케이션에 더 간단한 흐름을 제공합니다. 권한 코드 부여와 달리 암시적 흐름은 액세스 토큰이 발급되기 전에 권한 부여 코드가 필요하지 않습니다.
대신 사용자가 동의하면 액세스 토큰이 리디렉션 URI(Uniform Resource Identifier)에 포함되어 액세스를 요청하는 애플리케이션으로 사용자를 반환합니다. 앱은 URI에서 액세스 토큰을 가져옵니다.
액세스 토큰이 만료된 경우 이 권한 부여 유형은 새 액세스 토큰으로 교환할 수 있는 새로 고침 토큰을 애플리케이션에 제공합니다. 새로 고침 토큰이 없으면 최종 사용자는 애플리케이션이 새 액세스 토큰을 받을 수 있도록 다시 한 번 동의를 제공해야 합니다.
OpenID Connect(OIDC)는 OAuth 2.0을 기반으로 구축된 인증 프로토콜입니다. OpenID Connect가 사용자의 ID를 확인하면 OAuth는 해당 사용자에게 리소스 및 서비스에 액세스할 수 있는 권한을 부여할 수 있습니다.