Think Page Title OAuth OAuth(오픈 인증)란 무엇인가요?
IBM의 고급 인증 솔루션 살펴보기 Think 뉴스레터 구독하기
구름, 휴대폰, 지문, 확인 표시의 픽토그램.

게시일: 2024년 7월 29일
기고자: Gregg Lindemulder, Matt Kosinski

오픈 인증(OAuth)이란 무엇인가요?

오픈 인증(OAuth)은 사용자 계정의 로그인이나 비밀번호 없이도 애플리케이션이 사진, 캘린더 또는 소셜 미디어 게시물과 같은 최종 사용자의 보호된 리소스에 액세스할 수 있는 권한을 부여하는 개방형 표준 인증 프레임워크입니다.

사용자에게 "Google로 로그인하시겠습니까?" 또는 "계정 정보에 대한 액세스를 허용하시겠습니까?"라고 묻는 웹사이트 및 타사 애플리케이션이 OAuth의 일반적인 사용 사례입니다. OAuth 프로토콜을 사용하면 사용자는 사용자 자격 증명을 공유하지 않고도 이러한 애플리케이션에 계정 데이터에 대한 액세스 권한을 쉽게 부여할 수 있습니다.

OAuth는 웹 애플리케이션 외에도 API, 서버 측 애플리케이션, OS 네이티브 앱, 모바일 앱 및 디바이스(예: 스마트 TV 및 가전제품)에 대한 리소스 액세스 권한을 부여할 수 있습니다. 경우에 따라 OAuth가 조직 또는 비즈니스 계정을 대신하여 애플리케이션 액세스를 승인할 수 있으므로 사람이 개입하지 않는 경우도 있습니다.

KuppingerCole Access Management Leadership Compass

KuppingerCole이 IBM이 성숙하고 확장 가능하며 안전한 엔터프라이즈 인증 솔루션을 제공하는 선두 주자라고 말하는 이유를 알아보세요.

OAuth가 중요한 이유는 무엇인가요?

OAuth는 로그인 데이터에 액세스할 수 없도록 하고 다른 민감한 정보에 대한 액세스를 제한함으로써 사용자, 개발자 및 비즈니스에 중요한 액세스 관리 이점을 제공합니다. 또한 사용자 자격 증명 공유에 따른 보안 취약점 없이 애플리케이션이 필요한 계정 정보에 더 쉽게 액세스할 수 있습니다.

소규모 소프트웨어 개발자 팀이 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 프로토콜은 권한 부여 요청 프로세스의 각 구성 요소가 액세스 토큰을 승인, 정의 및 관리하는 방법을 정의합니다.

OAuth 토큰은 데이터를 안전하게 전송할 수 있기 때문에 일반적으로 JSON 웹 토큰(JWT) 표준을 사용합니다.

OAuth 프레임워크의 기본 구성 요소는 다음과 같습니다.

  • 리소스 소유자
  • 리소스 서버
  • 고객
  • 권한 부여 서버
  • 범위 지정
리소스 소유자

애플리케이션이 액세스하려는 계정(예: Facebook 또는 Google 계정)을 소유한 최종 사용자입니다. 리소스 소유자는 애플리케이션이 사진이나 개인 데이터 등 해당 계정의 특정 보호된 리소스에 액세스할 수 있도록 동의합니다. 경우에 따라 리소스 소유자는 회사 또는 비즈니스 계정일 수 있습니다.

리소스 서버

사용자를 대신하여 보호된 리소스를 저장하는 서버입니다. 리소스 서버는 클라이언트로부터 받은 OAuth 토큰을 수락하고 유효성을 검사한 다음 리소스 소유자가 공개에 동의한 사용자 데이터를 제공합니다.

고객

클라이언트는 액세스를 요청하는 애플리케이션, 웹사이트, API 또는 디바이스입니다. 클라이언트 ID를 제시하여 권한 부여 서버에 권한 부여를 요청합니다. 그런 다음, 리소스 소유자가 동의를 제공하면 클라이언트는 리소스 서버의 보호된 리소스에 액세스하는 데 사용할 수 있는 액세스 토큰을 받습니다.

