Bouw een multi-tenant SaaS-applicatie: Een volledige gids van ontwerp tot implementatie

Hoe worden apps zoals Notion, Slack of Figma gebouwd? Deze multi-tenant SaaS-applicaties lijken eenvoudig in gebruik, maar er zelf een bouwen? Dat is een ander verhaal.

Toen ik voor het eerst nadacht over het bouwen van zo'n complex systeem, explodeerde mijn geest:

• Gebruikers hebben meerdere inlogopties nodig (e-mail, Google, GitHub)
• Elke gebruiker kan meerdere organisaties aanmaken en lid zijn van meerdere organisaties
• Verschillende toestemmingsniveaus binnen elke organisatie
• Enterprise-organisaties die automatisch lidmaatschap vereisen voor specifieke e-maildomeinen
• MFA-vereisten voor gevoelige bewerkingen
• ...

"Baas, laten we het over productontwerp hebben over twee weken. Ik zit nu vast in de modder."

Maar toen ik er echt aan begon te werken, vond ik dat het niet zo ontmoedigend is als het lijkt.

Ik heb net een systeem gebouwd met al deze functies in MINDER DAN 2 UUR!

Ik zal je precies laten zien hoe je zo'n systeem vanaf de basis ontwerpt en implementeert - en je zult verbaasd zijn over hoe eenvoudig het echt is in 2025 met moderne tools en de juiste architecturale benadering.

De volledige broncode is beschikbaar aan het einde van dit artikel. Laten we erin duiken!

We beginnen met een AI-documentatie SaaS-product genaamd DocuMind.

DocuMind is een AI-documentatie SaaS-product ontworpen met een multi-tenantmodel om individuele gebruikers, kleine bedrijven en ondernemingen te ondersteunen.

Het platform biedt krachtige AI-mogelijkheden voor documentbeheer, inclusief automatische samenvattingsgeneratie, het extraheren van belangrijke punten en intelligente inhoudsaanbevelingen binnen organisaties.

Welke functies zijn vereist voor SaaS-authenticatie en autorisatie?#

Laten we eerst de noodzakelijke vereisten herzien. Welke functies heb je nodig?

Multi-tenant architectuur#

Om een multi-tenant architectuur mogelijk te maken, heb je een entiteitslaag nodig genaamd organisatie. Stel je een enkele pool van gebruikers voor die toegang kunnen krijgen tot meerdere werkruimtes. Elke organisatie vertegenwoordigt een werkruimte en gebruikers behouden een enkele identiteit terwijl zij toegang krijgen tot verschillende werkruimtes (organisaties) op basis van hun toegekende rollen.

Het is een veelgebruikte functie bij authenticatieproviders. Een organisatie in een identiteitsbeheer-systeem komt overeen met de werkruimte, het project of de huurder van je SaaS-app.

Lidmaatschap#

Een lid is een tijdelijk concept dat wordt gebruikt om de lidmaatschapsstatus van een identiteit binnen een organisatie aan te geven.

Bijvoorbeeld, Sarah meldt zich aan bij jouw app met haar e-mail, [email protected]. Ze kan tot verschillende werkruimtes behoren. Als Sarah deel uitmaakt van Workspace A maar niet van Workspace B, wordt ze beschouwd als lid van Workspace A maar niet van Workspace B.

Rol- en permissie ontwerp#

In een multi-tenant architectuur hebben gebruikers rollen met specifieke permissies nodig om toegang te krijgen tot hun huurder-resources. Permissies zijn gedetailleerde toegangscontroles die specifieke acties definiëren, zoals read: order of write: order. Ze bepalen welke acties kunnen worden uitgevoerd op bepaalde resources.

Rollen zijn een verzameling van permissies toegewezen aan leden in een multi-tenant omgeving.

Je moet deze rollen en permissies definiëren, dan rollen toewijzen aan gebruikers, en soms kan het geautomatiseerde processen omvatten. Bijvoorbeeld:

1. Gebruikers die lid worden van een organisatie krijgen automatisch de lid-rol.
2. De eerste gebruiker die een werkruimte maakt, krijgt automatisch de beheerder-rol.

Registratie- en inlogstroom#

Zorg voor een gebruiksvriendelijke en veilige registratie- en authenticatieproces, inclusief basis inlog- en registratieopties:

1. E-mail en wachtwoord inloggen: Traditionele inlogmethode met e-mail en wachtwoord.
2. Wachtwoordloos inloggen: Gebruik e-mailverificatie codes voor gemakkelijke en veilige toegang.
3. Accountbeheer: Een accountcenter waar gebruikers hun e-mail, wachtwoord en andere gegevens kunnen bijwerken.
4. Sociaal inloggen: Opties zoals Google en GitHub voor snelle inlog.
5. Multi-Factor Authenticatie (MFA): Verhoog de beveiliging door inloggen toe te staan via authenticator-apps zoals Duo.

Tenantcreatie en uitnodigingen#

In een multi-tenant SaaS-app is een belangrijk verschil in de gebruikersstroom de noodzaak om tenantcreatie en ledenuitnodigingen te ondersteunen. Dit proces vereist zorgvuldige planning en uitvoering omdat het een sleutelrol speelt in productactivering en groei.

Hier zijn enkele typische gebruiksstromen die je moet overwegen:

Hier zijn enkele veelvoorkomende scenario's te vinden in bijna elke SaaS-app. Gebruik deze als referentie om je product- en ontwerpteam te inspireren, en voel je vrij om je eigen stromen te maken als dat nodig is.

Technische architectuur en systeemontwerp#

Zodra we alle productvereisten begrijpen, gaan we over naar de implementatie.

Definieer authenticatiestrategie#

Authenticatie lijkt eng. Gebruikers hebben nodig:

• E-mail & wachtwoord registratie/inloggen
• Éénklik inloggen met Google/Github
• Wachtwoordherstel wanneer ze het vergeten
• Teamwijd inloggen voor zakelijke klanten
• ...

Zelfs het implementeren van slechts deze basisfuncties zou weken ontwikkeling kunnen kosten.

Maar nu hoeven we geen van dit zelf te bouwen!

Moderne auth-providers (ik kies Logto deze keer) hebben al deze functies voor ons verpakt. De authenticatiestroom is eenvoudig:

Van weken ontwikkeling naar 15 minuten installatie, Logto verzorgt alle complexe stromen voor ons! We behandelen de integratiestappen later in de implementatiesectie. Nu kunnen we ons richten op het bouwen van DocuMind kernfuncties!

Multi-tenant architectuur tot stand brengen#

Het organisatiesysteem stelt gebruikers in staat meerdere organisaties te maken en lid te worden. Laten we de kernrelaties begrijpen:

In dit systeem kan elke gebruiker tot meerdere organisaties behoren, en elke organisatie kan meerdere leden hebben.

Toegangscontrole in multi-tenant app mogelijk maken#

Rol-gebaseerde toegangscontrole (RBAC) is belangrijk voor het waarborgen van veiligheid en schaalbaarheid in multi-tenant SaaS-applicaties.

In een multi-tenant app is het ontwerp van machtigingen en rollen meestal consistent, aangezien het voortkomt uit het productontwerp. Bijvoorbeeld, in meerdere werkruimtes is er meestal een admin-rol en een lid-rol. Logto als een auth-provider heeft het volgende ontwerp voor organisatie-niveau rol-gebaseerde toegangscontrole:

1. Eenvormige machtigingsdefinities: Machtigingen worden op systeemniveau gedefinieerd en gelden consistent voor alle organisaties, wat zorgt voor onderhoudbare en consistente machtigingsbeheer
2. Organisatiesjablonen: Vooraf gedefinieerde rol- en machtigingscombinaties via organisatiesjablonen, wat de organisatie-initialisatie vereenvoudigt

De toestemmingsrelatie ziet er als volgt uit:

Aangezien elke gebruiker hun eigen rol(len) nodig heeft binnen elke organisatie, moet de relatie tussen rollen en organisaties de rollen weerspiegelen die aan elke gebruiker zijn toegewezen:

We hebben het organisatiesysteem en toegangscontrolesysteem ontworpen, nu kunnen we beginnen met het bouwen van ons product!

Tech stack#

Ik heb gekozen voor een gebruiksvriendelijke, draagbare stack:

1. Frontend: React (gemakkelijk over te dragen naar Vue/Angular/Svelte)
2. Backend: Express (eenvoudige, intuïtieve API)

Waarom frontend en backend scheiden? Omdat het een duidelijke architectuur heeft, gemakkelijk te leren en eenvoudig te wisselen van stack. En als auth-provider gebruik ik Logto als voorbeeld.

En voor de volgende handleidingen, werken de hier gebruikte patronen met: Elke frontend, elke backend en elk auth-systeem.

Voeg basis authenticatiestroom toe aan je app#

Dit is de gemakkelijkste stap. We hoeven alleen maar Logto in ons project te integreren. Dan kunnen we gebruikersinlog/registratiemethoden configureren in de Logto Console op basis van onze behoeften.

Installeer Logto in je app#

Log eerst in op Logto Cloud. Je kunt je aanmelden voor een gratis account als je er nog geen hebt. Maak een Development Tenant voor testdoeleinden.

Klik in de Tenant Console op de knop "Aplicatie" aan de linkerkant. Selecteer dan React om onze applicatie te beginnen bouwen.

Volg de gids op de pagina. Je kunt de Logto-integratie in ongeveer 5 minuten voltooien!

Hier is mijn integratiecode:

Een handige truc: Onze inlogpagina heeft zowel Inloggen als Registreren knoppen. De Registreren knop leidt direct naar Logto's registratiepagina. Dit werkt via Logto's eerste scherm functie. Het bepaalt welke stap van de auth-stroom gebruikers als eerste zien.

Je kunt standaard naar de registratiepagina gaan wanneer je product veel nieuwe gebruikers verwacht.

Na het klikken op inloggen ga je naar de Logto inlogpagina. Bij succesvol inloggen (of registratie), gefeliciteerd! Je app heeft zijn eerste gebruiker (jij)!

En roep de signOut functie aan vanuit de useLogto hook om de gebruiker uit te loggen wanneer je dat wilt.

Pas inlog- en registratiemethoden aan#

In de Logto Console, klik je op "Sign-in Experience" in het linkermenu. Ga dan naar het tabblad "Sign-up and sign-in". Op deze pagina volg je de instructies om Logto's inlog-/registratiemethoden te configureren.

En de inlogstroom ziet er als volgt uit:

Schakel multi-factor authenticatie in#

Met Logto is het eenvoudig om MFA in te schakelen. Klik gewoon op de knop "Multi-factor auth" in de Logto Console. Schakel het dan in op de Multi-factor authenticatiepagina.

En de MFA-stroom ziet er als volgt uit:

Alles is zo eenvoudig! We hebben een complex gebruikersauthenticatiesysteem in slechts een paar minuten opgezet!

Het toevoegen van multi-tenant organisatie-ervaring#

Nu hebben we onze eerste gebruiker! Deze gebruiker behoort echter nog niet tot een organisatie, en we hebben nog geen organisaties aangemaakt.

Logto biedt ingebouwde ondersteuning voor multitenancy. Je kunt een onbeperkt aantal organisaties creëren in Logto. Elke organisatie kan meerdere leden hebben.

Elke gebruiker kan zijn organisatie-informatie ophalen van Logto. Dit maakt multi-tenancy ondersteuning mogelijk.

Verkrijg de organisatie-informatie van een gebruiker#

Om de organisatie-informatie van een gebruiker van Logto te krijgen, volg je deze twee stappen:

Verklaar toegang tot organisatie-informatie in de Logto Config. Dit doe je door de juiste scopes en resources in te stellen.

