다중 테넌트 SaaS 애플리케이션 구축: 설계부터 구현까지 완전한 가이드

Notion, Slack, 또는 Figma 같은 앱은 어떻게 만들어질까요? 이러한 다중 테넌트 SaaS 애플리케이션은 사용하기에 간단해 보일 수 있지만, 직접 만들어 본다면? 이제부터 다른 이야기입니다.

처음에 그렇게 복잡한 것을 만들겠다고 생각했을 때 제 머리는 폭발할 것만 같았습니다:

• 사용자들은 여러 가지 로그인 옵션이 필요합니다 (이메일, 구글, GitHub)
• 각 사용자는 여러 조직을 만들고 소속될 수 있습니다
• 각 조직 내에서 다른 권한 수준
• 특정 이메일 도메인을 위한 자동 가입이 필요한 엔터프라이즈 조직
• 민감한 작업을 위한 MFA 요구 사항
• ...

"이사님, 2주 후에 제품 디자인에 대해 이야기해 보죠. 지금은 헤어날 수 없을 것 같네요."

그런데 막상 작업을 시작했더니 생각만큼 두렵진 않다는 것을 깨달았습니다.

그냥 모든 기능을 갖춘 시스템을 2시간 안에 만들었습니다!

어떻게 처음부터 끝까지 이런 시스템을 설계하고 구현할 수 있는지 정확히 보여드리겠습니다 - 2025년에 현대적인 도구와 올바른 아키텍처적 접근을 통해 얼마나 간단한지 경이로울 것입니다.

전체 소스 코드는 이 글의 마지막에 제공됩니다. 시작해 보겠습니다!

우리는 DocuMind라는 AI 문서화 SaaS 제품으로 시작할 것입니다.

DocuMind는 개인 사용자, 소기업, 기업을 지원하기 위해 다중 테넌트 모델로 설계된 AI 문서화 SaaS 제품입니다.

이 플랫폼은 AI 기반의 문서 관리 기능을 제공하며, 조직 내에서 자동 요약 생성, 핵심 포인트 추출, 지능형 콘텐츠 추천을 포함합니다.

SaaS 인증 및 권한 부여에 필요한 기능은 무엇인가요?#

먼저 필요한 요구 사항을 검토해 보겠습니다. 어떤 기능이 필요합니까?

다중 테넌트 아키텍처#

다중 테넌트 아키텍처를 가능하게 하려면 조직이라는 엔터티 레이어가 필요합니다. 이는 하나의 사용자 풀이 여러 작업 영역에 액세스할 수 있는 경우를 상상해 보세요. 각 조직은 작업 공간을 나타내며, 사용자는 할당된 역할에 따라 다른 작업 공간(조직)에 액세스할 수 있는 단일 신원을 유지합니다.

이는 인증 제공자에서 널리 사용되는 기능입니다. 신원 관리 시스템에서의 조직은 SaaS 앱의 작업 공간, 프로젝트 또는 테넌트에 해당합니다.

멤버십#

멤버는 조직 내에서 신원의 멤버십 상태를 나타내기 위해 사용되는 임시적인 개념입니다.

예를 들어, 사라가 이메일 [email protected]을 사용하여 귀하의 앱에 가입합니다. 그녀는 다른 작업 영역에 소속될 수 있습니다. 사라가 작업 공간 A의 일부이지만 작업 공간 B의 일부가 아니라면, 그녀는 작업 공간 A의 멤버로 간주되지만 작업 공간 B의 멤버는 아닙니다.

역할 및 권한 설계#

다중 테넌트 아키텍처에서는 사용자가 테넌트 리소스에 액세스하기 위한 특정 권한을 정의하는 역할 이 필요합니다. 권한은 특정 작업, 예를 들어 read: order 또는 write: order와 같은 구체적인 액세스 제어로 정의되며, 특정 리소스에 대해 수행할 수 있는 작업을 결정합니다.

역할은 다중 테넌트 환경에서 멤버에게 할당되는 권한 세트입니다.

이 역할과 권한을 정의해야 하며, 사용자가 역할을 할당받고 때로는 자동화된 프로세스가 포함될 수 있습니다. 예를 들어:

1. 조직에 가입하는 사용자는 자동으로 멤버 역할을 받습니다.
2. 워크스페이스를 처음 생성하는 사용자는 자동으로 관리자 역할을 받습니다.

