OAuth는 사용자의 ID 인증 데이터를 해당 애플리케이션과 공유하지 않고 여러 애플리케이션에 걸쳐 사용자 권한 부여를 확대하기 위한 프로토콜입니다.
이 글을 읽은 후에 다음을 할 수 있습니다:
관련 콘텐츠
인터넷에서 가장 인기 있는 인사이트를 한 달에 한 번 정리하는 Cloudflare의 월간 요약본 theNET를 구독하세요!
글 링크 복사
OAuth는 사용자 인증을 위한 기술 표준입니다. OAuth는 사용자 이름, 비밀번호 등의 실제 사용자 자격 증명을 공유하지 않고 한 서비스에서 다른 서비스로 권한 부여를 전달하기 위한 프로토콜입니다. OAuth를 사용하면 사용자는 한 플랫폼에서 로그인한 다음 다른 플랫폼에서 작업을 수행하고 데이터를 볼 수 있는 권한을 부여받을 수 있습니다.
OAuth를 사용하면 두 애플리케이션이 무엇인지와 관계없이 한 애플리케이션에서 다른 애플리케이션으로 권한 부여를 전달할 수 있습니다. OAuth는 SSO(Single Sign-On) 서비스에서 다른 클라우드 애플리케이션으로 권한 부여를 전달하는 데 사용되는 가장 일반적인 방법 중 하나이지만, 어떠한 두 애플리케이션 간에도 사용할 수 있습니다. OAuth가 가장 널리 사용되는 프로토콜 중 하나이지만, 다른 프로토콜도 이 기능을 수행할 수 있습니다.
집주인이 없을 때 방문자가 집에 와서, 집 주인이 실제 집 열쇠를 보내는 대신 열쇠가 들어 있는 자물쇠함을 열 수 있는 임시 코드를 보낸다고 상상해 보십시오. OAuth도 비슷한 방식으로 작동합니다. OAuth에서 애플리케이션 하나가 사용자의 자격 증명을 보내는 대신 다른 애플리케이션에 권한 부여 토큰을 보내 사용자에게 액세스 권한을 부여합니다.
Alice가 회사의 클라우드 파일 스토리지 애플리케이션에 액세스하려고 한다고 가정해보겠습니다. Alice는 이미 회사의 SSO에 로그인했지만, 그날 파일 스토리지 애플리케이션에 아직 액세스하지 않았습니다. Alice가 파일 저장 애플리케이션을 열면 단순히 그녀를 허용하는 대신 애플리케이션이 Alice의 SSO에서 Alice에 대한 승인을 요청합니다.
이에 대한 응답으로 SSO는 OAuth 인증 토큰을 애플리케이션에 보냅니다. 토큰에는 Alice가 애플리케이션 내에서 가져야 하는 권한에 대한 정보가 포함되어 있습니다. 토큰에는 시간 제한도 있습니다. 일정 시간이 지나면 토큰이 만료되고 Alice는 자신의 SSO에 다시 로그인해야 합니다.
OAuth 토큰은 일반적으로 HTTPS를 사용하여 전송되는데, 이는 토큰이 암호화됨을 의미합니다.OAuth 토큰은 OSI 모델의 계층 7에서 전송됩니다.
OAuth는 사용자에게 권한을 부여하고 한 애플리케이션이 다른 애플리케이션에 대한 부분 액세스를 허용하는 데 모두 사용할 수 있습니다. 사용자가 자주 접하는 사용 사례 중 하나는 앱이 소셜 미디어 플랫폼이나 다른 온라인 계정에 액세스하도록 허용하는 것입니다. Google 사용자 계정은 블로깅 플랫폼, 뉴스 웹 사이트, 다양한 온라인 게임 등의 다양한 소비자 애플리케이션과 통합될 수 있습니다. 이러한 경우 외부 앱이 Google에서 필요한 데이터에 액세스할 수 있도록 OAuth 프로토콜이 막후에서 사용됩니다.
기업의 경우 OAuth의 보다 일반적인 사용 사례는 ID 및 액세스 관리(IAM) 시스템과 관련됩니다. 사용자는 OAuth를 통해 애플리케이션 사용을 승인받을 수 있습니다. 예를 들어 직원은 사용자 이름과 비밀번호를 사용하여 회사의 SSO 시스템에 로그인할 수 있습니다. 이 SSO 시스템을 통해 작업을 수행하는 데 필요한 모든 애플리케이션에 대한 액세스 권한이 부여되고, SSO 시스템은 이러한 앱에 OAuth 인증 토큰을 전달하여 이를 수행합니다.
OAuth는 현재 사용되는 여러 인증 프로토콜 중 하나입니다. 이러한 인증 프로토콜은 사용자 로그인 데이터를 노출하지 않고 애플리케이션 간에 인증 정보를 보내는 방법이 있어야 하므로 필요합니다. 일부 플랫폼에서는 자체 인증 방법을 개발했습니다. 예를 들어 Facebook은 Facebook Connect를 제공합니다.
OAuth 2.0은 OAuth의 최신 버전입니다. OAuth의 첫 번째 버전은 2010년에 출시되었습니다. OAuth 2.0은 2012년에 출시되었으며 OAuth 1.0에 존재하는 여러 취약점을 수정했습니다.
권한 부여와 인증은 비슷하게 들리지만, 액세스 관리 내에서는 완전히 동일하지는 않으며 액세스 관리 기술(OAuth 포함)이 작동하는 방식을 이해하려면 둘의 차이를 아는 것이 아주 중요합니다.인증은 사용자 ID와 관련이 있는 반면, 권한 부여는 사용자 권한과 관련이 있습니다.
Bob이 경비실이 있는 안전한 시설에서 근무한다고 상상해 보세요. 시설에 들어오는 모든 차량은 경비실 앞에서 정차하며 알려진 직원만 출입할 수 있습니다. 경비실은 사용자 인증이 이루어지는 곳입니다. 경비원은 직원 목록을 대조해서 Bob의 신분증을 확인하고 허용된 차량 목록에서 차량 번호판을 확인합니다. 경비실에서 Bob의 신원과 차량을 인증할 수 있으면, Bob은 시설의 주차장에 차를 몰고 가서 주차할 수 있습니다.
그러나 Bob이 시설에 운전해서 들어갈 수 있다고 해서 원하는 곳에 주차할 수 있다는 의미는 아닙니다. 대신 직원 유형별로 지정된 주차장이 있습니다. Bob은 지정된 주차장에만 주차할 수 있습니다. 그는 CEO의 주차 공간에는 주차할 수 없습니다.
OAuth는 승인을 위한 프로토콜입니다. 이 프로토콜에 따라 Bob이 올바른 주차장으로 갈 수 있습니다. 이와는 대조적으로 SAML(Security Assertion Markup Language)은 인증을 위한 프로토콜이거나 Bob이 경비실을 통과하도록 허용합니다.
ID 공급자(IdP) 또는 SSO 서비스는 둘 다 서로 함께 사용하거나 OAuth 단독으로 사용할 수 있습니다(인증을 위해 OAuth를 사용하는 것은 "의사 인증"으로 간주됨).
요약하자면 SAML과 OAuth는 서로 다른 프로토콜이며 서로 다른 용도로 사용되지만, 둘 다 SSO와 함께 사용되는 경우가 많습니다.
Cloudflare Zero Trust는 현재 SSO 서비스와 같은 사용자 인증을 제공하지 않지만, 조직에서 사용자 액세스 및 권한을 관리할 수 있도록 합니다. Cloudflare를 사용하면 가상 사설망(VPN)을 사용하지 않고도 사용자 권한 부여를 관리할 수 있습니다.
Cloudflare Zero Trust는 다양한 SSO 공급자와 통합되며 여러 SSO와도 통합할 수 있으므로 외부 기관 및 계약자에게 시스템 액세스를 더 쉽게 제공할 수 있습니다. 자세히 알아보려면 Cloudflare를 사용하는 다양한 SSO에 대한 블로그 게시물을 읽어보세요.
시작하기
액세스 관리 소개
제로 트러스트 소개
VPN 리소스
용어
학습 센터 탐색