CIAM 101: 인증, 정체성, SSO
Logto는 여러 가지 이유로 CIAM에서 시작했습니다 (이에 대해 이야기할 다른 글이 있을 것입니다). 개발 중에 우리는 팀 전체에 통합된 이해를 구축하는 것이 우리 제품을 다음 수준으로 끌어올리기 전에 유익하다는 것을 깨달았습니다. 이것이 IAM의 전반적인 모습을 더 잘 이해하는 데 도움이 되기를 바랍니다.
Logto는 여러 가지 이유로 CIAM에서 시작했습니다 (이에 대해 이야기할 다른 글이 있을 것입니다). 개발 중에 우리는 팀 전체에 통합된 이해를 구축하는 것이 우리 제품을 다음 수준으로 끌어올리기 전에 유익하다는 것을 깨달았습니다. 이것이 IAM의 전반적인 모습을 더 잘 이해하는 데 도움이 되기를 바랍니다.
아이덴티티 및 접근 관리 (IAM)가 시간이 지남에 따라 점점 더 복잡하고 확장되었다는 것을 깨닫고 Logto를 구축하기 시작했습니다. IAM의 개념은 WIAM (Workforce IAM) 및 CIAM (Customer IAM)과 같은 새로운 개념을 탄생시키기에 충분히 거대합니다.
WIAM과 CIAM은 같은 기초를 공유하지만, 각기 다른 사용 사례를 가지고 있습니다. WIAM은 일반적으로 내부 사용자용으로 사용되며, CIAM은 외부 고객용으로 사용됩니다.
몇 가지 예시:
개발 중에 우리는 팀 전체에 통합된 이해를 구축하는 것이 제품을 다음 단계로 끌어올리기 전에 유익하다는 것을 깨달았습니다. 이것이 IAM의 전반적인 모습을 더 잘 이해하는 데 도움이 되기를 바랍니다.
시작해 봅시다!
이 문서에서는 CIAM의 기본 개념과 인증 흐름 전후에 발생할 수 있는 문제들을 중점적으로 다루겠습니다. 또한 싱글 사인온(SSO)과 관련된 시나리오에 대해서도 논의할 것입니다.
💡 인증은 처음에는 "누구입니까?"로 정의되었지만, 디지털 정체성을 논할 때, 인증을 "정체성 소유권 증명"으로 설명하는 것이 더 정확합니다. (Calm-Card-2424에게 공을 돌립니다)
이 두 카테고리에 속하지 않는 것을 발견하면, 그것은 아마도 정체성 비즈니스에 필수적이지 않을 것입니다.
정체성은 일반적으로 사용자나 기계를 나타냅니다. 인증이 성공적으로 이루어지면 ID 토큰이 정체성으로 발급됩니다.
다시 말해, 인증의 주된 목적은 정체성을 획득하는 것입니다.
테넌트는 정체성들의 그룹입니다:
"다중 테넌트"를 논할 때 우리는 서로 정체성이 격리된 다수의 Logto 인스턴스를 언급하고 있습니다. 즉, 여러 Logto 인스턴스입니다.
Tenant 1의 정체성을 Tenant 2에서 사용할 수 없습니다. 마치 코스트코 회원권이 Whole Foods에서 유효하지 않은 것과 같습니다.
정체성과 마찬가지로, 앱도 테넌트 소속입니다. 기억해야 할 몇 가지 사항:
이 두 제공자 간의 차이는 까다롭지만 중요합니다.
Google에서 Service Provider에 대해 다양한 설명을 찾을 수 있지만 만족스럽지 않을 수 있습니다. 제 생각에 Service Provider는 상대적인 개념입니다:
일반적인 소셜 로그인 시나리오를 고려해 봅시다:
❓ 이 그래프에서 몇 개의 Service Providers와 Identity Providers가 있을까요?
답변
둘 다 두 개 있습니다. iOS 앱은 Logto에 대한 서비스 제공자이며, Logto는 정체성 제공자입니다. Logto는 GitHub에 대한 서비스 제공자이자 정체성 제공자입니다. 따라서 Logto는 서비스 제공자이면서 정체성 제공자입니다.
당신은 기술 솔루션 회사의 CTO이며, 100개 이상의 비즈니스 파트너를 보유하고 있으며 300개 이상의 프로젝트를 완료했습니다.
❓ Logto (또는 CIAM 제품)가 어떻게 도울 수 있을까요?
각 비즈니스 파트너마다 Logto 인스턴스를 만드세요. 각 파트너는 테넌트를 보유합니다. 프로젝트는 Logto의 "앱"으로 매핑됩니다.
Logto는 테넌트 내에서 보편적인 로그인 경험 (즉, SSO)를 제공합니다, 따라서 사용자가 이미 로그인했던 동일한 테넌트의 다른 앱에 접근할 때 다시 로그인할 필요가 없습니다.
“SSO”라는 용어가 자주 혼란을 야기하는 것을 발견했습니다. 우리는 싱글 사인온(SSO)을 행동으로 간주하며, 비즈니스 개념으로 보지 않습니다. 따라서 SSO는 “WIAM의 SSO”와 동일하지 않습니다.
“SSO가 필요하다”고 말할 때, 이는 다음과 같은 경우 중 하나를 의미할 수 있습니다:
👉🏽 대기업에서 직원들은 모든 회사 승인된 리소스 (예: 이메일, IM, 클라우드 서비스)에 같은 자격 증명을 사용하여 로그인합니다.
이는 전형적인 WIAM 시나리오입니다. 이 경우, 단일 Identity Provider만 참여합니다. 지금은 이것에 신경 쓸 필요가 없습니다.
👉🏽 최종 사용자가 같은 회사를 통해 개발된 모든 서비스 (예: GSuite)에 같은 자격 증명을 사용하여 로그인합니다.
Logto는 현재 위에서 설명한 접근법에 집중하고 있습니다. Facebook과 같은 제3자 소셜 로그인 제공자와 같은 외부 IdP가 여러 개 있을 수 있지만, 이들은 독립적이며 연결되지 않을 수 있습니다.
그럼에도 불구하고, Logto는 아이덴티티에 대한 단일 진실의 근원으로 남으며, 단순히 다른 제공자로부터 "빌린다"라고 할 수 있습니다. 이 경우, Logto는 GSuite 앱에 대해 Identity Provider로 작용하고, 외부 IdP에 대해서는 Service Provider로 작용합니다.
👉🏽 최종 사용자는 해당 이메일 도메인 내에서 특정 IdP를 사용하여 인증을 완료할 수 있습니다. 예를 들어, Google Workspace를 통한 Figma 로그인.
이는 CIAM에서 SSO에 대한 가장 일반적인 사용 사례입니다. 좀 더 자세히 살펴보겠습니다.
silverhand.io 이메일을 사용하여 Figma에 로그인하고자 한다면, 소셜 로그인이나 SSO를 사용할 수 있습니다. 아래 그림은 두 간의 차이를 보여줍니다:
소셜 로그인
SSO
말로 설명하자면:
이 경우, Logto는 IdP와 SP 역할을 모두 수행합니다. SSO는 일반적인 로그인 프로세스보다 복잡한 것 같습니다. 아이덴티티 소유자에게 어떤 이점이 있을까요?
🤔 똑똑한 너는 이것이 사실상 SaaS의 관점에서 SSO 사례 1인 것을 알아챘을 것입니다.
SSO 그래프에서 "X"에 대해 논의할 시간입니다. 이것은 Figma가 이메일 도메인을 특정 IdP에 연결하는 과정을 의미합니다. 그러나 이것이 어떻게 작동할까요?
요청은 종종 기업 고객으로부터 오므로, 이전 섹션의 "SSO 사례 3"를 "Enterprise SSO"라고 부릅니다.
우리는 쉽게 순진한 해결책을 고안할 수 있습니다: 이메일 도메인과 SSO 방법 간의 매핑을 만들고 수동으로 업데이트합니다.
과정 “X”의 동작은 이제 분명합니다:
🔍 주어진 이메일 도메인에 대한 매핑된 Enterprise SSO 방법을 찾으세요
따라서 silverhand.io를 Google Workspace SSO URL과 연결된 유효한 이메일 도메인으로 구성하면, @silverhand.io 이메일로 로그인하려는 사용자는 해당 Google Workspace 로그인 페이지로 리다이렉트됩니다.
수십 개의 클라이언트만 Enterprise SSO가 필요할 때는 수동으로 매핑을 관리해도 괜찮습니다. 그러나 다음을 더 고려해야 합니다:
그리고 더 많은 것들이 있습니다. 거의 모든 Enterprise SSO가 이메일 도메인 기반이므로, 우리는 더 나은 해결책을 빠르게 생각해낼 수 있습니다:
이 해결책은 첫번째 두 질문을 해결합니다:
1. Enterprise SSO 클라이언트가 수 백 혹은 수 천개가 있다면 어떻게 해야 하나요?
2. “일반 사용자”와 “Enterprise SSO 사용자”는 어떤 관계인가요?
세 번째 질문에 대해:
3. 다른 Enterprise SSO 클라이언트 간에 데이터를 격리해야 하나요?
특정 Enterprise SSO 방법을 사용할 도메인을 인식하기 위해 이메일 도메인을 사용한다고 언급했습니다; 다시 말해, 특정 사용자 그룹에 대해 특별 처리를 적용하는 것입니다.
그러나 클라이언트의 요구사항은 종종 단순히 Enterprise SSO를 넘어서 있습니다; 예를 들어, 전 섹션의 질문 4와 5처럼 말입니다. 수년간 뛰어난 SaaS 회사들이 이러한 종류의 문제를 해결하기 위해 성숙한 모델을 개발해왔습니다: 조직.
조직 규칙
"워크스페이스", “팀”, 혹은 심지어 "테넌트"와 같은 다른 용어를 소프트웨어에서 볼 수 있습니다. 우리가 논의하는 개념인지 확인하려면 그것이 "정체성 그룹"을 나타내는지 확인하세요.
이 글에서는 일관성을 위해 "조직"이라는 용어를 사용하겠습니다.
Notion에서는 같은 이메일 주소로 여러 작업 공간 (즉, 조직)을 생성하고 가입하고 쉽게 전환할 수 있습니다.
Slack에서는 동일하게 보이지만 각 작업 공간별로 새 계정을 생성해야 하므로, 내부적으로 다른 정체성을 사용하는 것으로 의심됩니다.

