CIAM 101: 인증, 정체성, SSO

배경#

아이덴티티 및 접근 관리 (IAM)가 시간이 지남에 따라 점점 더 복잡하고 확장되었다는 것을 깨닫고 Logto를 구축하기 시작했습니다. IAM의 개념은 WIAM (Workforce IAM) 및 CIAM (Customer IAM)과 같은 새로운 개념을 탄생시키기에 충분히 거대합니다.

WIAM과 CIAM은 같은 기초를 공유하지만, 각기 다른 사용 사례를 가지고 있습니다. WIAM은 일반적으로 내부 사용자용으로 사용되며, CIAM은 외부 고객용으로 사용됩니다.

몇 가지 예시:

• WIAM 귀사의 직원들이 회사 리소스 (소프트웨어 구독, 클라우드 컴퓨팅 서비스 등)에 접근하기 위해 통합된 아이덴티티 시스템을 사용합니다.
• CIAM 귀하의 온라인 서점은 고객과 판매자를 위한 사용자 아이덴티티 시스템이 필요합니다. 로그인 경험은 온보딩의 중요한 부분으로, 이는 전환 깔때기의 최상단에 위치합니다.

개발 중에 우리는 팀 전체에 통합된 이해를 구축하는 것이 제품을 다음 단계로 끌어올리기 전에 유익하다는 것을 깨달았습니다. 이것이 IAM의 전반적인 모습을 더 잘 이해하는 데 도움이 되기를 바랍니다.

시작해 봅시다!

CIAM의 기본#

이 문서에서는 CIAM의 기본 개념과 인증 흐름 전후에 발생할 수 있는 문제들을 중점적으로 다루겠습니다. 또한 싱글 사인온(SSO)과 관련된 시나리오에 대해서도 논의할 것입니다.

인증과 권한 부여#

💡 인증은 처음에는 "누구입니까?"로 정의되었지만, 디지털 정체성을 논할 때, 인증을 "정체성 소유권 증명"으로 설명하는 것이 더 정확합니다. (Calm-Card-2424에게 공을 돌립니다)

이 두 카테고리에 속하지 않는 것을 발견하면, 그것은 아마도 정체성 비즈니스에 필수적이지 않을 것입니다.

• 인증의 예시
  • 비밀번호 로그인, 비밀번호 없는 로그인, 소셜 로그인 등
  • 기계 간 인증
• 권한 부여의 예시
  • 역할 기반 접근 제어
  • 속성 기반 접근 제어
• 예외의 예시
  • 비정체성 데이터
  • 웹 훅

정체성과 테넌트#

정체성은 일반적으로 사용자나 기계를 나타냅니다. 인증이 성공적으로 이루어지면 ID 토큰이 정체성으로 발급됩니다.

다시 말해, 인증의 주된 목적은 정체성을 획득하는 것입니다.

테넌트는 정체성들의 그룹입니다:

"다중 테넌트"를 논할 때 우리는 서로 정체성이 격리된 다수의 Logto 인스턴스를 언급하고 있습니다. 즉, 여러 Logto 인스턴스입니다.

Tenant 1의 정체성을 Tenant 2에서 사용할 수 없습니다. 마치 코스트코 회원권이 Whole Foods에서 유효하지 않은 것과 같습니다.

앱과 테넌트#

정체성과 마찬가지로, 앱도 테넌트 소속입니다. 기억해야 할 몇 가지 사항:

• 앱과 정체성 간에 직접적인 관계는 보통 존재하지 않습니다.
  • 정체성은 앱을 나타낼 수 있지만, 그들 간에는 직접적인 연결이 없습니다.
• 사용자와 같이, 앱도 테넌트 단계입니다.
• 앱은 코드이며, 사용자는 인간입니다.
• 앱의 유일한 목적은 인증을 완료하는 것입니다, 즉 정체성을 얻는 것입니다.

Identity Provider (IdP)와 Service Provider (SP)#

이 두 제공자 간의 차이는 까다롭지만 중요합니다.

