아키텍처 계획하기

디자인에서 모범 사례를 확립하고 아키텍처를 계획하려면 다양한 관점에서 필요를 고려하세요. 기본 기술과 기능에만 집중하지 말고 최종 목표와 워크플로에 집중하세요. 제품에 이상적인 아키텍처를 구축하는 데 도움이 되는 몇 가지 주요 질문을 소개합니다.

비즈니스 모델은 무엇이며, 관련된 주요 당사자와 이해관계자는 누구입니까?

일반적으로 두 가지 주요 비즈니스 모델, B2C 및 B2B가 있으며, 각각은 복잡한 아이덴티티 관리 시나리오에서 다른 당사자를 포함합니다. 이러한 주요 이해관계를 이해하면 사용자 중심의 경험을 제공하고 아이덴티티 관리의 모든 측면을 다루는 시스템을 설계할 수 있습니다.

B2C

B2C 애플리케이션에서는 아이덴티티 관리가 일반적으로 간단하며 보통 두 당사자만 포함됩니다.

개발자 (당신)

이는 Logto Console 관리자 및 협력자를 의미하며, 일반적으로 당신과 개발 팀이 사용자 아이덴티티 풀을 관리하고 보안하며 아이덴티티 데이터베이스와 직접 작업합니다. Logto Console에서 고객 아이덴티티를 직접 관리하거나 Logto Management API를 사용하여 맞춤형 개발을 할 수 있습니다.

당신의 소비자

당신의 소비자는 Logto의 핵심 서비스와 데이터베이스에 저장된 사용자 아이덴티티입니다. B2C 모델에서는 소비자가 자신의 인증 및 개인 정보를 관리할 수 있습니다.

B2B

B2B 애플리케이션에서는 이 아키텍처에 또 다른 계층과 컨텍스트가 도입됩니다. 비즈니스 유닛 소유자 (또는 조직)는 누가 인스턴스에 접근할 수 있는지, 어떻게 인증하는지, 무엇을 할 수 있는지를 제어합니다. 조직은 인스턴스에 접근하는 모든 최종 사용자의 아이덴티티를 관리합니다.

개발자 (당신)

여전히 Logto Console 관리자 및 협력자를 의미합니다. 조직 관리자가 아이덴티티를 관리할 수 있지만, 개발자는 여전히 Logto Console에서 고객 아이덴티티를 직접 관리하거나 Logto Management API를 사용하여 맞춤형 개발을 할 수 있습니다.

당신의 고객 (조직 관리자)

당신의 고객은 다중 테넌트 앱에서 "조직"을 나타내는 비즈니스 유닛입니다. 예를 들어, Slack 또는 Notion의 워크스페이스입니다. 각 워크스페이스는 일반적으로 여러 역할과 직원을 관리하는 하나 이상의 관리자를 가지고 있습니다. 다음 내용에서는 회원 아이덴티티를 관리할 수 있는 사람들을 "조직 관리자"라고 부릅니다.

당신의 고객의 직원, 파트너 또는 소비자

이들은 조직 컨텍스트에서 "회원"으로 불리는 최종 사용자 아이덴티티이며, 조직 내에서 관리될 수 있습니다. 이러한 아이덴티티는 조직별로 분리되어 있지만, 모두 단일 아이덴티티 시스템 아래에 집계됩니다.

실제 시나리오에서, 제품 관점에서, 이들은 회사 직원, 비즈니스 파트너 또는 조직과 관련된 소비자일 수 있습니다.

기타

B2B2C와 같은 다른 모델은 이러한 두 가지 모델에서 복잡성으로 인해 발생할 수 있습니다. 그러나 접근 방식은 동일합니다: 모든 변경은 동일한 핵심 기반에서 시작됩니다.

다음 장에서는 이 두 가지 일반적인 아키텍처를 자세히 살펴보고 Logto가 지원하는 관련 기능을 강조할 것입니다.

인증 (Authentication) 필요를 정리하세요