Slack 작업 공간

Notion 작업 공간
Notion의 "개인 계획"은 정상적으로는 내부적으로 조직이며, 단일 사용자(당신)만 포함되어 있습니다. Notion의 정확한 구현은 알 수 없지만, 이 설명은 우리의 모델에 대해 합리적이고 아카이브 가능합니다.
각 조직은 또한 식별자, 즉 "조직 도메인"이라고 불리는 것을 가지고 있습니다.
❓ 앱이 조직과 연관될 수 있나요?
답변
네 가능합니다. 처음에 논의했듯이, 앱은 정체성을 가질 수 있습니다. 비즈니스 시나리오를 설명할 수 있습니까?
3. 다른 Enterprise SSO 클라이언트 간에 데이터를 격리해야 하나요?
4. Enterprise SSO 관리자에게 활성 사용자, 감사 로그 등을 볼 수 있는 대시보드를 제공해야 하나요?
5. Enterprise SSO IdP에서 사용자가 제거되었을 때 계정을 자동으로 비활성화하는 방법은 무엇인가요?
인증 (AuthN), 권한 부여 (AuthZ), 정체성, 테넌트, 애플리케이션, IdP, SP, SSO 및 Enterprise SSO (조직)이라는 여러 개념을 소개했습니다. 모두 이해하는 데 시간이 걸릴 수 있습니다.
이 글을 쓰면서 흥미롭게도, 온라인 서비스의 가장 비싼 플랜은 전적으로 이 글에서 언급되지 않은 권한 부여와 관련된 독점 기능을 포함하는 경우가 많다는 것을 알게 되었습니다. 이미 권한 부여에 대해 몇 가지 질문이 있는지 모르겠네요: