Bygg en multi-tenant SaaS-applikation: En komplett guide från design till implementering

Hur byggs appar som Notion, Slack eller Figma? Dessa multi-tenant SaaS-applikationer ser enkla ut att använda, men att bygga en själv? Det är en helt annan historia.

När jag först tänkte på att bygga en sådan komplex sak, exploderade mitt sinne:

• Användare behöver flera inloggningsalternativ (e-post, Google, GitHub)
• Varje användare kan skapa och tillhöra flera organisationer
• Olika behörighetsnivåer inom varje organisation
• Företagsorganisationer som kräver automatisk anslutning för specifika e-postdomäner
• MFA-krav för känsliga operationer
• ...

"Chef, låt oss prata om produktdesign om två veckor. Jag sitter fast just nu."

Men när jag faktiskt började arbeta med det, upptäckte jag att det inte är så skrämmande som det verkar.

Jag har precis byggt ett system med alla dessa funktioner på MINDRE ÄN 2 TIMMAR!

Jag kommer att visa dig exakt hur du designar och implementerar ett sådant system från grunden - och du kommer att bli förvånad över hur enkelt det verkligen är år 2025 med moderna verktyg och rätt arkitektoniskt tillvägagångssätt.

Den kompletta källkoden finns tillgänglig i slutet av denna artikel. Låt oss dyka in!

Vi börjar med en AI-dokumentations-SaaS-produkt som heter DocuMind.

DocuMind är en AI-dokumentations-SaaS-produkt designad med en multi-tenant-modell för att stödja enskilda användare, småföretag och företag.

Plattformen erbjuder kraftfulla AI-funktioner för dokumenthantering, inklusive automatisk sammanfattningsgenerering, nyckelpunktsextraktion och intelligenta innehållsrekommendationer inom organisationer.

Vilka funktioner krävs för SaaS-autentisering och auktorisering?#

Först, låt oss granska de nödvändiga kraven. Vilka funktioner behöver du?

Multi-tenant arkitektur#

För att möjliggöra en multi-tenant arkitektur behöver du ett entitetslager som kallas organisation. Föreställ dig en enda pool av användare som kan komma åt flera arbetsytor. Varje organisation representerar en arbetsyta, och användare bibehåller en enda identitet medan de får tillgång till olika arbetsytor (organisationer) baserat på sina tilldelade roller.

Det är en allmänt använd funktion i autentiseringsleverantörer. En organisation i ett identitetshanteringssystem motsvarar din SaaS-apps arbetsyta, projekt eller hyresgäst.

Medlemskap#

En medlem är ett tillfälligt koncept som används för att indikera en identitets medlemsstatus inom en organisation.

Till exempel, Sarah registrerar sig för din app med sin e-post, [email protected]. Hon kan tillhöra olika arbetsytor. Om Sarah är en del av Arbetsyta A men inte Arbetsyta B betraktas hon som en medlem av Arbetsyta A men inte Arbetsyta B.

Roll- och behörighetsdesign#

I en multi-tenant arkitektur behöver användare roller med specifika behörigheter för att få tillgång till sina hyresgästresurser. Behörigheter är detaljerade åtkomstkontroller som definierar specifika åtgärder, som read: order eller write: order. De bestämmer vilka åtgärder som kan utföras på specifika resurser.

Roller är en uppsättning behörigheter som tilldelas medlemmar i en multi-tenant miljö.

Du behöver definiera dessa roller och behörigheter, sedan tilldela roller till användare, och ibland kan det inkludera automatiserade processer. Till exempel:

1. Användare som ansluter sig till en organisation får automatiskt rollen medlem.
2. Den första användaren som skapar en arbetsyta tilldelas automatiskt rollen admin.

Registrerings- och inloggningsflöde#

Säkerställ en användarvänlig och säker registrerings- och autentiseringsprocess, inklusive grundläggande inloggnings- och registreringsalternativ:

1. Inloggning med e-post och lösenord: Traditionell inloggningsmetod med e-post och lösenord.
2. Lösenordslös inloggning: Använd e-postverifieringskoder för enkel och säker åtkomst.
3. Kontohantering: Ett kontocenter där användare kan uppdatera sin e-post, sitt lösenord och andra detaljer.
4. Social inloggning: Alternativ som Google och GitHub för snabb inloggning.
5. Multi-Factor Authentication (MFA): Förbättra säkerheten genom att tillåta inloggning via autentiseringsappar som Duo.

