일반적인 SAML 워크플로우는 다음과 같습니다.

• 요청: 사용자가 "로그인" 버튼을 누릅니다.
• 검증: SAML과 아이덴티티 공급업체가 인증을 위해 연결됩니다.
• 로그인: 사용자 이름과 비밀번호 데이터를 입력하는 창이 표시됩니다.
• 토큰 생성: 사용자가 정보를 올바르게 입력하면 SAML 토큰이 서비스 공급업체에게 전송되어 사용자가 서버에 로그인할 수 있게 됩니다.

서비스 공급업체와 브라우저, 그리고 아이덴티티 공급업체는 이러한 워크플로우를 통해 정보를 원활하게 주고받을 수 있습니다. 하지만 정보가 보통 몇 초만에 처리되기 때문에 사용자는 정보 처리에 따른 시간 지연을 느끼지 못합니다.

OAuth (Open Authorization)의 원리

“Auth”는 인증과 권한 인증을 모두 의미할 수 있지만 OAuth 프로토콜에서는 권한 인증을 의미합니다. 이 프로토콜은 서비스 전환 시 권한 인증을 전달하는 데 사용되며, 이러한 과정에서 사용자 이름과 비밀번호를 안전하게 보호합니다.

이를테면 직원 한 명이 평균적으로 하루에 업무용 애플리케이션을 전환하는 횟수가 무려 1,100회에 이르는 환경에서 OAuth는 시간을 대폭 절약할 수 있는 프로토콜입니다. 직원들이 다시 로그인하지 않고 앱 사이에서 전환하고자 하는 경우가 있는데, OAuth는 이러한 전환이 가능합니다.

예를 들어 Google 계정을 활성화하여 사용하는 직원이 한 명 있습니다. 이 직원은 동일한 자격 증명을 사용해 아래 애플리케이션에 저장된 데이터까지 이용할 수 있습니다.

• Hootsuite
• SurveyMonkey
• HotJar
• Microsoft 365
• Salesforce
• Marketo
• Box

직원이 직무를 올바르게 수행하기 위해서는 위의 웹 기반 프로그램이 모두 필요합니다. 하지만 사용자 이름과 비밀번호를 각각 5개씩 만들어서 외워야 하는 것은 쉬운 일은 아닙니다.

그렇다고 같은 사용자 이름과 비밀번호를 재사용하는 것은 보안을 위협하는 요인이 될 가능성이 높습니다. 사이트 한 곳이 침해를 당하면 사용자의 주요 데이터가 모든 플랫폼에서 위험에 노출되어 취약해지기 때문입니다. 첫 번째 자격 증명 세트에서 확인된 검증을 통해 다른 사이트에 로그인하는 것과는 매우 다른 상황입니다.

이러한 툴을 사용하면 Facebook과 같은 회사에게 지나치게 많은 권한을 부여하게 된다며 데이터 마이닝을 우려하는 소비자들도 있습니다. 사용자가 다른 앱이나 사이트에 액세스하기 위해 Facebook 로그인을 선택할 때마다 Facebook은 더욱 많은 고객 인사이트를 얻게 되기 때문입니다. 또한 Facebook의 데이터가 침해되면 해당 사용자가 다른 앱이나 사이트에도 액세스하지 못할 수 있습니다.

그럼에도 불구하고 이러한 툴들은  대부분의 직원들이 시간을 절약할 수 있도록 도움을 주고 있습니다

OAuth 워크플로우는 다음과 같습니다.

• 요청: 사용자가 웹 페이지에서 "로그인" 버튼을 클릭합니다.
• 선택: 클라이언트가 타사 권한 인증 자격 증명을 선택합니다.
• 로그인: 권한 인증 서버가 액세스 토큰을 생성하여 이를 리소스 서버에 전송합니다.
• 연결: 리소스 서버가 토큰을 확인한 후 액세스를 허용합니다.

이러한 과정에서 두 서버가 서로 정보를 주고받습니다. 일반적으로 OAuth는 JWT를 토큰으로 사용하지만 그렇지 않고 JavaScript Object Notation을 사용할 수도 있습니다.

토큰은 생성 방법에 관계없이 항상 인코딩되어 대부분 서명까지 포함되지만 서버 사이에서 전달될 때는 암호화되는 일이 거의 없습니다.

OAuth와 SAML의 비교: 유사점과 차이점

OAuth와 SAML은 모두 상호 운용성을 장려 및 표준화하기 위한 프로토콜입니다.