가입 및 로그인 흐름#

기본적인 로그인 및 가입 옵션을 포함한 사용자 친화적이고 안전한 등록 및 인증 프로세스를 보장하세요:

1. 이메일 및 비밀번호 로그인: 이메일과 비밀번호를 사용하는 전통적인 로그인 방법입니다.
2. 비밀번호 없는 로그인: 이메일 확인 코드를 사용하여 쉽고 안전한 액세스를 제공합니다.
3. 계정 관리: 사용자가 이메일, 비밀번호 및 기타 세부 정보를 업데이트할 수 있는 계정 센터입니다.
4. 소셜 로그인: Google 및 GitHub과 같은 빠른 로그인 옵션입니다.
5. 다중 요소 인증 (MFA): Duo와 같은 인증자 앱을 통한 로그인 허용하여 보안을 강화합니다.

테넌트 생성 및 초대#

다중 테넌트 SaaS 앱에서는 사용자 흐름의 주요 차별화 요소는 테넌트 생성 및 멤버 초대를 지원해야 한다는 점입니다. 이 프로세스는 제품 활성화 및 성장에 중요한 역할을 하기 때문에 신중한 계획과 실행이 필요합니다.

다음은 고려해야 할 몇 가지 일반적인 사용 흐름입니다:

거의 모든 SaaS 앱에서 발견되는 공통적인 시나리오 몇 가지가 여기에 있습니다. 이를 참고하여 제품 및 디자인 팀에 영감을 주고 필요에 따라 자체적으로 흐름을 만들 수 있습니다.

기술 아키텍처 및 시스템 설계#

모든 제품 요구 사항을 이해한 후에는 구현 단계로 넘어갑니다.

인증 전략 정의#

인증은 무섭게 보입니다. 사용자가 필요로 하는 것:

• 이메일 & 비밀번호 가입/로그인
• Google/Github 한 번 클릭 로그인
• 비밀번호를 잊어버렸을 때 비밀번호 재설정
• 엔터프라이즈 고객을 위한 팀 단위 로그인
• ...

이 기본 기능들만 구현해도 몇 주 동안 개발할 수 있습니다.

하지만 이제, 이것들을 전혀 스스로 구축할 필요가 없습니다!

현대적인 인증 제공자(이번에는 Logto를 선택했습니다)가 이러한 모든 기능을 패키지화하여 제공합니다. 인증 흐름은 간단합니다:

몇 주 동안의 개발을 15분 설정으로, Logto가 우리를 위해 모든 복잡한 흐름을 처리합니다! 우리가 나중에 구현 섹션에서 통합 단계를 다룰 것입니다. 이제 우리는 DocuMind 핵심 기능 구축에 집중할 수 있습니다!

다중 테넌트 아키텍처 구축#

조직 시스템은 사용자가 여러 조직을 생성하고 가입할 수 있게 합니다. 핵심 관계를 이해해 봅시다:

이 시스템에서 각 사용자는 여러 조직에 소속될 수 있으며, 각 조직은 여러 멤버를 가질 수 있습니다.

다중 테넌트 앱에서 접근 제어 활성화#

역할 기반 접근 제어(RBAC)는 다중 테넌트 SaaS 애플리케이션에서 보안성과 확장성을 보장하는 데 중요합니다.

다중 테넌트 앱에서는 권한과 역할의 설계가 일반적으로 일관되며, 제품 설계에서 비롯됩니다. 예를 들어 여러 작업 공간에서 일반적으로 관리자 역할과 멤버 역할이 있습니다. Logto는 인증 제공자로서 다음과 같은 조직 수준 역할 기반 접근 제어 설계를 가지고 있습니다:

1. 통합된 권한 정의: 권한은 시스템 수준에서 정의되며 모든 조직에 일관되게 적용되어 유지 보수가 가능하고 일관된 권한 관리를 보장합니다
2. 조직 템플릿: 사전 정의된 역할 및 권한 조합을 통해 조직 초기화가 간편해집니다

권한 관계는 다음과 같습니다:

각 사용자가 각 조직 내에서 자신의 역할을 가져야 하기 때문에 역할과 조직 간의 관계는 각 사용자에게 할당된 역할을 반영해야 합니다:

우리는 조직 시스템과 접근 제어 시스템을 설계했으며, 이제 우리의 제품을 구축할 수 있습니다!

기술 스택#

초보자에게 친숙하고 이식 가능한 스택을 선택했습니다:

1. 프론트엔드: React (Vue/Angular/Svelte로 쉽게 전환 가능)
2. 백엔드: Express (간단하고 직관적인 API)

프론트엔드와 백엔드를 분리한 이유는? 명확한 아키텍처를 가지고 배우기 쉽고 스택을 쉽게 전환할 수 있기 때문입니다. 인증 제공자로는 예제로 Logto를 사용합니다.

그리고 다음 가이드에서는, 여기서의 패턴은 모든 프론트엔드, 모든 백엔드 및 모든 인증 시스템에 적용됩니다.

앱에 기본 인증 흐름 추가#

가장 쉬운 단계입니다. Logto를 프로젝트에 통합하기만 하면 됩니다. 그런 다음 필요에 따라 Logto 콘솔에서 사용자 로그인/등록 방법을 구성할 수 있습니다.

Logto를 앱에 설치하기#

먼저, Logto Cloud에 로그인합니다. 계정이 없다면 무료 계정을 만드시기 바랍니다. 테스트를 위해 Development Tenant를 만듭니다.

Tenant Console에서 왼쪽의 "응용 프로그램" 버튼을 클릭합니다. 그런 다음 React를 선택하여 애플리케이션을 구축합니다.

페이지의 지침을 따릅니다. 약 5분 안에 Logto 통합을 완료할 수 있습니다!

제 통합 코드는 다음과 같습니다:

여기 유용한 팁이 있습니다: 우리의 로그인 페이지에는 "로그인"과 "등록" 버튼이 모두 있습니다. "등록" 버튼은 Logto의 등록 페이지로 직접 연결됩니다. Logto의 첫 번째 화면 기능을 통해 작동합니다. 이 기능은 사용자가 인증 흐름의 어떤 단계를 처음 보는지를 결정합니다.

여러 새로운 사용자가 예상되는 경우 기본값을 등록 페이지로 설정할 수 있습니다.

로그인 버튼을 클릭하면 Logto의 로그인 페이지로 이동합니다. 로그인(또는 등록)에 성공하면 축하합니다! 당신의 앱에 첫 번째 사용자가 생겼습니다 (여러분입니다)!

그리고 사용자를 로그아웃시키고 싶을 때 useLogto 훅에서 signOut 함수를 호출하십시오.

로그인 및 가입 방법 커스터마이징하기#

Logto 콘솔에서 왼쪽 메뉴의 "로그인 경험"을 클릭합니다. 그런 다음 "가입 및 로그인" 탭을 클릭합니다. 이 페이지에서 지침에 따라 Logto의 로그인/등록 방법을 구성합니다.

그리고 로그인 흐름은 다음과 같습니다:

다중 요소 인증 활성화#

Logto를 사용하면 MFA를 간단하게 활성화할 수 있습니다. Logto 콘솔에서 "다중 요소 인증" 버튼을 클릭하세요. 그런 다음 다중 요소 인증 페이지에서 활성화하세요.

그리고 MFA 흐름은 다음과 같습니다:

모든 것이 너무 간단합니다! 몇 분 안에 복잡한 사용자 인증 시스템을 설정했습니다!

다중 테넌트 조직 경험 추가하기#

이제 첫 번째 사용자가 생겼습니다! 그러나 이 사용자는 아직 어떤 조직에도 속해 있지 않으며, 우리는 아직 조직을 만들지 않았습니다.

Logto는 다중 테넌시에 대한 내장 지원을 제공합니다. Logto에서 원하는 만큼 조직을 만들 수 있습니다. 각 조직에는 여러 멤버가 있을 수 있습니다.

각 사용자는 Logto에서 자신의 조직 정보를 가져올 수 있습니다. 이는 다중 테넌시를 지원합니다

사용자의 조직 정보 가져오기#

Logto에서 사용자의 조직 정보를 얻으려면 다음 두 단계를 완료하십시오:

Logto Config에 조직 정보 접근을 선언하십시오. 이는 적절한 scopes 및 resources를 설정함으로써 수행됩니다.