Hyresgästskapande och inbjudan#

I en multi-tenant SaaS-app är en nyckelskillnad i användarflödet behovet av att stödja hyresgästskapande och medlemsinbjudningar. Denna process kräver noggrann planering och genomförande eftersom den spelar en nyckelroll i produktaktivering och tillväxt.

Här är några typiska användarflöden du behöver överväga:

Här är några vanliga scenarier som finns i nästan alla SaaS-appar. Använd dessa som referens för att inspirera ditt produkt- och designteam, och känn dig fri att skapa dina egna flöden vid behov.

Teknisk arkitektur och systemdesign#

När vi förstår alla produktkrav, låt oss gå vidare till implementeringen.

Definiera autentiseringsstrategi#

Autentisering ser skrämmande ut. Användare behöver:

• Sign-up/login med e-post & lösenord
• Enklicksinloggning med Google/Github
• Återställning av lösenord när de glömmer
• Team-wide inloggning för företagskunder
• ...

Att implementera bara dessa grundläggande funktioner kan ta veckor av utveckling.

Men nu, behöver vi inte bygga NÅGON av dessa själva!

Moderna autentiseringsleverantörer (jag kommer att välja Logto den här gången) har paketera alla dessa funktioner för oss. Autentiseringsflödet är enkelt:

Från veckor av utveckling till 15 minuter av inställning, Logto hanterar alla komplexa flöden för oss! Vi kommer att täcka integrationsstegen i implementeringsavsnittet senare. Nu kan vi fokusera på att bygga DocuMinds kärnfunktioner!

Upprätta multi-tenant arkitektur#

Organisationssystemet möjliggör att användare kan skapa och gå med i flera organisationer. Låt oss förstå de grundläggande relationerna:

I detta system kan varje användare tillhöra flera organisationer, och varje organisation kan ha flera medlemmar.

Aktivera åtkomstkontroll i multi-tenant app#

Rollbaserad åtkomstkontroll (RBAC) är viktig för att säkerställa säkerhet och skalbarhet i multi-tenant SaaS-applikationer.

I en multi-tenant app är designen av behörigheter och roller vanligtvis konsekvent, eftersom det kommer från produktdesignen. Till exempel, i flera arbetsytor finns det vanligtvis en admin-roll och en medlemsroll. Logto som en autentiseringsleverantör har följande organisationsnivå rollbaserat åtkomstkontrolldesign:

1. Enhetliga behörighetsdefinitioner: Behörigheter definieras på systemnivå och tillämpas konsekvent över alla organisationer, vilket säkerställer underhållbar och konsekvent behörighetshantering
2. Organisation mallar: Fördefinierade roll- och behörighetskombinationer genom organisationsmallar, vilket förenklar organisationens initiering

Behörighetsförhållandet ser ut så här:

Eftersom varje användare behöver sina egna roll(er) inom varje organisation måste relationen mellan roller och organisationer reflektera rollerna som tilldelas varje användare:

Vi har designat organisationssystemet och åtkomstkontrollsystemet och nu kan vi börja bygga vår produkt!

Teknologisk stack#

Jag valde en nybörjarvänlig, portabel stack:

1. Frontend: React (lätt att överföra till Vue/Angular/Svelte)
2. Backend: Express (enkel, intuitiv API)

Varför separera frontend och backend? För att den har en tydlig arkitektur, lätt att lära och enkel att byta stackar. Och för autentiseringsleverantörer använder jag Logto som exempel.

Och för de följande guiderna, dess mönster här fungerar med: Alla frontend, alla backend och alla autentiseringssystem.

Lägg till grundläggande autentiseringsflöde till din app#

Det här är det enklaste steget. Vi behöver bara integrera Logto i vårt projekt. Sedan kan vi konfigurera användarinloggnings/registreringsmetoder i Logto-konsolen baserat på våra behov.

Installera Logto till din app#

