## 배경 아이덴티티 및 접근 관리 (IAM)가 시간이 지남에 따라 점점 더 복잡하고 확장되었다는 것을 깨닫고 Logto를 구축하기 시작했습니다. IAM의 개념은 WIAM (Workforce IAM) 및 CIAM (Customer IAM)과 같은 새로운 개념을 탄생시키기에 충분히 거대합니다. WIAM과 CIAM은 같은 기초를 공유하지만, 각기 다른 사용 사례를 가지고 있습니다. WIAM은 일반적으로 내부 사용자용으로 사용되며, CIAM은 외부 고객용으로 사용됩니다. 몇 가지 예시: - **WIAM** 귀사의 직원들이 회사 리소스 (소프트웨어 구독, 클라우드 컴퓨팅 서비스 등)에 접근하기 위해 통합된 아이덴티티 시스템을 사용합니다. - **CIAM** 귀하의 온라인 서점은 고객과 판매자를 위한 사용자 아이덴티티 시스템이 필요합니다. 로그인 경험은 온보딩의 중요한 부분으로, 이는 전환 깔때기의 최상단에 위치합니다. 개발 중에 우리는 팀 전체에 통합된 이해를 구축하는 것이 제품을 다음 단계로 끌어올리기 전에 유익하다는 것을 깨달았습니다. 이것이 IAM의 전반적인 모습을 더 잘 이해하는 데 도움이 되기를 바랍니다. 시작해 봅시다! ## CIAM의 기본 WIAM과 CIAM의 차이와 상관없이, 둘 다 인증과 권한 부여라는 같은 기초를 가지고 있습니다. 이 두 가지 개념은 그들의 기능의 핵심입니다. 이 문서에서는 CIAM의 기본 개념과 인증 흐름 전후에 발생할 수 있는 문제들을 중점적으로 다루겠습니다. 또한 싱글 사인온(SSO)과 관련된 시나리오에 대해서도 논의할 것입니다. ### 인증과 권한 부여 - 인증 (AuthN)은 “어떤 정체성을 소유하십니까?”라는 질문에 답합니다. - 권한 부여 (AuthZ)는 “무엇을 할 수 있습니까?”라는 질문에 답합니다. > 💡 인증은 처음에는 "누구입니까?"로 정의되었지만, 디지털 정체성을 논할 때, 인증을 "정체성 소유권 증명"으로 설명하는 것이 더 정확합니다. ([Calm-Card-2424](https://www.reddit.com/r/programming/comments/10uycg0/comment/j7eyhrb/)에게 공을 돌립니다) 이 두 카테고리에 속하지 않는 것을 발견하면, 그것은 아마도 정체성 비즈니스에 필수적이지 않을 것입니다. - **인증의 예시** - 비밀번호 로그인, 비밀번호 없는 로그인, 소셜 로그인 등 - 기계 간 인증 - **권한 부여의 예시** - 역할 기반 접근 제어 - 속성 기반 접근 제어 - **예외의 예시** - 비정체성 데이터 - 웹 훅 ### 정체성과 테넌트 정체성은 일반적으로 사용자나 기계를 나타냅니다. 인증이 성공적으로 이루어지면 ID 토큰이 정체성으로 발급됩니다. 다시 말해, 인증의 주된 목적은 정체성을 획득하는 것입니다. 테넌트는 정체성들의 그룹입니다: ```mermaid graph TD Tenant --- A[정체성: 사용자 1] Tenant --- B[정체성: 사용자 2] Tenant --- C[정체성: 기계 1] ``` "다중 테넌트"를 논할 때 우리는 서로 정체성이 격리된 다수의 Logto 인스턴스를 언급하고 있습니다. 즉, 여러 Logto 인스턴스입니다. ```mermaid graph TD T1[테넌트 1] --- A[정체성: 사용자 1] T2[테넌트 2] --- B[정체성: 사용자 1] T2[테넌트 2] --- C[정체성: 기계 1] subgraph IS2[정체성 시스템 2] T2 B C end subgraph IS1[정체성 시스템 1] T1 A end ``` Tenant 1의 정체성을 Tenant 2에서 사용할 수 없습니다. 마치 코스트코 회원권이 Whole Foods에서 유효하지 않은 것과 같습니다. 🧱 요약하자면, 테넌트 사이에는 “물리적인 벽”이 있습니다. "Tenant"의 정의는 CIAM 제품에 따라 다를 수 있습니다. 어떤 곳에서는 Logto의 "조직"이라는 용어를 사용하기도 하며, 이는 후에 소개될 것입니다. ### 앱과 테넌트 정체성과 마찬가지로, 앱도 테넌트 소속입니다. 기억해야 할 몇 가지 사항: - 앱과 정체성 간에 직접적인 관계는 보통 존재하지 않습니다. - 정체성은 앱을 나타낼 수 있지만, 그들 간에는 직접적인 연결이 없습니다. - 사용자와 같이, 앱도 테넌트 단계입니다. - 앱은 코드이며, 사용자는 인간입니다. - 앱의 유일한 목적은 인증을 완료하는 것입니다, 즉 정체성을 얻는 것입니다. ### Identity Provider (IdP)와 Service Provider (SP) 이 두 제공자 간의 차이는 까다롭지만 중요합니다. - **Identity Provider**는 인증을 제공하고 정체성을 발급하는 서비스입니다. Google에서 Service Provider에 대해 다양한 설명을 찾을 수 있지만 만족스럽지 않을 수 있습니다. 제 생각에 Service Provider는 상대적인 개념입니다: - **Service Provider (또는 [OIDC](https://openid.net/specs/openid-connect-core-1_0.html)에서의 Relying Party)**는 IdP에서 인증을 시작하고 결과를 요청하는 서비스 또는 클라이언트입니다. #### 퀴즈 일반적인 소셜 로그인 시나리오를 고려해 봅시다: ```mermaid graph LR A[iOS 앱] --> |로그인 호출| Logto --> |리다이렉트| GitHub GitHub --> |GitHub ID 반환| Logto --> |Logto ID 반환| A ``` **❓ 이 그래프에서 몇 개의 Service Providers와 Identity Providers가 있을까요?**

