112 lines
9.7 KiB
Markdown
112 lines
9.7 KiB
Markdown
---
|
|
title: Auth0 — Multi-tenant SaaS Tenant Resolution (Subdomain, JWT, Header)
|
|
source_type: company-tech-blog
|
|
status: raw
|
|
confidence: medium
|
|
url: https://auth0.com/blog/using-nextjs-and-auth0-to-build-a-multi-tenant-saas/
|
|
archive_url:
|
|
tags: [ca-multi-tenancy, auth0, jwt, subdomain, tenant-resolution, company-tech-blog]
|
|
related_projects: [ca-skeleton-operational-contract]
|
|
related_branches: [feature-tenant-context-policy, feature-repository-access-permission-contract]
|
|
created: 2026-05-22
|
|
last_reviewed: 2026-05-27
|
|
---
|
|
|
|
# Auth0 — Multi-tenant Tenant Resolution Patterns
|
|
|
|
> Layer: `raw/company-tech-blogs/` — Auth0 (Okta 의 vendor product) 의 multi-tenant SaaS 가이드 발췌. Auth0 의 article/blog style 콘텐츠이므로 vendor product 명세가 아닌 **company-tech-blog / 사례 + 관점** 으로 취급.
|
|
> ca-tmpl 의 tenant resolution 우선순위 (JWT claim > X-Tenant-Id header > subdomain) 결정 대안 비교용. 본 자료 자체는 공식 best practice 가 아님.
|
|
|
|
## Parent / 활용 branch (필수)
|
|
|
|
| Branch | 이 자료가 정당화하는 결정 |
|
|
|---|---|
|
|
| [[raw/branch-notes/feature-tenant-context-policy]] | tenant resolution 우선순위 (JWT claim > header > subdomain) 결정 시 industry vendor 의 대안 비교 baseline |
|
|
| [[raw/branch-notes/feature-repository-access-permission-contract]] | CROSS_TENANT_ADMIN capability 도입 시 tenant 식별자가 어느 경로에서 오는지의 trust boundary 결정 근거 |
|
|
| [[raw/project-notes/ca-skeleton-operational-contract]] | §18. Control Plane Contract (Tenant Context Policy) — JWT 우선 정책의 vendor 비교 reference |
|
|
|
|
## 컨텍스트 / 왜 저장했는지
|
|
|
|
ca-tmpl 의 tenant resolution 우선순위(JWT claim > X-Tenant-Id header > subdomain)와 직접 비교 가능한 자료. Auth0 는 **JWT claim only**, **subdomain**, **organization parameter** 3가지를 모두 다룸. 단, 본 URL 은 현재 (2026-05-27 확인) 404 응답 — 인용은 과거 정독 시점의 요지 정리 이며 verbatim 재검증이 필요한 상태.
|
|
|
|
## 출처 / Source
|
|
|
|
- 원본 URL: https://auth0.com/blog/using-nextjs-and-auth0-to-build-a-multi-tenant-saas/ ← **2026-05-27 확인 시 HTTP 404**. 원본 페이지 이전/삭제 가능성.
|
|
- 보조 (개념): https://auth0.com/docs/get-started/auth0-overview/create-tenants/multiple-tenants ← 별도 페이지로 분리되어 있음 (현재도 404 응답, 위치 이전 추정)
|
|
- 저자 / 조직: Auth0 (Okta 의 IAM vendor) Blog
|
|
- 발행일: 미상 (rolling blog, 원문 미회수)
|
|
- 마지막 확인일: 2026-05-27 — **본문 verbatim 재검증 불가 (URL 404)**
|
|
|
|
## 핵심 인용 / Key quotes (verbatim)
|
|
|
|
> ⚠️ **검증 상태**: 원본 URL 이 2026-05-27 시점 404 — 아래 인용은 **과거 정독 시 요지 정리 본** 이며 verbatim 재검증 불가. wiki/concepts 추출 시 archive.org 스냅샷 또는 대체 URL 확인 필수.
|
|
|
|
> [§Tenant identification — 과거 정독] "There are several ways to identify a tenant: by the URL (subdomain or path), by a custom header, or by a claim in the access token."
|
|
|
|
> [§Token-based — 과거 정독] "Using a claim in the access token is the most secure approach because the token is signed and cannot be tampered with by the client."
|
|
|
|
> [§Subdomain — 과거 정독] "Subdomain-based tenant identification is user-friendly (`acme.example.com`) but requires wildcard DNS + TLS certificate (wildcard or per-tenant)."
|
|
|
|
> [§Header — 과거 정독] "Custom headers like `X-Tenant-Id` are simple but require strict validation; do not trust the header without authorization."
|
|
|
|
## Claims Extracted / 추출된 주장
|
|
|
|
> 본 raw 의 인용이 verbatim 재검증 불가 (URL 404) 이므로 모든 claim 의 strength 를 `needs-confirmation` 으로 강등. wiki/concepts 추출 전 archive.org 스냅샷 또는 대체 출처로 보강 필수.
|
|
|
|
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|
|
|---|---|---|---|---|---|
|
|
| AUTH0-TR-C1 | tenant 식별 방식은 URL (subdomain/path), custom header, access token claim 의 3가지 카테고리로 분류 가능 | [§Tenant identification — 과거 정독] "There are several ways to identify a tenant: by the URL (subdomain or path), by a custom header, or by a claim in the access token." | `needs-confirmation` | SaaS multi-tenant 환경의 tenant resolution 선택 | 이 3가지가 모든 사례를 포괄한다는 뜻 아님 (예: mTLS cert SAN, IP allowlist 기반은 별도). 원본 verbatim 재검증 불가 |
|
|
| AUTH0-TR-C2 | access token claim 기반 tenant 식별이 가장 안전 — token 이 signed 되어 클라이언트가 변조 불가하기 때문 | [§Token-based — 과거 정독] "Using a claim in the access token is the most secure approach because the token is signed and cannot be tampered with by the client." | `needs-confirmation` | OAuth/OIDC 기반 access token 발급 환경 | "가장 안전" 의 정량 기준 없음. token leak / replay 위험은 별도. 원본 verbatim 재검증 불가 |
|
|
| AUTH0-TR-C3 | subdomain 기반 식별은 UX 친화적 (`acme.example.com`) 이나 wildcard DNS + TLS 인증서 (wildcard 또는 per-tenant) 필요 | [§Subdomain — 과거 정독] "Subdomain-based tenant identification is user-friendly (`acme.example.com`) but requires wildcard DNS + TLS certificate (wildcard or per-tenant)." | `needs-confirmation` | tenant 마다 별도 hostname 노출하는 SaaS | Let's Encrypt rate limit 등 구체 운영 제약은 별도 자료에서. 원본 verbatim 재검증 불가 |
|
|
| AUTH0-TR-C4 | `X-Tenant-Id` 같은 custom header 는 단순하나 strict validation 필요 — authorization 없이 header 를 신뢰하면 안 됨 | [§Header — 과거 정독] "Custom headers like `X-Tenant-Id` are simple but require strict validation; do not trust the header without authorization." | `needs-confirmation` | internal/admin API 또는 인증 후 downstream propagation | "신뢰 금지" 가 절대 금지인지 / authorization 결합 시 허용인지의 경계는 인용에 명시 없음. 원본 verbatim 재검증 불가 |
|
|
|
|
## Usage Boundaries / 적용 경계
|
|
|
|
- **이 자료가 직접 증명하는 것**:
|
|
- 인용 자체의 verbatim 검증 불가 (URL 404) → **아무것도 직접 증명하지 않음** 으로 취급. wiki 추출 시 archive.org 스냅샷 또는 대체 vendor 자료로 보강 필요.
|
|
- **이 자료가 증명하지 않는 것**:
|
|
- JWT claim 기반 tenant 식별이 Auth0 공식 best practice 라는 주장 (Auth0 docs 본문이 아닌 blog 자료이며 현재 URL 도 404)
|
|
- subdomain 의 운영 비용 정량값 (cert 발급 속도, DNS propagation time 등)
|
|
- X-Tenant-Id header 사용 시 정확히 어떤 authorization 결합이 충분한가
|
|
- 다른 vendor (Okta, Cognito, Keycloak) 도 동일 우선순위를 권장하는지
|
|
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
|
|
- ca-tmpl 의 "JWT claim > header > subdomain" 우선순위가 Auth0 권고와 일치한다는 주장의 verbatim 근거 — archive.org 또는 현재 유효한 Auth0 docs/blog URL 재수집
|
|
- header 기반 tenant 가 admin/internal 에서만 허용된다는 ca-tmpl 결정의 출처 보강 (Auth0 자료가 아니라 다른 vendor doc 확인 권고)
|
|
|
|
## 메모 / Notes (내 해석, 미검증)
|
|
|
|
> 본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.
|
|
|
|
- isolation 수준: tenant resolution 자체는 isolation과 직교. 어떤 isolation 모델이든 resolution은 필요.
|
|
- tenant resolution 방식 비교:
|
|
- **JWT claim only**: token 발급 시점에 tenant 고정. token 재발급 없이는 tenant 전환 불가. 가장 안전.
|
|
- **Subdomain**: UX 친화적, B2B SaaS에서 흔함. 단점: wildcard TLS, DNS, CORS 설정 복잡, local 개발 환경 어려움 (hosts file 수정).
|
|
- **X-Tenant-Id header**: 가장 단순. admin/internal API에 적합. external에서 신뢰 금지.
|
|
- **Path-based** (`/t/{tenant}/...`): routing 자연스럽지만 모든 URL에 prefix → API client 코드 변경 큼.
|
|
- scale 한계: resolution 자체는 무관. 다만 subdomain은 DNS 캐시/TLS 인증서 발급 속도가 tenant onboarding 속도를 제약.
|
|
- 운영 복잡도:
|
|
- JWT only: identity provider와 강결합. token rotation 시점에 tenant 정보 갱신.
|
|
- subdomain: DNS/TLS 운영 비용. Let's Encrypt rate limit 주의.
|
|
- security:
|
|
- header 단독은 spoofing 위험 → 반드시 JWT/session으로 cross-check
|
|
- JWT claim은 signature 검증으로 spoofing 방지
|
|
- subdomain은 host header injection 주의
|
|
- ca-tmpl과의 차이:
|
|
- ca-tmpl은 **JWT claim 우선, header는 admin/internal에서만, subdomain은 fallback**. Auth0 권장(JWT 우선)과 일치 — 단 본 raw 자료로는 verbatim 입증 불가.
|
|
- "JWT only로 header 차단"은 ca-tmpl이 admin/internal 운영성을 위해 거부한 대안. 외부 trust boundary가 적은 단일 IdP 환경에서는 가능.
|
|
|
|
## Related / 관련
|
|
|
|
- 같은 주제 다른 raw:
|
|
- [[raw/company-tech-blogs/multitenancy-atlassian-tenant-context]]
|
|
- [[raw/company-tech-blogs/multitenancy-subdomain-resolution-patterns]]
|
|
- [[raw/company-tech-blogs/multitenancy-stripe-citus-schema-per-tenant]]
|
|
- [[raw/official-docs/multitenancy-azure-architecture-patterns]]
|
|
- [[raw/official-docs/multitenancy-aws-saas-tenant-isolation-whitepaper]]
|
|
- 인용하는 branch / project:
|
|
- [[raw/branch-notes/feature-tenant-context-policy]]
|
|
- [[raw/branch-notes/feature-repository-access-permission-contract]]
|
|
- [[raw/project-notes/ca-skeleton-operational-contract]] (§18 Control Plane Contract / Tenant Context Policy)
|
|
- 대안 그룹: **Topic 6 — Multi-tenancy** (대안 6종: opt-in shared DB / subdomain-based / JWT claim only / schema-per-tenant / db-per-tenant / hybrid Deployment Stamps). 본 source 의 위치: tenant resolution 비교 (JWT claim / subdomain / header).
|
|
- 인용한 wiki 요약: (미작성)
|