Först, logga in på Logto Cloud. Du kan registrera ett gratis konto om du inte har ett. Skapa en utvecklingshyresgäst för testning.

I hyresgästkonsolen, klicka på "Applikation"-knappen till vänster. Välj sedan React för att börja bygga vår applikation.

Följ guiden på sidan. Du kan slutföra Logto-integrationen på cirka 5 minuter!

Här är min integrationskod:

Här är ett användbart knep: Vår inloggningssida har både Logga in och Registrera knappar. Registreringsknappen leder direkt till Logtos registreringssida. Detta fungerar genom Logtos första skärm funktion. Den avgör vilket steg av autentiseringsflödet användare ser först.

Du kan standardisera registreringssidan när din produkt förväntar sig många nya användare.

Efter att ha klickat inloggning, kommer du till Logtos inloggningssida. Vid lyckad inloggning (eller registrering), grattis! Din app har sin första användare (du)!

Och kalla signOut funktionen från useLogto kroken för att logga ut användaren när du vill.

Anpassa inloggnings- och registreringsmetoder#

I Logto-konsolen, klicka på "Inloggningsupplevelse" i menyn till vänster. Klicka sedan på fliken "Registrering och inloggning". På den här sidan, följ instruktionerna för att konfigurera Logtos inloggnings-/registreringsmetoder.

Och inloggningsflödet kommer att se ut så här:

Aktivera multi-factor authentication#

Med Logto är det enkelt att aktivera MFA. Klicka bara på knappen "Multi-factor auth" i Logto-konsolen. Aktivera det sedan på sidan för multifaktorautentisering.

Och MFA-flödet kommer att se ut så här:

Allt är så enkelt! Vi har satt upp ett komplext användarautentiseringssystem på bara några minuter!

Lägga till multi-tenant organisationupplevelse#

Nu har vi vår första användare! Men denna användare tillhör ännu ingen organisation, och vi har inte skapat några organisationer.

Logto erbjuder inbyggt stöd för multi-tenancy. Du kan skapa valfritt antal organisationer i Logto. Varje organisation kan ha flera medlemmar.

Varje användare kan få sin organisationsinformation från Logto. Detta möjliggör multi-tenancy stöd

Få en användares organisationsinformation#

För att få en användares organisationsinformation från Logto, följ dessa två steg:

Deklarera åtkomst till organisationsinformation i Logto Config. Det görs genom att ställa in lämpliga scopes och resources.

Använd Logtos fetchUserInfo metod för att få användarinformation, inklusive organisationsdata.

Efter att ha slutfört dessa steg behöver du logga ut och logga in igen. Detta är nödvändigt eftersom vi ändrade den begärda omfattningen och resursen.

Just nu har du inte skapat några organisationer. Användaren har heller inte anslutit sig till några organisationer. Instrumentpanelen kommer att visa "Du har ännu ingen organisation".

Nästa, vi ska skapa en organisation för våra användare och lägga till dem i den.

Tack vare Logto behöver vi inte bygga komplexa organisationsrelationer. Vi behöver bara skapa en organisation i Logto och lägga till användare i den. Logto hanterar all komplexitet för oss. Det finns två sätt att skapa organisationer:

1. Skapa organisationer manuellt via Logto-konsolen
2. Använd Logto Management API för att skapa organisationer, särskilt när du designar ett SaaS-flöde som låter användare skapa sina egna organisationer (arbetsytor).

Skapa organisation i Logto-konsolen#

Klicka på "Organisationer"-menyknappen på vänster sida av Logto-konsolen. Skapa en organisation.

Nu har du din första organisation.

Nästa, låt oss lägga till användaren i denna organisation.

Gå till organisationsdetaljsidan. Byt till fliken Medlemmar. Klicka på "+ Lägg till medlem"-knappen. Välj din inloggade användare från listan till vänster. Klicka på knappen "Lägg till medlemmar" längst ner till höger. Nu har du framgångsrikt lagt till användaren i denna organisation.

Uppdatera din APP-sida. Du kommer att se att användaren nu tillhör en organisation!

Implementera självbetjäningsorganisation skaparupplevelse#