Gebruik Logto's fetchUserInfo methode om gebruikersinformatie op te halen, inclusief organisatiegegevens.

Na het voltooien van deze stappen moet je uitloggen en opnieuw inloggen. Dit is noodzakelijk omdat we het opgevraagde bereik en de opgevraagde resource hebben gewijzigd.

Op dit moment heb je nog geen organisaties aangemaakt. De gebruiker is ook nog niet lid geworden van een organisatie. Het dashboard zal "Je hebt nog geen organisatie" weergeven.

Vervolgens maken we een organisatie voor onze gebruikers en voegen ze eraan toe.

Dankzij Logto hoeven we geen complexe organisatorische relaties op te bouwen. We hoeven alleen maar een organisatie te maken in Logto en gebruikers eraan toe te voegen. Logto behandelt alle complexiteit voor ons. Er zijn twee manieren om Organisaties te maken:

1. Handmatig organisaties aanmaken via de Logto Console.
2. Gebruik de Logto Management API om organisaties aan te maken, vooral bij het ontwerpen van een SaaS-stroom waarmee gebruikers hun eigen organisaties (werkruimtes) kunnen maken.

Organisatie aanmaken in Logto Console#

Klik op de menuknop "Organisaties" aan de linkerkant van de Logto Console. Maak een organisatie.

Nu heb je je eerste organisatie.

Vervolgens voeg je de gebruiker toe aan deze organisatie.

Ga naar de organisatiedetailspagina. Schakel over naar het tabblad Leden. Klik op de knop "+ Lid toevoegen". Selecteer je inloggebruiker uit de linker lijst. Klik op de knop "Leden toevoegen" in de rechter benedenhoek. Nu heb je de gebruiker met succes toegevoegd aan deze organisatie.

Vernieuw je APP pagina. Je ziet dat de gebruiker nu tot een organisatie behoort!

Implementeer een selfservice organisatiecreatie ervaring#

Een organisatie aanmaken in de console is niet voldoende. Je SaaS-app heeft een stroom nodig die eindgebruikers in staat stelt eenvoudig hun eigen werkruimtes te creëren en te beheren. Gebruik voor het implementeren van deze functionaliteit de Logto Management API.

Raadpleeg de gids Interact with Management API om API-communicatie met Logto in te stellen.

Begrijp de organisatie auth interactiestroom#

Laten we de organisatiecreatiestroom als voorbeeld nemen. Hier is hoe het organisatiecreatieproces werkt:

Deze stroom heeft twee belangrijke authenticatievereisten:

1. Beveiliging achter service-API:
   • Toegang tot onze Achter Service API vanaf de voorkant vereist authenticatie.
   • API-eindpunten worden beveiligd door het geldig verklaren van de Logto toegangstoken van de gebruiker.
   • Dit zorgt ervoor dat alleen geauthenticeerde gebruikers toegang hebben tot onze services.
2. Toegang tot Logto Management API:
   • Achter Service moet veilig de Logto Management API aanroepen.
   • Volg de Interact with Management API handleiding voor installatie.
   • Gebruik Machine-to-Machine authenticatie om toegangsinformatie te verkrijgen.

Beveilig je backend API#

Laten we eerst een API-eindpunt maken in onze backend service voor het aanmaken van organisaties.

Onze backend service API staat alleen geauthenticeerde gebruikers toe. We moeten Logto gebruiken om onze API te beveiligen. We moeten ook de huidige gebruikersinformatie weten (zoals gebruikers-ID).

In Logto's concept (en OAuth 2.0) fungeert onze backend service als een resource-server. Gebruikers krijgen toegang tot de resource-server van DocuMind met een toegangstoken vanaf de voorkant. De resource-server verifieert dit token. Als het geldig is, retourneert het de gevraagde resources.

Laten we een API Resource maken om onze backend service weer te geven.

Ga naar de Logto Console.