Logto의 fetchUserInfo 메소드를 사용하여 사용자 정보, 조직 데이터를 포함하여 가져옵니다.

이 단계를 완료한 후에는 로그아웃하고 다시 로그인해야 합니다. 이는 요청된 범위와 리소스를 수정했기 때문입니다.

현재, 어떤 조직도 만들지 않은 상태입니다. 사용자도 어떤 조직에도 가입하지 않았습니다. 대시보드는 "아직 어떤 조직도 없습니다"를 표시할 것입니다.

다음으로, 우리 사용자를 위한 조직을 만들고, 그들을 추가할 것입니다.

Logto 덕분에 우리는 복잡한 조직 관계를 구축할 필요가 없습니다. 우리는 Logto에서 조직을 만들고, 사용자를 추가하기만 하면 됩니다. Logto가 모든 복잡성을 처리합니다. 조직을 생성하는 두 가지 방법이 있습니다:

1. Logto 콘솔을 통해 수동으로 조직 생성
2. Logto Management API를 사용하여 SaaS 흐름을 계획하여 사용자가 스스로 조직을 생성(작업 공간)을 할 수 있도록 합니다.

Logto 콘솔에서 조직 생성#

Logto 콘솔 왼쪽의 "조직" 메뉴 버튼을 클릭합니다. 조직을 생성합니다.

이제 당신은 첫 번째 조직을 가졌습니다.

다음으로 이 조직에 사용자를 추가합니다.

조직 세부사항 페이지로 이동합니다. 멤버 탭으로 전환합니다. "+ 멤버 추가" 버튼을 클릭합니다. 왼쪽 목록에서 로그인한 사용자를 선택합니다. 화면 하단 오른쪽의 "멤버 추가" 버튼을 클릭합니다. 이제 사용자를 이 조직에 성공적으로 추가했습니다.

앱 페이지를 새로 고칩니다. 이제 사용자가 조직에 속해 있음을 볼 수 있습니다!

셀프 서비스 조직 생성 경험 구현#

콘솔에서 조직을 생성하는 것으로는 충분하지 않습니다. SaaS 앱에는 최종 사용자가 손쉽게 자신의 작업 공간을 만들고 관리할 수 있는 흐름이 필요합니다. 이 기능을 구현하기 위해 Logto Management API를 사용합니다.

지침을 위해 Management API와 상호작용하기 문서를 확인하여 Logto와의 API 통신을 설정하십시오.

조직 인증 상호작용 흐름 이해하기#

조직 생성 흐름을 예로 들겠습니다. 조직 생성 프로세스가 어떻게 작동하는지 설명합니다:

이 흐름에는 두 가지 주요 인증 요구 사항이 있습니다:

1. 백엔드 서비스 API 보호:
   • 프론트엔드가 백엔드 서비스 API에 액세스하려면 인증이 필요합니다
   • API 엔드포인트는 사용자의 Logto Access Token을 검증함으로써 보호됩니다
   • 인증된 사용자만이 우리의 서비스에 액세스할 수 있습니다
2. Logto Management API에 액세스하기:
   • 백엔드 서비스는 Logto Management API를 안전하게 호출해야 합니다
   • Management API와 상호작용하기 가이드를 따라 설정합니다
   • 기계-대-기계 인증을 통해 접근 자격을 얻습니다

백엔드 API 보호하기#

먼저, 조직 생성을 위한 백엔드 서비스에 API 엔드포인트를 만듭니다.

우리의 백엔드 서비스 API는 인증된 사용자만 허용합니다. 우리는 Logto를 사용하여 우리의 API를 보호해야 합니다. 또한 현재 사용자의 정보(예: 사용자 ID)를 알아야 합니다.

Logto의 개념(및 OAuth 2.0)에서는 우리의 백엔드 서비스가 리소스 서버처럼 작동합니다. 사용자는 프론트엔드에서 받은 액세스 토큰으로 DocuMind 리소스 서버에 액세스합니다. 리소스 서버는 이 토큰을 검증하고, 유효하면 요청된 리소스를 반환합니다.

우리의 백엔드 서비스를 나타내는 API 리소스를 생성합시다.

Logto 콘솔로 이동하여