답변

둘 다 두 개 있습니다. iOS 앱은 Logto에 대한 서비스 제공자이며, Logto는 정체성 제공자입니다. Logto는 GitHub에 대한 서비스 제공자이자 정체성 제공자입니다. 따라서 Logto는 서비스 제공자이면서 정체성 제공자입니다.

## 사례 연구: 기술 솔루션 회사 당신은 기술 솔루션 회사의 CTO이며, 100개 이상의 비즈니스 파트너를 보유하고 있으며 300개 이상의 프로젝트를 완료했습니다. - 각 프로젝트는 웹 앱 또는 백엔드 서비스가 있는 모바일 앱입니다. - 각 비즈니스 파트너에 대해, 프로젝트 간의 SSO를 제공하기 위해 사용자 시스템을 리팩토링하고 싶습니다. **❓ Logto (또는 CIAM 제품)가 어떻게 도울 수 있을까요?**

답변

각 비즈니스 파트너마다 Logto 인스턴스를 만드세요. 각 파트너는 테넌트를 보유합니다. 프로젝트는 Logto의 "앱"으로 매핑됩니다. ```mermaid graph TD T1[테넌트 1] --- A[앱 1] T1 --- B[앱 2] T1 --- C[앱 3] T1 --- U1[사용자 1] T1 --- U2[사용자 2] T2[테넌트 2] --- D[앱 1] T2 --- E[앱 2] T2 --- U21[사용자 1] T2 --- U22[사용자 2] ``` Logto는 테넌트 내에서 보편적인 로그인 경험 (즉, SSO)를 제공합니다, 따라서 사용자가 이미 로그인했던 동일한 테넌트의 다른 앱에 접근할 때 다시 로그인할 필요가 없습니다.