• Identity Provider는 인증을 제공하고 정체성을 발급하는 서비스입니다.

Google에서 Service Provider에 대해 다양한 설명을 찾을 수 있지만 만족스럽지 않을 수 있습니다. 제 생각에 Service Provider는 상대적인 개념입니다:

• **Service Provider (또는 OIDC에서의 Relying Party)**는 IdP에서 인증을 시작하고 결과를 요청하는 서비스 또는 클라이언트입니다.

퀴즈#

일반적인 소셜 로그인 시나리오를 고려해 봅시다:

❓ 이 그래프에서 몇 개의 Service Providers와 Identity Providers가 있을까요?

답변

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

사례 연구: 기술 솔루션 회사#

당신은 기술 솔루션 회사의 CTO이며, 100개 이상의 비즈니스 파트너를 보유하고 있으며 300개 이상의 프로젝트를 완료했습니다.

• 각 프로젝트는 웹 앱 또는 백엔드 서비스가 있는 모바일 앱입니다.
• 각 비즈니스 파트너에 대해, 프로젝트 간의 SSO를 제공하기 위해 사용자 시스템을 리팩토링하고 싶습니다.

❓ Logto (또는 CIAM 제품)가 어떻게 도울 수 있을까요?

답변

각 비즈니스 파트너마다 Logto 인스턴스를 만드세요. 각 파트너는 테넌트를 보유합니다. 프로젝트는 Logto의 "앱"으로 매핑됩니다.

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에서는 동일하게 보이지만 각 작업 공간별로 새 계정을 생성해야 하므로, 내부적으로 다른 정체성을 사용하는 것으로 의심됩니다.

Notion의 "개인 계획"은 정상적으로는 내부적으로 조직이며, 단일 사용자(당신)만 포함되어 있습니다. Notion의 정확한 구현은 알 수 없지만, 이 설명은 우리의 모델에 대해 합리적이고 아카이브 가능합니다.

각 조직은 또한 식별자, 즉 "조직 도메인"이라고 불리는 것을 가지고 있습니다.

퀴즈#

❓ 앱이 조직과 연관될 수 있나요?

답변

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

남은 질문들#

3. 다른 Enterprise SSO 클라이언트 간에 데이터를 격리해야 하나요?

• 예: 메시지, 문서와 같은 비즈니스 데이터를 조직 수준에서 격리하세요.
• 아니요: 정체성을 독립적으로 유지하세요. 반드시 조직에 연관되지 않아도 됩니다.
• 여기에는 정체성, 조직, Enterprise SSO 구성이라는 세 가지 분명히 다른 엔티티가 포함되어 있습니다. 이는 상당한 복잡성을 증가시킵니다. 질문 자체가 충분히 구체적이지 않습니다.

4. Enterprise SSO 관리자에게 활성 사용자, 감사 로그 등을 볼 수 있는 대시보드를 제공해야 하나요?

5. Enterprise SSO IdP에서 사용자가 제거되었을 때 계정을 자동으로 비활성화하는 방법은 무엇인가요?

• 이러한 요구는 더 비즈니스 지향적이며 조직 수준에서 구현할 수 있습니다. 이들을 여기서 열어두겠습니다.

마무리 노트#

인증 (AuthN), 권한 부여 (AuthZ), 정체성, 테넌트, 애플리케이션, IdP, SP, SSO 및 Enterprise SSO (조직)이라는 여러 개념을 소개했습니다. 모두 이해하는 데 시간이 걸릴 수 있습니다.

이 글을 쓰면서 흥미롭게도, 온라인 서비스의 가장 비싼 플랜은 전적으로 이 글에서 언급되지 않은 권한 부여와 관련된 독점 기능을 포함하는 경우가 많다는 것을 알게 되었습니다. 이미 권한 부여에 대해 몇 가지 질문이 있는지 모르겠네요:

• 어떻게 사용자의 권한을 할당하고 확인할 수 있을까요?
• 어떤 권한 부여 모델을 사용해야 하나요?
• 권한 부여 모델을 적용하는 모범 사례는 무엇인가요?