9.7 KiB
title, source_type, status, confidence, url, archive_url, tags, related_projects, related_branches, created, last_reviewed
| title | source_type | status | confidence | url | archive_url | tags | related_projects | related_branches | created | last_reviewed | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Auth0 — Multi-tenant SaaS Tenant Resolution (Subdomain, JWT, Header) | company-tech-blog | raw | medium | https://auth0.com/blog/using-nextjs-and-auth0-to-build-a-multi-tenant-saas/ |
|
|
|
2026-05-22 | 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-Idare 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 요약: (미작성)