권한 부여 서버

OAuth 프로토콜을 구동하는 기본 서버입니다. 두 개의 엔드포인트를 운영하여 리소스 서버에 대한 액세스 권한을 부여합니다.

권한 부여 엔드포인트 는 리소스 소유자에게 보호된 특정 리소스에 대한 동의를 제공하라는 메시지를 표시합니다. 그런 다음 토큰 엔드포인트는 OAuth 클라이언트로부터 토큰 요청을 수신하고 리소스에 대한 액세스 권한을 부여하는 새 액세스 토큰을 생성합니다.

범위

범위는 리소스 서버의 보호된 리소스에 대한 액세스 매개변수입니다.

예를 들어 리소스 소유자에게 이메일, 파일 또는 사진과 같은 데이터 액세스에 대한 동의를 요청할 수 있습니다. 범위는 클라이언트의 접근을 해당 항목으로만 제한합니다.

OAuth 흐름 예시

다음은 OAuth 흐름의 작동 방식에 대한 기본 개요입니다.

  1. Jim(리소스 소유자)은 소셜 미디어 사이트( 클라이언트)가 자신의 이메일 연락처(리소스)에 액세스할 수 있도록 허용하려고 합니다.

  2. 이메일 인증 서버는 Jim에게 이 액세스에 대한 동의를 제공하라는 메시지를 표시합니다.

  3. Jim의 동의를 받은 후 권한 부여 서버는 소셜 미디어 사이트에 액세스 토큰을 제공합니다.

  4. 소셜 미디어 사이트는 Jim의 이메일 계정 정보를 저장하는 리소스 서버에 액세스 토큰을 제공합니다.

  5. 리소스 서버는 액세스 토큰을 인식하고 소셜 미디어 사이트에 Jim의 이메일 연락처에 대한 액세스 권한을 부여합니다. 액세스 토큰에는 Jim의 동의 범위가 포함되기 때문에 소셜 미디어 사이트는 Jim의 계정에서 다른 데이터에 액세스할 수 없습니다.
OAuth 권한 부여 유형

애플리케이션에 액세스 토큰을 제공하는 절차를 권한 부여 또는 권한 부여 흐름이라고 합니다. 다음과 같은 다양한 유형의 애플리케이션, 디바이스 또는 API에 사용할 수 있는 다양한 권한 부여 유형과 OAuth 흐름이 있습니다.

  • 권한 부여 코드
  • 코드 교환을 위한 증명 키(PKCE)
  • 클라이언트 자격 증명
  • 암시적 부여
  • 새로 고침 토큰
권한 부여 코드

이 부여 유형은 일반적으로 웹 애플리케이션 및 모바일 앱에 사용됩니다. 권한 부여 코드 흐름에서 권한 부여 서버는 클라이언트에 일회성 권한 부여 코드를 제공합니다. 그런 다음 클라이언트는 해당 권한 부여 코드를 권한 부여 서버의 토큰 엔드포인트에서 액세스 토큰으로 교환할 수 있습니다.

코드 교환을 위한 증명 키(PKCE)

이 흐름은 코드 삽입 공격으로부터 앱을 보호하기 위해 권한 코드 부여에 보안을 추가합니다. 이러한 유형의 공격은 앱을 속여 악성 코드를 실행하여 앱의 작동 방식을 변경하도록 만들 수 있습니다.

PKCE는 액세스 토큰이 발급되기 전에 권한 부여 서버로 클라이언트를 인증하는 '클라이언트 비밀'을 추가합니다. 합법적인 클라이언트만 비밀을 가지고 있기 때문에 악의적인 공격자가 클라이언트로 가장하여 악성 코드를 삽입할 수 없습니다.

클라이언트 자격 증명

이 권한 부여 유형은 자동화된 프로세스, 기계 간 상호 작용 및 마이크로서비스와 같이 사람이 개입하지 않는 상황을 위해 설계되었습니다.