1. 오른쪽의 "API 리소스" 버튼을 클릭합니다.
2. "API 리소스 생성"을 클릭합니다. 팝업에서 Express를 선택합니다.
3. API 이름으로 "DocuMind API"를 입력합니다. API 식별자에는 "https://api.documind.com"을 사용합니다.
4. 생성 버튼을 클릭합니다.

이 API 식별자 URL에 대해 걱정하지 마세요. 이 URL은 Logto에서 귀하의 API의 고유 식별자일 뿐 실제 백엔드 서비스 URL과는 관련이 없습니다.

이제 API 리소스를 사용하는 방법에 대한 튜토리얼을 볼 수 있습니다. 이 튜토리얼을 따르거나 아래 단계를 따르십시오.

POST /organizations 엔드포인트를 보호하기 위해 requireAuth 미들웨어를 만듭니다.

이 미들웨어를 사용하려면 다음 환경 변수가 필요합니다:

• LOGTO_JWKS_URL
• LOGTO_ISSUER

이 변수들은 Logto 테넌트의 OpenID Configuration 엔드포인트에서 구하십시오. https://<your-tenant-id>.logto.app/oidc/.well-known/openid-configuration를 방문하십시오. 반환된 JSON에서 필요한 정보를 찾을 수 있습니다:

이제 requireAuth 미들웨어를 우리의 POST /organizations 엔드포인트에서 사용합니다.

이로써 우리의 POST /organizations 엔드포인트가 보호되었습니다. 유효한 Logto 액세스 토큰을 가진 사용자만이 이 엔드포인트에 액세스할 수 있습니다.

이제 프론트엔드에서 Logto로부터 토큰을 얻을 수 있으며, 사용자는 이 토큰을 통해 백엔드 서비스 API를 통해 조직을 만들 수 있습니다. 이 미들웨어는 또한 사용자 ID를 제공합니다. 이는 사용자를 조직에 추가할 때 도움이 됩니다.

프론트엔드 코드에서 이 API 리소스를 Logto config에 선언하십시오. 리소스 배열에 그 식별자를 추가하십시오.

이전과 마찬가지로, 사용자는 우리가 Logto config를 업데이트한 후 다시 로그인해야 합니다.

대시보드에서 조직을 만들 때 Logto 액세스 토큰을 얻고, 이 토큰을 사용하여 우리의 백엔드 서비스 API에 액세스합니다.

이제 DocuMind 백엔드 서비스 API에 올바르게 접근할 수 있습니다.

Logto Management API 호출#

이제 Logto Management API를 사용한 조직 생성을 구현해보겠습니다.

첨단 서비스 요청과 마찬가지로, Logto에서 머신-대-머신 인증으로 액세스 토큰을 얻어야 합니다. Management API와 상호작용하기를 참조하십시오.

Logto 콘솔의 애플리케이션 페이지로 이동합니다. 머신-대-머신 애플리케이션을 만듭니다. "Logto Management API access" 역할을 지정합니다. 토큰 엔드포인트, 앱 ID, 앱 비밀을 복사합니다. 이러한 정보를 액세스 토큰에 사용합니다.

이제 이 M2M 애플리케이션을 통해 Logto Management API 액세스 토큰을 얻을 수 있습니다.

이 액세스 토큰을 사용하여 Logto Management API를 호출합니다.

우리는 이러한 Management API를 사용할 것입니다:

• POST /api/organizations: 조직 생성 (참조: 조직 생성 API 레퍼런스)
• POST /api/organizations/{id}/users: 조직에 사용자 추가 (참조: 조직에 사용자 추가 API 레퍼런스)

이제 Logto Management API를 통한 조직 생성과 사용자 추가를 구현했습니다.

이 기능을 대시보드에서 테스트해 봅시다.

그리고 "조직 생성" 버튼을 클릭하세요

생성이 성공적으로 완료되었습니다!

다음 단계는 조직에 사용자를 초대하는 것입니다. 이 기능은 우리의 튜토리얼에서 아직 구현하지 않았습니다. 이미 Management API 사용법을 배웠습니다. 이 블로그 게시물 사용자 협업을 다중 테넌트 앱에 구현하는 방법을 참고하여 이 기능을 쉽게 구현할 수 있습니다.

다중 테넌트 앱에 접근 제어 구현하기#

이제 조직 접근 제어로 넘어가 보겠습니다.