Att skapa en organisation i konsolen är inte tillräckligt. Din SaaS-app behöver ett flöde som tillåter slutanvändare att enkelt skapa och hantera sina egna arbetsytor. För att implementera denna funktionalitet, använd Logto Management API.

För vägledning, kolla in Interact with Management API dokumentationen för att ställa in API-kommunikation med Logto.

Förstå organisationens autentiseringsinteraktionsflöde#

Låt oss ta organisationsskapande flöde som ett exempel. Här är hur organisationsskapande processen fungerar:

Detta flöde har två viktiga autentiseringskrav:

1. Skydda backend service API:
   • Frontend-åtkomst till vår backend service API kräver autentisering
   • API-endpoints skyddas genom att validera användarens Logto Access Token
   • Säkerställer att endast autentiserade användare kan komma åt våra tjänster
2. Åtkomst till Logto Management API:
   • Backend-service behöver säkert ringa Logto Management API
   • Följ guiden Interact with Management API för inställning
   • Använd Maskin-till-maskin autentisering för att erhålla åtkomstuppgifter

Skydda ditt backend-API#

Först, låt oss skapa en API-endpoint i vår backend-tjänst för att skapa organisationer.

Vår backend service API tillåter endast autentiserade användare. Vi behöver använda Logto för att skydda vårt API. Vi behöver också veta den aktuella användarens information (som användar-ID).

I Logtos koncept (och OAuth 2.0), fungerar vår backend-tjänst som en resursserver. Användare kommer åt DocuMind resursserver med en accesstoken från frontend. Resursservern verifierar denna token. Om den är giltig, returnerar den de begärda resurserna.

Låt oss skapa en API-resurs för att representera vår backend-tjänst.

Gå till Logto-konsolen.

1. Klicka på "API-resurser"-knappen till höger.
2. Klicka "Skapa API-resurs". Välj Express i popupen.
3. Fyll i "DocuMind API" som API-namn. Använd "https://api.documind.com" som API-identifierare.
4. Klicka skapa.

Oroa er inte för den här API-identifierarens URL. Det är bara ett unikt identifierare för ditt API i Logto. Det är inte relaterat till din faktiska backend-tjänsts URL.

Du kommer att se en handledning för att använda API-resursen. Du kan följa den handledningen eller våra steg nedan.

Låt oss skapa en "requireAuth"-mellanvara för att skydda vår POST /organisationer-endpoint.

För att använda denna mellanvara, behöver vi dessa miljövariabler:

• LOGTO_JWKS_URL
• LOGTO_ISSUER

Hämta dessa variabler från din Logto-hyresgästs OpenID-konfigureringsendpoint. Besök https://<din-hyresgäst-id>.logto.app/oidc/.well-known/openid-configuration. Du kommer att hitta den nödvändiga informationen i den returnerade JSON:

Nu använder vi requireAuth-mellanvaran i vår POST /organisationer-endpoint.

Detta skyddar vår POST /organisationer-endpoint. Endast användare med giltiga Logto access tokens kan komma åt den.

Vi kan nu få token från Logto i vår frontend. Användare kan skapa organisationer genom vår backend-tjänst med denna token. Mellanvaran ger oss också användar-id. Detta är användbart när vi lägger till användare i organisationer.

I frontendkoden, deklarera detta API-resurs i Logto-konfigurationen. Lägg till dess identifierare till resource-arrayen.

Som tidigare, användare behöver logga in igen efter vi uppdaterar Logto-konfigurationen.

I Dashboard, få Logto Access Token när du skapar en organisation. Använd denna token för att komma åt vår backend-tjänst API.

Nu kan vi korrekt komma åt DocuMind backend-tjänst API.

Ring Logto Management API#

Låt oss implementera organisationsskapande med Logto Management API.

Som frontend-förfrågningar till backend-tjänst, behöver backend-tjänst förfrågningar till Logto access tokens.

I Logto, använder vi Maskin-till-Maskin autentisering för access tokens. Se Interact with Management API.

Gå till applikationssidan i Logto-konsolen. Skapa en Maskin-till-Maskin applikation. Tilldela rollen "Logto Management API åtkomst". Kopiera token-endpoint, App ID och App Secret. Vi kommer att använda dessa för access tokens.