애플리케이션에는 기능을 수행하는 데 필요한 시스템 리소스에 대한 액세스 권한이 부여되지만 최종 사용자 리소스에 대한 액세스 권한은 부여되지 않습니다. 예를 들어 클라이언트 자격 증명을 부여하면 날씨 앱이 API에 액세스하여 최신 일기 예보에 대한 데이터를 검색할 수 있습니다. 

암시적 부여

이 권한 부여 유형은 JavaScript 웹 애플리케이션에 더 간단한 흐름을 제공합니다. 권한 코드 부여와 달리 암시적 흐름은 액세스 토큰이 발급되기 전에 권한 부여 코드가 필요하지 않습니다.

대신 사용자가 동의하면 액세스 토큰이 리디렉션 URI(Uniform Resource Identifier)에 포함되어 액세스를 요청하는 애플리케이션으로 사용자를 반환합니다. 앱은 URI에서 액세스 토큰을 가져옵니다.

새로 고침 토큰

액세스 토큰이 만료된 경우 이 권한 부여 유형은 새 액세스 토큰으로 교환할 수 있는 새로 고침 토큰을 애플리케이션에 제공합니다. 새로 고침 토큰이 없으면 최종 사용자는 애플리케이션이 새 액세스 토큰을 받을 수 있도록 다시 한 번 동의를 제공해야 합니다.

SSO와 OAuth의 차이점은 무엇인가요?

근본적인 차이점은 싱글사인온(SSO)은 사용자 인증 프로토콜이고 OAuth는 권한 부여 프로토콜이라는 점입니다.

SSO는 종종 ID 공급자(IdP)와 확장 마크업 언어(XML)를 기반으로 하는 보안 검증 마크업 언어(SAML)를 사용하여 사용자 이름과 비밀번호를 통해 사용자의 디지털 ID를 인증합니다.

OAuth는 사용자를 인증하지는 않지만 시스템 리소스에 액세스할 수 있는 권한을 부여합니다. SSO 솔루션은 OAuth를 사용하여 인증된 사용자가 기업 전체의 애플리케이션 및 서비스에 쉽게 액세스할 수 있도록 하는 경우가 있습니다.

OpenID Connect란 무엇인가요?

OpenID Connect(OIDC)는 OAuth 2.0을 기반으로 구축된 인증 프로토콜입니다. OpenID Connect가 사용자의 ID를 확인하면 OAuth는 해당 사용자에게 리소스 및 서비스에 액세스할 수 있는 권한을 부여할 수 있습니다. 

관련 솔루션
IBM Verify

AI를 통해 하이브리드 클라우드 전반에서 고객, 인력 및 권한 있는 ID를 보호하고 관리하세요.

IBM Verify 살펴보기

 IBM Verify (SaaS)

데이터와 애플리케이션에 대한 사용자 액세스에 심층적인 컨텍스트, 인텔리전스 및 보안을 추가하세요.

IBM Verify(SaaS) 살펴보기

IBM API Connect

API에 대한 액세스를 보호, 제어 및 조정하여 심화되는 위협으로부터 API를 보호하세요. 

IBM API Connect 살펴보기
리소스 데이터 유출로 인한 손해 보고서(Cost of a Data Breach)

보안 및 IT 팀이 위험과 잠재적 손실을 더 잘 관리하는 데 도움이 되는 필수 인사이트를 얻으세요.

X-Force Threat Intelligence 인덱스

최신 사이버 공격 전술을 이해하여 사람, 데이터 및 인프라를 더 잘 보호하세요.

인증이란 무엇인가요?

컴퓨터 시스템에서 인증(줄여서 'auth')은 사용자가 본인임을 확인하는 프로세스입니다.

다음 단계 안내

IBM Security Verify는 직원과 고객의 요구 사항을 관리할 수 있는 AI 기반 기능을 제공하는 선도적인 IAM 플랫폼입니다. ID 사일로를 통합하고, ID 기반 공격의 위험을 줄이고, 비밀번호 없는 기능을 포함한 최신 인증을 제공합니다.

Verify 살펴보기 90일 동안 Verify 체험하기