1. Klik op de knop "API resources" aan de rechterkant.
2. Klik op "API-resource aanmaken". Selecteer Express in het pop-upvenster.
3. Vul "DocuMind API" in als de API naam. Gebruik "https://api.documind.com" als de API identifier.
4. Klik op aanmaken.

Maak je geen zorgen over deze API identifier URL. Het is gewoon een unieke identifier voor jouw API in Logto. Het is niet gerelateerd aan jouw feitelijke backend service URL.

Je ziet een tutorial voor het gebruik van de API-resource. Je kunt die handleiding volgen of onze onderstaande stappen.

Laten we een requireAuth middleware maken om ons POST /organizations eindpunt te beschermen.

Om deze middleware te gebruiken, hebben we deze omgevingsvariabelen nodig:

• LOGTO_JWKS_URL
• LOGTO_ISSUER

Verkrijg deze variabelen van de OpenID Configuratie eindpunt van jouw Logto tenant. Bezoek https://<your-tenant-id>.logto.app/oidc/.well-known/openid-configuration. Je vindt de benodigde informatie in de geretourneerde JSON:

Gebruik nu de requireAuth middleware in ons POST /organizations eindpunt.

Dit beschermt ons POST /organizations eindpunt. Alleen gebruikers met geldige Logto toegangstokens kunnen hier toegang toe krijgen.

We kunnen nu het token van Logto verkrijgen in onze frontend. Gebruikers kunnen organisaties creëren via onze backend-service met dit token. De middleware geeft ons ook de gebruikers-ID. Dit helpt bij het toevoegen van gebruikers aan organisaties.

In de frontendcode, declareer deze API-resource in de Logto-config. Voeg de identifier toe aan de resources-array.

Net als voorheen moeten gebruikers opnieuw inloggen nadat we de Logto-config hebben bijgewerkt.

In het Dashboard, verkrijg het Logto toegangstoken bij het creëren van een organisatie. Gebruik dit token voor toegang tot onze backend-service API.

Nu kunnen we correct toegang krijgen tot de DocuMind backend-service API.

Logto Management API aanroepen#

Laten we implementeren organisatiecreatie met behulp van de Logto Management API.

Net als front-end requests aan de backend-service, hebben backend-serviceverzoeken aan Logto toegangstokens nodig.

In Logto gebruiken we Machine-to-Machine authenticatie voor toegangstokens. Zie Interact with Management API.

Ga naar de applicatiespagina in de Logto Console. Maak een Machine-to-Machine applicatie. Ken de "Logto Management API toegang" rol toe. Kopieer de Token eindpunt, App ID en App Secret. We gebruiken deze voor toegangstokens.

Nu kunnen we Logto Management API toegangstokens verkrijgen via deze M2M applicatie.

Gebruik dit toegangstoken om Logto Management API aan te roepen.

We zullen deze Management API's gebruiken:

• POST /api/organizations: Organisatie aanmaken (zie: Create organization API reference)
• POST /api/organizations/{id}/users: Gebruikers toevoegen aan organisatie (zie: Add users to organization API reference)

We hebben nu organisatiecreatie geïmplementeerd via Logto Management API. We kunnen ook gebruikers aan organisaties toevoegen.

Laten we deze functie testen in het Dashboard.

En klik op "Create Organization"

Creatie succesvol!

De volgende stap zou zijn om gebruikers uit te nodigen voor een organisatie. We zullen deze functie nog niet in onze tutorial implementeren. Je weet al hoe je de Management API kunt gebruiken. Je kunt deze Tenantcreatie en uitnodiging als productontwerp referentie raadplegen en gemakkelijk deze functie implementeren door deze blogpost te volgen: How we implement user collaboration within a multi-tenant app.

Implementeren van toegangscontrole voor je multi-tenant app#

Nu gaan we verder met toegangscontrole voor organisaties.

We willen bereiken:

• Gebruikers kunnen alleen toegang krijgen tot resources die bij hun eigen organisaties horen: Dit kan worden gedaan via Logto's organization token
• Gebruikers hebben specifieke rollen binnen organisaties (met verschillende toestemmingen) om geautoriseerde acties uit te voeren: Dit kan worden geïmplementeerd via Logto's organisatiesjabloonfeature

Laten we eens kijken hoe we deze functies kunnen implementeren.

Logto organisatietoken gebruiken#

Vergelijkbaar met het Logto toegangstoken dat we eerder noemden, geeft Logto een toegangstoken uit dat overeenkomt met een specifieke resource, en gebruikers gebruiken dit token om beschermde resources in de backend-service te openen. In overeenstemming hiermee geeft Logto een organisatietoken uit dat overeenkomt met een specifieke organisatie, en gebruikers gebruiken dit token om beschermde organisatie resources in de backend-service te openen.

In de frontend applicatie kunnen we Logto's getOrganizationToken methode gebruiken om een token te verkrijgen voor toegang tot een specifieke organisatie.

Hier is organizationId de id van de organisatie waartoe de gebruiker behoort.

Voordat je getOrganization of een van de organisatiefeatures gebruikt, moeten we ervoor zorgen dat urn:logto:scope:organizations scope en urn:logto:resource:organization resource in de Logto-config zijn opgenomen. Aangezien we deze eerder al hebben gedeclareerd, zullen we dat niet herhalen.

In onze organisatiepagina gebruiken we het organisatietoken om documenten binnen de organisatie op te halen.

Er zijn twee belangrijke punten om op te letten in deze implementatie:

1. Als de organizationId die naar getOrganizationToken wordt doorgegeven geen organisatie-id is die tot de huidige gebruiker behoort, kan deze methode geen token krijgen, wat ervoor zorgt dat gebruikers alleen hun eigen organisaties kunnen openen.
2. Bij het opvragen van organisatie resources gebruiken we het organisatietoken in plaats van het toegangstoken omdat we voor resources die bij een organisatie horen, organisatie toestemming controle willen gebruiken in plaats van gebruikers toestemming controle (je begrijpt dit beter wanneer we de GET /documents API later implementeren).

Vervolgens creëren we een GET /documents API in onze backend-service. Vergelijkbaar met hoe we een API-resource gebruikten om de POST /organizations API te beschermen, gebruiken we organisatie specifieke resource-indicatoren om de GET /documents API te beschermen.

Laten we eerst een requireOrganizationAccess middleware maken om Organisatie resources te beschermen.

Gebruik vervolgens de requireOrganizationAccess middleware om de GET /documents API te beschermen.

Op deze manier hebben we organisatietokens gebruikt om toegang te krijgen tot organisatie resources. In de backend-service kun je corresponderende resources ophalen uit de database op basis van de organisatie-ID.

Sommige software vereist gegevensisolatie tussen organisaties. Voor verdere discussie en implementatie kun je de blogpost raadplegen: Multi-tenancy implementation with PostgreSQL: Learn through a simple real-world example.

Implementeer organisatie-niveau rol-gebaseerde toegangscontrole ontwerp#

We hebben organisatie tokens gebruikt om toegang te krijgen tot organisatie resources. Vervolgens zullen we gebruikers toestsingcontroles binnen organisaties implementeren met behulp van RBAC.

Laten we aannemen dat DocuMind twee rollen heeft: Beheerder en Medewerker.

Beheerders kunnen documenten aanmaken en openen, terwijl Medewerkers alleen documenten kunnen openen.

Daarom moet onze Organisatie deze twee rollen hebben: Beheerder en Medewerker.

Beheerder heeft zowel read:documents en create:documents toestemmingen, terwijl Medewerker alleen de read:documents toestemming heeft.

• Beheerder
  • read:documents
  • create:documents
• Medewerker
  • read:documents

Hier komt Logto's organisatiesjabloonfeature van pas.

Een organisatiesjabloon is een blauwdruk van het toegangscontrolemodel voor elke organisatie: het definieert de rollen en toestemmingen die gelden voor alle organisaties.

Waarom een organisatiesjabloon?