우리는 이렇게 달성하고자 합니다:

• 사용자는 자신이 속한 조직 리소스에만 액세스할 수 있습니다: Logto의 organizational token 을 통해 구현할 수 있습니다
• 사용자는 조직 내에서 특정 역할을 가지고 있으며, 이 역할에 따라 승인된 작업을 수행합니다: Logto의 조직 템플릿 기능을 통해 구현할 수 있습니다

이러한 기능을 어떻게 구현하는지 보겠습니다.

Logto 조직 토큰 사용#

이전에 언급한 Logto 액세스 토큰과 유사하게, Logto는 특정 리소스에 대응하는 액세스 토큰을 발행하며, 사용자는 이 토큰으로 보호된 리소스에 접근합니다. 이에 대응하여, Logto는 특정 조직에 대응하는 조직 토큰을 발행하며, 사용자는 이 토큰으로 보호된 조직 리소스에 접근합니다.

프론트엔드 애플리케이션에서는 Logto의 getOrganizationToken 메소드를 사용하여 특정 조직에 액세스하기 위한 토큰을 얻을 수 있습니다.

여기서 organizationId는 사용자가 속한 조직의 ID입니다.

getOrganization 또는 조직 기능을 사용하기 전에 Logto config에 urn:logto:scope:organizations 범위 및 urn:logto:resource:organization 리소스가 포함되어야 합니다. 이미 이를 선언했으므로 반복하지 않겠습니다.

우리의 조직 페이지에서는 조직의 문서를 가져올 때 조직 토큰을 사용합니다.

이 구현에서 주목해야 할 두 가지 중요한 점이 있습니다:

1. getOrganizationToken에 전달하는 organizationId가 현재 사용자에게 속하는 조직 id가 아닌 경우 이 메소드는 토큰을 얻을 수 없으므로 사용자가 자신이 속한 조직에만 액세스할 수 있도록 보장합니다.
2. 조직 리소스를 요청할 때, 우리는 액세스 토큰 대신 조직 토큰을 사용합니다. 왜냐하면 조직에 속한 리소스에 대해, 우리는 사용자 권한 대신 조직 권한 제어를 사용하고자 합니다(우리가 나중에 GET /documents API를 구현할 때 이를 더 잘 이해할 수 있을 것입니다).

다음으로, 우리의 백엔드 서비스에서 GET /documents API를 만듭니다. POST /organizations API를 보호하기 위해 API 리소스를 사용하는 것과 유사하게, 우리는 조직별 리소스 식별자를 사용하여 GET /documents API를 보호합니다.

먼저 조직 리소스를 보호하기 위한 requireOrganizationAccess 미들웨어를 만듭니다.

그런 다음 requireOrganizationAccess 미들웨어를 사용하여 GET /documents API를 보호합니다.

이렇게 조직 토큰을 사용하여 조직 리소스에 액세스하는 것을 구현했습니다. 백엔드 서비스에서는 조직 ID에 따라 데이터베이스에서 해당 리소스를 가져올 수 있습니다.

일부 소프트웨어는 조직 간 데이터 격리를 필요로 합니다. 추가 논의 및 구현은 블로그 게시물: PostgreSQL을 사용한 다중 테넌시 구현: 간단한 실세계를 예제로 배우기를 참조하십시오.

조직 수준의 역할 기반 접근 제어 설계 구현#

조직 리소스에 액세스할 때 조직 토큰을 사용하는 것을 구현했습니다. 이제 RBAC를 사용하여 조직 내 사용자 권한 제어를 구현할 것입니다.

DocuMind에는 관리자와 협력자라는 두 가지 역할이 있다고 가정해 봅시다.

관리자는 문서를 생성하고 액세스할 수 있는 반면, 협력자는 문서에만 액세스할 수 있습니다.

따라서 우리의 조직은 관리자와 협력자라는 두 가지 역할을 필요로 합니다.

관리자는 read:documents와 create:documents 권한을 모두 가지고 있고, 협력자는 read:documents 권한만을 가지고 있습니다.

• 관리자
  • read:documents
  • create:documents
• 협력자
  • read:documents

이 시점에서 Logto의 조치 템플릿 기능을 사용합니다.

조직 템플릿은 모든 조직에 적용되는 접근 제어 모델의 청사진입니다: 이는 모든 조직에 적용되는 역할과 권한을 정의합니다.