Nu kan vi få Logto Management API access tokens genom denna M2M-applikation.

Använd denna access token för att ringa Logto Management API.

Vi kommer att använda dessa Management API:er:

• POST /api/organisationer: Skapa organisation (se: Skapa organisation API-referens)
• POST /api/organisationer/{id}/användare: Lägg till användare i organisation (se: Lägg till användare i organisation API-referens)

Vi har nu implementerat organisationsskapande genom Logto Management API. Vi kan också lägga till användare i organisationer.

Låt oss testa denna funktion i Dashboard.

och klicka "Skapa Organisation"

Skapelse lyckades!

Nästa steg skulle vara att bjuda in användare till en organisation. Vi kommer inte att implementera denna funktion i vår handledning än. Du vet redan hur man använder Management API. Du kan referera till detta Hyresgästskapande och inbjudan som produktdesignreferens och enkelt implementera denna funktion genom att följa detta blogginlägg: How we implement user collaboration within a multi-tenant app.

Implementera åtkomstkontroll till din multi-tenant app#

Nu, låt oss gå vidare till organisationsåtkomstkontroll.

Vi vill uppnå:

• Användare kan endast komma åt resurser som tillhör deras egna organisationer: Detta kan göras genom Logtos organisationstoken
• Användare har specifika roller inom organisationer (innehållande olika behörigheter) för att utföra auktoriserade åtgärder: Detta kan implementeras genom Logtos organisationsmallfunktion

Låt oss se hur man implementerar dessa funktioner.

Använda Logto organisationstoken#

Precis som Logto access token vi nämnde tidigare, utfärdar Logto en access token som motsvarar en specifik resurs, och användare använder denna token för att komma åt skyddade resurser i backend-tjänst. Motsvarande utfärdar Logto ett organisationstoken som motsvarar en specifik organisation, och användare använder detta token för att komma åt skyddade organisationsresurser i backend-tjänst.

I frontend-applikationen kan vi använda Logtos getOrganizationToken metod för att erhålla en token för att komma åt en specifik organisation.

Här är organizationId är id för den organisation användaren tillhör.

Innan du använder getOrganization eller någon organisationsfunktioner behöver vi säkerställa att urn:logto:scope:organizations scope och urn:logto:resource:organization resurs ingår i Logto-konfigurationen. Eftersom vi redan har deklarerat dessa tidigare, kommer vi inte att upprepa det.

På vår organisationssida, använder vi organisationstoken för att hämta dokument inom organisationen.

Det finns två viktiga punkter att notera i denna implementering:

1. Om organizationId överförd till getOrganizationToken inte är ett organisations-id som tillhör den nuvarande användaren, kommer denna metod inte att kunna få en token, vilket säkerställer att användare endast kan komma åt sina egna organisationer.
2. När du begär organisationsresurser använder vi organisationstoken i stället för access token eftersom för resurser som tillhör en organisation, vill vi använda organisationsbehörighetskontroll i stället för användarbehörighetskontroll (du kommer att förstå detta bättre när vi implementerar GET /documents API senare).

Nu skapar vi en GET /documents API i vår backend tjänst. Precis som vi använder API-resurs för att skydda POST /organizations API, använder vi organisation-specifika resursindikatorer för att skydda GET /documents API.

Först, låt oss skapa en requireOrganizationAccess mellanvara för att skydda organisationsresurser.

Därefter använder vi requireOrganizationAccess mellanvara för att skydda GET /documents API.

På så sätt har vi implementerat användningen av organisationstoken för att få tillgång till organisationsresurser. I backend-tjänsten kan du hämta motsvarande resurser från databasen baserat på organisationens id.

Vissa programvaror kräver dataseparation mellan organisationer. För vidare diskussion och implementering, kan du referera till blogginlägget: Multi-tenancy implementation with PostgreSQL: Learn through a simple real-world example.

Implementera organisationsnivå rollbaserat åtkomstkontrolldesign#

Vi har implementerat användningen av organisationstoken för att få tillgång till organisationsresurser. Nästa, vi kommer att implementera användarbehörighetskontroll inom organisationer med RBAC.

Låt oss anta DocuMind har två roller: Admin och Medsamarbetare.