기술 및 제품 설계에 관련된 주요 사용자와 당사자를 이해한 후, 다음 질문을 고려하여 아이덴티티 아키텍처를 정제하고 인증 (Authentication) 필요와 제어 수준을 결정하세요:

1. 고객이 인증 및 로그인 경험을 위해 어떤 옵션을 가지고 있습니까? 이는 일반적으로 비즈니스, 획득 전략 및 제품 필요에 따라 다릅니다.

   예: 내 앱에 필요한 기능은 무엇입니까? 소셜 로그인? 비밀번호 없는 로그인?

2. 고객 행동에 대해 개발자가 원하는 제어 수준은 무엇입니까?

   예: 고객이 자신의 프로필을 업데이트하고 유지할 수 있습니까? 고객이 스스로 MFA를 켜고 끌 수 있습니까? 선호하는 로그인 방법을 선택할 수 있습니까?

3. 조직에 위임하고 싶은 맞춤화 유형은 무엇입니까? 이는 제품의 도메인 및 산업과 고객의 특정 필요에 따라 다르며, 조직마다 다를 수 있습니다.

   예: 각 조직에 대해 로그인 경험이 달라져야 합니까? 그렇다면 맞춤화는 브랜딩에만 국한되어야 합니까, 아니면 인증 흐름의 차이도 포함해야 합니까?

4. 조직 관리자가 회원 행동에 대해 원하는 제어 수준은 무엇입니까?

   예: 조직 관리자가 MFA가 필요한지 결정할 수 있어야 합니까? 관리자가 회원의 비밀번호를 변경할 수 있는 권한이 있어야 합니까?

단일 보편적 아이덴티티 시스템이 필요한가요, 아니면 여러 개의 별도 시스템이 필요한가요?

또 다른 중요한 질문은 비즈니스 또는 제품의 일부가 하나의 아이덴티티 시스템이 필요한지, 아니면 별도의 시스템이 필요한지를 스스로에게 묻는 것입니다.

일반적으로, 답은 단일 보편적 아이덴티티 시스템입니다. 이는 하나의 Logto 테넌트 (또는 Logto OSS의 하나의 Logto 관리자 콘솔 인스턴스)만 필요하다는 것을 의미합니다. Logto는 단일 테넌트 내에서 여러 앱과 여러 조직을 모두 지원하도록 설계되었습니다. 하나의 프로덕션 Logto 테넌트는 대부분의 필요에 충분합니다. 다음은 직면할 수 있는 몇 가지 일반적인 시나리오입니다:

다중 테넌시를 가진 SaaS 애플리케이션을 구축하고 싶습니다

각 고객을 위한 "워크스페이스" 또는 "조직" 개념을 가진 SaaS 애플리케이션을 구축하는 경우, 단일 테넌트 내에서 각 고객의 워크스페이스를 관리하기 위해 조직을 사용할 수 있습니다.

이 경우, 사용자는 여러 조직의 회원이 될 수 있습니다. 예를 들어, 사용자는 개인 워크스페이스를 가지고 회사의 워크스페이스에 참여할 수 있습니다.

여러 애플리케이션이 있습니다

Logto를 사용하면 애플리케이션의 유형 (예: 웹, 모바일, 데스크톱 등)과 애플리케이션 사용 사례 및 기능 (예: 드라이버 앱, 호출자 앱 등)에 관계없이 단일 테넌트 내에서 여러 애플리케이션을 관리할 수 있습니다.

여러 기업 고객이 있습니다

단일 테넌트 내에서 여러 기업 고객을 관리하기 위해 엔터프라이즈 SSO와 조직을 사용할 수 있습니다. 엔터프라이즈 SSO 이메일 도메인 설정을 구성하고 Just-in-Time 프로비저닝 기능을 사용하여 엔터프라이즈 SSO 계정을 가진 사용자가 적절한 조직에 가입하거나 로그인하는 프로세스를 자동화할 수 있습니다.