Omdat schaalbaarheid een van de belangrijkste vereisten voor SaaS-producten is. Met andere woorden, wat werkt voor één klant moet werken voor alle klanten.

Laten we naar Logto Console > Organisatie Sjablonen > Organisatie machtigingen gaan en twee machtigingen aanmaken: read:documents en create:documents.

Ga vervolgens naar het organisatie rollen tabblad om twee gebruikersrollen aan te maken: Beheerder en Medewerker, en wijs dienovereenkomstig toestemmingen toe aan deze rollen.

Op deze manier hebben we een RBAC machtigingsmodel voor elke organisatie gecreëerd.

Vervolgens gaan we naar onze Organisatiedetailpagina om de juiste rollen aan onze leden toe te wijzen.

Nu hebben onze organisatiegebruikers rollen! Je kunt deze stappen bereiken via Logto Management API:

Nu kunnen we gebruikerspermissiecontrole implementeren door hun toestemmingen te controleren.

In onze code moeten we ervoor zorgen dat het organisatietoken van de gebruiker toestemminformation bevat en vervolgens deze toestemming in de backend valideren.

In de frontendcode's Logto-config moeten we de toestemmingen verklaren die de gebruikers nodig hebben om binnen de organisatie op te vragen. Laten we read:documents en create:documents permissies toevoegen aan de scopes.

Zoals gebruikelijk, log opnieuw in met je gebruikersaccount om deze configuraties te laten werken.

Dan voegen we in de backend's requireOrganizationAccess middleware verificatie van de gebruikerspermissies toe.

Maak vervolgens een POST /documents API en gebruik de requireOrganizationAccess middleware met requiredScopes configuratie om deze API en de vorige GET /documents API te beschermen.

Op deze manier hebben we gebruikerspermissiecontrole geïmplementeerd door hun permissies te controleren.

In de frontend kun je gebruikers permissie informatie verkrijgen door het organisatietoken te decoderen of Logto's getOrganizationTokenClaims methode aan te roepen.

Beheer paginage elementen op basis van gebruikerspermissies door de scopes in de claims te controleren.

Voeg meer multi-tenant appfeatures toe#

Tot nu toe hebben we de basisfuncties voor gebruikers en organisaties in een multi-tenant SaaS-systeem geïmplementeerd! Er zijn echter nog steeds enkele functies die we niet hebben behandeld, zoals het aanpassen van de branding van de inlogpagina voor elke Organisatie, het automatisch toevoegen van gebruikers met specifieke domeinen aan bepaalde organisaties en het integreren van enterprise-niveau SSO-functionaliteit.

Dit zijn allemaal kant-en-klare functies en je kunt meer informatie over deze functies vinden in de Logto-documentatie.

Samenvatting#

Weet je nog hoe overweldigend het aan het begin was? Gebruikers, organisaties, permissies, enterprise functsies... het leek een eindeloze berg om te beklimmen.

Maar kijk eens wat we hebben bereikt:

• Een compleet authenticatiesysteem met meerdere inlogopties en MFA-ondersteuning
• Een flexibel organisatiesysteem dat meerdere lidmaatschappen ondersteunt
• Rol-gebaseerde toegangscontrole binnen organisaties

En het beste van alles? We hoefden het wiel niet opnieuw uit te vinden. Door gebruik te maken van moderne tools zoals Logto, hebben we wat maanden van ontwikkeling had kunnen zijn omgevormd tot een kwestie van uur.

De volledige broncode voor deze tutorial is beschikbaar op: Multi-tenant SaaS Voorbeeld.

Dit is de kracht van moderne ontwikkeling in 2025 - we kunnen ons concentreren op het bouwen van unieke productfuncties in plaats van te worstelen met infrastructuur. Nu is het jouw beurt om iets geweldig te bouwen!

Verken alle functies van Logto, vanaf Logto Cloud tot Logto OSS, op de Logto-website of meld je vandaag nog aan voor Logto cloud vandaag.