## 우리가 SSO에 대해 얘기할 때 “SSO”라는 용어가 자주 혼란을 야기하는 것을 발견했습니다. 우리는 싱글 사인온(SSO)을 행동으로 간주하며, 비즈니스 개념으로 보지 않습니다. 따라서 SSO는 “WIAM의 SSO”와 동일하지 않습니다. “SSO가 필요하다”고 말할 때, 이는 다음과 같은 경우 중 하나를 의미할 수 있습니다: ### SSO 사례 1 > 👉🏽 대기업에서 직원들은 모든 회사 승인된 리소스 (예: 이메일, IM, 클라우드 서비스)에 같은 자격 증명을 사용하여 로그인합니다. 이는 전형적인 WIAM 시나리오입니다. 이 경우, 단일 Identity Provider만 참여합니다. 지금은 이것에 신경 쓸 필요가 없습니다. ### SSO 사례 2 > 👉🏽 최종 사용자가 같은 회사를 통해 개발된 모든 서비스 (예: GSuite)에 같은 자격 증명을 사용하여 로그인합니다. Logto는 현재 위에서 설명한 접근법에 집중하고 있습니다. Facebook과 같은 제3자 소셜 로그인 제공자와 같은 외부 IdP가 여러 개 있을 수 있지만, 이들은 독립적이며 연결되지 않을 수 있습니다. 그럼에도 불구하고, Logto는 아이덴티티에 대한 단일 진실의 근원으로 남으며, 단순히 다른 제공자로부터 "빌린다"라고 할 수 있습니다. 이 경우, Logto는 GSuite 앱에 대해 Identity Provider로 작용하고, 외부 IdP에 대해서는 Service Provider로 작용합니다. ### SSO 사례 3 > 👉🏽 최종 사용자는 해당 이메일 도메인 내에서 특정 IdP를 사용하여 인증을 완료할 수 있습니다. 예를 들어, Google Workspace를 통한 Figma 로그인. 이는 CIAM에서 SSO에 대한 가장 일반적인 사용 사례입니다. 좀 더 자세히 살펴보겠습니다. silverhand.io 이메일을 사용하여 Figma에 로그인하고자 한다면, 소셜 로그인이나 SSO를 사용할 수 있습니다. 아래 그림은 두 간의 차이를 보여줍니다:

말로 설명하자면: - 소셜 로그인 후, 사용자는 Figma에서 비밀번호를 설정하거나 이메일 주소를 변경할 수 있습니다. - SSO 후, 사용자는 비밀번호를 설정하거나 이메일 주소를 포함한 개인 정보를 변경할 수 없습니다. 이는 그들의 아이덴티티가 Google Workspace에 관리되기 때문입니다. 이 경우, Logto는 IdP와 SP 역할을 모두 수행합니다. SSO는 일반적인 로그인 프로세스보다 복잡한 것 같습니다. 아이덴티티 소유자에게 어떤 이점이 있을까요? - **중앙집중화된 관리:** 아이덴티티 정보와 인증 프로세스를 한 곳에서 유지하고 사용자 정보가 항상 최신 상태인지 확인할 수 있습니다. 변경 사항에 대해 다양한 애플리케이션에 라이센스를 추가 및 제거할 필요가 없습니다. - **개선된 사용자 경험:** SSO가 필요한 아이덴티티 소유자는 일반적으로 기업입니다. 그들의 직원들은 Figma, Zoom, Slack 등과 같은 크로스-컴퍼니 애플리케이션에 동일한 자격 증명과 세션을 사용하여 로그인할 수 있습니다. - **강화된 보안:** 일부 기업에서는 동적 인증 코드와 같은 특정 로그인 방법을 요구합니다. SSO를 사용하면 모든 직원이 동일한 로그인 방법 조합을 사용하여 모든 리소스에 접근할 수 있음을 보장할 수 있습니다. > 🤔 똑똑한 너는 이것이 사실상 SaaS의 관점에서 **SSO 사례 1**인 것을 알아챘을 것입니다. SSO 그래프에서 "X"에 대해 논의할 시간입니다. 이것은 Figma가 이메일 도메인을 특정 IdP에 연결하는 과정을 의미합니다. 그러나 이것이 어떻게 작동할까요? ## SSO 매핑 요청은 종종 기업 고객으로부터 오므로, 이전 섹션의 "SSO 사례 3"를 "Enterprise SSO"라고 부릅니다. 우리는 쉽게 순진한 해결책을 고안할 수 있습니다: 이메일 도메인과 SSO 방법 간의 매핑을 만들고 수동으로 업데이트합니다. 과정 “X”의 동작은 이제 분명합니다: > 🔍 **주어진 이메일 도메인에 대한 매핑된 Enterprise SSO 방법을 찾으세요** 따라서 silverhand.io를 Google Workspace SSO URL과 연결된 유효한 이메일 도메인으로 구성하면, @silverhand.io 이메일로 로그인하려는 사용자는 해당 Google Workspace 로그인 페이지로 리다이렉트됩니다. 수십 개의 클라이언트만 Enterprise SSO가 필요할 때는 수동으로 매핑을 관리해도 괜찮습니다. 그러나 다음을 더 고려해야 합니다: 1. _Enterprise SSO 클라이언트가 수 백 혹은 수 천개가 있다면 어떻게 해야 할까요?_ 2. _“일반 사용자”와 “Enterprise SSO 사용자”는 어떤 관계인가요?_ 3. _다른 Enterprise SSO 클라이언트 간에 데이터를 격리해야 하나요?_ 4. _Enterprise SSO 관리자에게 활성 사용자 및 감사 로그 등을 볼 수 있는 대시보드를 제공해야 하나요?_ 5. _Enterprise SSO IdP에서 사용자가 제거되었을 때 계정을 자동으로 비활성화하는 방법은 무엇인가요?_ 그리고 더 많은 것들이 있습니다. 거의 모든 Enterprise SSO가 이메일 도메인 기반이므로, 우리는 더 나은 해결책을 빠르게 생각해낼 수 있습니다: - 사용자가 해당 도메인의 소유권을 증명할 수 있다면, 그들은 해당 도메인의 Enterprise SSO를 자기 서비스 방식으로 구성할 수 있습니다. 이 해결책은 첫번째 두 질문을 해결합니다: > _1. Enterprise SSO 클라이언트가 수 백 혹은 수 천개가 있다면 어떻게 해야 하나요?_ - 그들은 자기 서비스 방식으로 Enterprise SSO를 구성할 수 있습니다. > _2. “일반 사용자”와 “Enterprise SSO 사용자”는 어떤 관계인가요?_ - 실제 사용자는 Enterprise SSO를 제외한 모든 가능한 로그인 방법을 열어두고, 도메인으로 로그인하려는 사용자는 Enterprise SSO만으로 로그인 방법을 제한합니다. 세 번째 질문에 대해: > _3. 다른 Enterprise SSO 클라이언트 간에 데이터를 격리해야 하나요?_ - 그렇기도 하고 아니기도 합니다. 이제 조직에 대해 소개할 때입니다. ## 조직 특정 Enterprise SSO 방법을 사용할 도메인을 인식하기 위해 이메일 도메인을 사용한다고 언급했습니다; 다시 말해, 특정 사용자 그룹에 대해 특별 처리를 적용하는 것입니다. 그러나 클라이언트의 요구사항은 종종 단순히 Enterprise SSO를 넘어서 있습니다; 예를 들어, 전 섹션의 질문 4와 5처럼 말입니다. 수년간 뛰어난 SaaS 회사들이 이러한 종류의 문제를 해결하기 위해 성숙한 모델을 개발해왔습니다: 조직. **조직 규칙** 1. 조직은 정체성 그룹이며, 보통 테넌트보다 작습니다. 2. 모든 조직은 테넌트와 관련이 있습니다. "워크스페이스", “팀”, 혹은 심지어 "테넌트"와 같은 다른 용어를 소프트웨어에서 볼 수 있습니다. 우리가 논의하는 개념인지 확인하려면 그것이 "정체성 그룹"을 나타내는지 확인하세요. 이 글에서는 일관성을 위해 "조직"이라는 용어를 사용하겠습니다. 🤹🏽‍♀️ 대부분의 경우, "정체성 그룹"은 "사용자 그룹"과 동일하지만, **같은 정체성이 여러 조직에 존재할 수 있습니다**. Notion에서는 같은 이메일 주소로 여러 작업 공간 (즉, 조직)을 생성하고 가입하고 쉽게 전환할 수 있습니다. Slack에서는 동일하게 보이지만 각 작업 공간별로 새 계정을 생성해야 하므로, 내부적으로 다른 정체성을 사용하는 것으로 의심됩니다.