Administratörer kan skapa och komma åt dokument, medan Medsamarbetare kan bara komma åt dokument.

Därför behöver vår Organisation ha dessa två roller: Admin och Medsamarbetare.

Admin har både read:documents och create:documents behörigheter, medan Medsamarbetare har bara read:documents behörighet.

• Admin
  • read:documents
  • create:documents
• Medsamarbetare
  • read:documents

Detta är där Logtos organisationsmallfunktion kommer in.

En organisationsmall är en modell för åtkomstkontrollmodellen för varje organisation: det definierar rollerna och behörigheterna som tillämpas på alla organisationer.

Varför organisationsmall?

Eftersom skalbarhet är ett av de viktigaste kraven för SaaS-produkter. Med andra ord, vad som fungerar för en klient bör fungera för alla klienter.

Låt oss gå till Logto Konsol > Organisationmallar > Organisationsbehörigheter och skapa två behörigheter: read:documents och create:documents.

Gå sedan till organisationsroller-fliken för att skapa två användarroller: Admin och Medsamarbetare, och tilldela motsvarande behörigheter till dessa roller.

På så sätt har vi skapat en RBAC-behörighetsmodell för varje organisation.

Nästa, vi går till vår Organisationsdetaljsida för att tilldela lämpliga roller till våra medlemmar.

Nu har våra organisationsanvändare roller! Du kan uppnå dessa steg via Logto Management API:

Nu kan vi implementera användarbehörighetskontroll genom att kontrollera deras behörigheter.

I vår kod behöver vi göra användarens organisationstoken bära behörighetsinformation, och sedan verifiera dessa behörigheter i backend.

I frontendkodens Logto-konfiguration behöver vi deklarera de behörigheter användarna behöver begära inom organisationen. Låt oss lägga till read:documents och create:documents behörigheter till scopes.

Som vanligt, logga in igen med din användare för att göra dessa inställningar gälla.

Sedan i backend requireOrganizationAccess mellanvara, lägger vi till verifiering för användarbehörigheter.

Skapa sedan ett POST /documents API och använd requireOrganizationAccess mellanvara med requiredScopes konfiguration för att skydda detta API och det tidigare GET /documents API.

På så sätt har vi implementerat användarbehörighetskontroll genom att kontrollera användarbehörigheter.

I frontend kan du få användarbehörighetsinformation genom att avkoda organisationstoken eller anropa Logtos getOrganizationTokenClaims metod.

Kontrollera sidlement baserat på användarbehörigheter genom att kontrollera omfattningar i kraven.

Lägg till fler multi-tenant app funktioner#

Hittills har vi implementerat de grundläggande användar- och organisationsfunktionerna i ett multi-tenant SaaS-system! Men det finns fortfarande vissa funktioner vi inte har täckt, till exempel att anpassa inloggningssida varumärkning för varje organisation, automatiskt lägga till användare med specifika domän epost till vissa organisationer och integrera företagsnivå SSO-funktionalitet.

Dessa är alla out-of-the-box funktioner, och du kan hitta mer information om dessa funktioner i Logto-dokumentationen.

Sammanfattning#

Minns du hur överväldigande det kändes i början? Användare, organisationer, behörigheter, företagsfunktioner... det verkade som ett oändligt berg att bestiga.

Men titta på vad vi har åstadkommit:

• Ett komplett autentiseringssystem med flera inloggningsalternativ och MFA-stöd
• Ett flexibelt organisationssystem som stöder flera medlemskap
• Rollbaserad åtkomstkontroll inom organisationer

Och det bästa? Vi behövde inte uppfinna hjulet på nytt. Genom att utnyttja moderna verktyg som Logto, transformerade vi vad som kunde ha varit månaders utveckling till en fråga om timmar.

Den fullständiga källkoden för denna handledning finns tillgänglig på: Multi-tenant SaaS Sample.

Detta är kraften i modern utveckling år 2025 - vi kan fokusera på att bygga unika produktfunktioner istället för att kämpa med infrastruktur. Nu är det din tur att skapa något fantastiskt!

Utforska alla Logtos funktioner, från Logto Cloud till Logto OSS, på Logtos webbplats eller registrera dig Logto cloud idag.