사람들이 이 두 가지 툴을 사용하는 이유는 끝없이 늘어나는 사용자 이름과 비밀번호로 인해 중요한 리소스에 액세스하지 못하는 일을 사전에 방지하기 위해서입니다. 앱 소유자는 OAuth와 SAML을 통해 온보딩을 쉽게 처리하고 사용자 관리를 위임할 수 있습니다. 관리자의 경우 통합이 빨라지며 인증 및 권한 인증을 중앙화할 수 있습니다.

하지만 두 툴이 처리하는 기능은 다음과 같이 전혀 다릅니다.

• 인증. 인증 프로세스는 사용자의 아이덴티티와 관련이 있습니다. SAML은 집 열쇠와 비슷합니다. 집에 대한 접근을 허용하기 때문입니다.
• 인가 (혹은 권한 부여). 권한 인증 프로세스는 사용자의 권한과 관련이 있습니다. OAuth는 사람이 집 안에서 할 수 있는 일과 할 수 없는 일을 지정하는 규칙과 같습니다.

좀 더 자세하게 알아보기 위해 평일에 회사에 출근한 직원을 예로 들어보겠습니다. 직원은 아침에 출근하여 SAML을 사용해 한 차례 로그인합니다. 로그인 한 번으로 SAML 기반의 모든 애플리케이션에 대한 액세스가 허용됩니다. 이후 애플리케이션 전환을 위해 추가로 클릭해야 할 일은 없습니다.

SAML 또는 OAuth를 사용해야 하는 경우

SAML과 OAuth는 SSO 구현의 기회를 제공할 뿐만 아니라 직원 생산성에도 매우 중요합니다. 엄밀히 말해 서로가 대안이라기 보다는 함께 사용할 수 있는 기술에 더 가깝습니다.

예를 들어 Microsoft 환경에서는 OAuth가 권한 인증을, 그리고 SAML이 인증을 처리합니다. 두 가지를 함께 사용하면 SAML을 통해 환경에 대한 액세스를 허용하고, OAuth를 통해 기밀로 분류된 리소스에 대한 액세스를 허용할 수 있습니다.

또한 두 툴을 모두 제거하는 것도 가능합니다. 예를 들어 일부 웹 페이지에서는 권한 부여나 인증이 필요하지 않을 수도 있습니다.

하지만 디지털 시스템이 구축된 기업이라면 인증 및 권한 인증 시스템이 있어야만 디지털 시스템을 효과적으로 사용할 수 있습니다. 직원들이 하루 일과를 마칠 때까지 회사 시스템에 로그인하여 필요한 리소스로 이동할 수 있어야 하기 때문입니다.

OpenID Connect(OIDC)이란?

앱이나 포털과 같은 소비자용 보조 툴을 개발하고 있다면 OAuth가 중요한 역할을 할 수 있습니다. 시장 고객들은 사용자 이름과 비밀번호를 새로 만들지 않고도 툴에 액세스할 수 있다는 점을 높이 평가할 것입니다. 더욱이 직원들이 SAML을 지원하지 않는 툴을 사용하고 있다면 OAuth가 유용하게 사용될 수 있습니다.

하지만 SAML과 비교해 보고 싶다면 SAML, OAuth 및 OpenID Connect의 차이점을 살펴보는 것이 좋습니다.

Okta솔루션과의 협업

Okta는 매일 사용하는 애플리케이션에 원활하게 인증할 수 있게 해주는 SSO 서비스로 잘 알려져 있습니다. 보안 SSO는 SAML을 프로토콜로 선택해 사용하는 경우가 많지만 Okta는 그 밖에도 Sign-in Widget, Auth SDK(JavaScript 기반 라이브러리), Social Login, 그리고 클라이언트용 Authentication API 등 다양한 옵션을 제공하고 있습니다.

Okta의 사전 구성 아이덴티티 솔루션에 대해 자세히 알아보세요.

참고 자료

A Survey on Single Sign-On Techniques. (2012년). Procedia Technology. 

Employees Switch Apps More Than 1,100 Times a Day, Decreasing Productivity. (2018년 12월). TechRepublic. 

Stop Synching Your Contacts with Facebook. (2019년 8월). Mashable. 

Authentication vs. Authorization. (2018년 9월). Medium.

Authentication vs. Authorization. (2020년 5월). Microsoft. 

Why SAML? (Security Assertion Markup Language). (2018년 7월). Medium.

Understanding Authentication, Authorization, and Encryption. Boston University.