![Slack 작업 공간](https://uploads.strapi.logto.io/1/slack_workspaces_b4f0bcc978.png) _Slack 작업 공간_ ![Notion 작업 공간](https://uploads.strapi.logto.io/1/notion_workspaces_5bdc2b7e9b.png) _Notion 작업 공간_

Notion의 "개인 계획"은 정상적으로는 내부적으로 조직이며, 단일 사용자(당신)만 포함되어 있습니다. Notion의 정확한 구현은 알 수 없지만, 이 설명은 우리의 모델에 대해 합리적이고 아카이브 가능합니다. 각 조직은 또한 식별자, 즉 "조직 도메인"이라고 불리는 것을 가지고 있습니다. "조직 도메인"은 조직을 구별하는 데 사용되는 내부 식별자입니다. 이는 "이메일 도메인"과 다를 수 있으며, 전자는 서비스 제공자에 의해 관리되고 후자는 일반적으로 외부 정체성 제공자에 의해 제공됩니다. 예를 들어, Slack에서는 `foo`를 조직 도메인으로 사용할 수 있지만, 이 조직에 대해 `@bar.io`를 이메일 도메인으로 사용할 수 있습니다. ### 퀴즈 **❓ 앱이 조직과 연관될 수 있나요?**

답변

네 가능합니다. 처음에 논의했듯이, 앱은 정체성을 가질 수 있습니다. 비즈니스 시나리오를 설명할 수 있습니까?

## 남은 질문들 > _3. 다른 Enterprise SSO 클라이언트 간에 데이터를 격리해야 하나요?_ - **예:** 메시지, 문서와 같은 비즈니스 데이터를 조직 수준에서 격리하세요. - **아니요:** 정체성을 독립적으로 유지하세요. 반드시 조직에 연관되지 않아도 됩니다. - 여기에는 정체성, 조직, Enterprise SSO 구성이라는 세 가지 분명히 다른 엔티티가 포함되어 있습니다. 이는 상당한 복잡성을 증가시킵니다. 질문 자체가 충분히 구체적이지 않습니다. > _4. Enterprise SSO 관리자에게 활성 사용자, 감사 로그 등을 볼 수 있는 대시보드를 제공해야 하나요?_ > > _5. Enterprise SSO IdP에서 사용자가 제거되었을 때 계정을 자동으로 비활성화하는 방법은 무엇인가요?_ - 이러한 요구는 더 비즈니스 지향적이며 조직 수준에서 구현할 수 있습니다. 이들을 여기서 열어두겠습니다. ## 마무리 노트 인증 (AuthN), 권한 부여 (AuthZ), 정체성, 테넌트, 애플리케이션, IdP, SP, SSO 및 Enterprise SSO (조직)이라는 여러 개념을 소개했습니다. 모두 이해하는 데 시간이 걸릴 수 있습니다. 이 글을 쓰면서 흥미롭게도, 온라인 서비스의 가장 비싼 플랜은 전적으로 이 글에서 언급되지 않은 권한 부여와 관련된 독점 기능을 포함하는 경우가 많다는 것을 알게 되었습니다. 이미 권한 부여에 대해 몇 가지 질문이 있는지 모르겠네요: - 어떻게 사용자의 권한을 할당하고 확인할 수 있을까요? - 어떤 권한 부여 모델을 사용해야 하나요? - 권한 부여 모델을 적용하는 모범 사례는 무엇인가요? 🔥 잠시 쉬고, CIAM 102에서 봅시다!