왜 조직 템플릿일까요?

왜냐하면 확장성은 SaaS 제품에서 가장 중요한 요구 사항 중 하나입니다. 즉, 한 클라이언트에게 효과가 있는 것은 모든 클라이언트에서 효과가 있어야 합니다.

Logto 콘솔 > 조직 템플릿 > 조직 권한으로 이동하여 read:documents와 create:documents 두 권한을 만듭니다.

그런 다음 조직 역할 탭으로 이동하여 관리자와 협력자라는 두 사용자 역할을 만들고, 이들 역할에 적절한 권한을 할당합니다.

이렇게 해서 각 조직에 대한 RBAC 권한 모델을 만들었습니다.

다음으로 우리의 조직 세부사항 페이지로 이동하여 조직 멤버에게 적절한 역할을 할당합니다.

이제 우리 조직의 사용자가 역할을 가지고 있습니다! 이 단계를 Logto Management API로 수행할 수 있습니다:

이제 사용자의 권한을 확인하여 사용자 권한 제어를 구현할 수 있습니다.

우리의 코드에서는 사용자의 조직 토큰이 권한 정보를 담도록 하고, 백엔드에서 이 권한을 검증합니다.

프론트엔드 코드의 Logto config에서는 사용자가 조직 내에서 요청해야 할 권한을 선언해야 합니다. read:documents와 create:documents 권한을 scopes에 추가합시다.

항상 그렇듯이, 사용자의 구성을 적용하기 위해 사용자에게 다시 로그인하도록 하십시오.

그런 다음, 백엔드의 requireOrganizationAccess 미들웨어에 사용자 권한 검증을 추가합니다.

그런 다음 POST /documents API를 만들고, 예전과 같은 방식으로 config를 사용하여이 요구 사항을 보호하십시오.

이렇게 해서, 우리는 사용자 권한을 확인하여 조직 리소스에 대한 사용자 권한 제어를 구현했습니다.

프론트엔드에서는 조직 토큰을 디코딩하여 사용자 권한 정보를 확인하거나 Logto의 getOrganizationTokenClaims 메소드를 호출하여 이를 수행할 수 있습니다.

주어지는 권한을 확인하여 페이지 요소를 제어하십시오.

다중 테넌트 앱 기능 추가하기#

지금까지 우리는 다중 테넌트 SaaS 시스템에서 기본 사용자 및 조직 기능을 구현했습니다! 그러나 조직별 로그인 페이지 브랜딩 사용자 정의, 특정 도메인 이메일을 가진 사용자를 특정 조직에 자동으로 추가하는 것, 엔터프라이즈 수준 SSO 기능 통합과 같은 몇 가지 기능을 다루지 않았습니다.

이들은 모두 박스 밖의 기능입니다. 이 기능들에 대한 자세한 내용은 Logto 문서에서 찾을 수 있습니다.

요약#

처음에 얼마나 압도적으로 느껴졌는지 기억하세요? 사용자, 조직, 권한, 엔터프라이즈 기능... 이 모든 것은 끝없는 산을 오르는 것처럼 보였습니다.

하지만 우리가 이뤄낸 것을 보십시오:

• 여러 로그인 옵션과 MFA 지원이 있는 완전한 인증 시스템
• 다중 멤버십을 지원하는 유연한 조직 시스템
• 조직 내에서 역할 기반 접근 제어

그리고 가장 좋은 점은? 우리는 바퀴를 새로 발명할 필요가 없었습니다. Logto 같은 현대적인 도구를 활용함으로써 몇 달이 걸릴 수 있었던 개발을 몇 시간 만에 완성할 수 있었습니다.

이 튜토리얼의 전체 소스 코드는 다중 테넌트 SaaS 샘플에서 확인할 수 있습니다.

이것이 2025년의 현대적 개발의 힘입니다 - 우리는 인프라와 씨름하는 대신 독특한 제품 기능 구축에 집중할 수 있습니다. 이제 여러분의 차례입니다. 훌륭한 무언가를 만들어 보세요!

Logto Cloud에서부터 Logto OSS까지 Logto의 모든 기능을 Logto 웹사이트에서 탐색하거나 Logto 클라우드에 오늘 등록하세요.