Met de toenemende volwassenheid van low-code tools en clouddiensten vandaag de dag, vergezeld door de versnelling van AI-toolgebruik, wordt de drempel voor het ontwikkelen van apps aanzienlijk verlaagd, en verschijnen er steeds meer apps op de markt. Of het nu complexe of eenvoudige apps zijn, de meeste apps omvatten scenario's van gebruikersregistratie en -inloggen, zodat gebruikers stabielere, veiligere en gepersonaliseerde diensten kunnen krijgen. En om het probleem van gebruikersinloggen en -registratie op te lossen, is de eerste stap het bouwen van een identiteitssysteem. Voor veel apps die op consumenten zijn gericht, zijn hun identiteitsmodellen vaak relatief eenvoudig, of vereisen ze zelfs alleen e-mail en wachtwoord. Voor apps die zich in een fase van snelle groei bevinden en nieuwe gebruikers aantrekken, is dit voldoende; maar zodra de app een eigen businessmodel heeft, in het eenvoudigste geval, bijvoorbeeld voor het leveren van advertenties, moet er een onderscheid worden gemaakt tussen gewone gebruikersaccounts en adverteerdersaccounts. Adverteerdersaccounts kunnen aangepaste advertentie-indelingsschalen en -inhoud configureeren; terwijl gewone gebruikers slechts enkele gratis inhoud en advertenties kunnen bekijken, enzovoort. Logto is een cloudgebaseerde identiteitsoplossing, en er is ook een open-source software (OSS) oplossing met dezelfde kern als clouddiensten voor gebruikers met speciale behoeften om aanpassingen uit te voeren. De service van Logto is gebouwd op een multi-tenant systeem, waarbij elke Logto-gebruiker zijn eigen account aanmaakt en meerdere tenants binnen het account kan beheren. Andere verschillende identiteitsclouddiensten hebben ook vergelijkbare architecturen, waarbij elke verschillende clouddienst zijn eigen definitie van "tenant" heeft, dus het tenantmodel dat we in dit artikel bespreken is beperkt tot het scenario van Logto, en voor andere leveranciers kunnen er andere corresponderende concepten zijn. Opmerkelijk is dat in het multi-tenant model van Logto, **_gegevens tussen tenants (alle informatie van eindgebruikers) geïsoleerd zijn_**, zodat Logto-gebruikers eindgebruikersaccountgegevens kunnen beheren volgens hun zakelijke behoeften binnen een Logto-account. Veel andere identiteitsclouddiensten kunnen slechts ondersteuning bieden voor elk account met één tenant, wat ertoe leidt dat gebruikers die meerdere tenants tegelijkertijd moeten beheren vaak van account moeten wisselen, wat resulteert in een slechte ervaring. Algemeen identiteitsmodel

Na al dat, hoe moet je een accountmodel kiezen dat geschikt is voor je app? Hier bekijken we drie gevallen. ## Case 1: App biedt direct service aan eindgebruikers Het identiteitsmodel in dit soort apps is vrij eenvoudig. Laten we een muziekstreaming-app als voorbeeld nemen — afgezien van de beheerder (Logto's gebruiker "foo", die in dit geval de tenant-eigenaar is, heb namelijk beheertoegang), zijn er alleen eindgebruikers. In dit scenario kunnen eindgebruikers worden onderverdeeld in drie typen: 1. Gratis plan gebruiker: Kan alleen gratis muziek afspelen 2. Betaald plan gebruiker: Kan gratis muziek afspelen en hun eigen afspeellijsten maken 3. Premium gebruiker: Naast het afspelen van gratis muziek en het maken van afspeellijsten, kan ook HiFi-muziek worden afgespeeld In bovenstaand toepassingsscenario hebben we slechts drie soorten rollen nodig (gratis, betaald, premium), elk toegewezen met verschillende permissies. Dus nadat de eindgebruiker is ingelogd, kan Logto beslissen of bepaalde specifieke diensten (bijv. toegang tot HiFi muziek) aan hem worden aangeboden op basis van de rol die hij heeft. Op dit punt hebben we slechts een enkele tenant nodig om aan de vereisten te voldoen. Muziek app identiteitsmodel

## Case 2: eCommerce platform app Een platform dat derdepartijdienstverleners en eindgebruikers verbindt, wat tegenwoordig ook een zeer gebruikelijk 2C-businessmodel is. Er zijn twee gebruikersgroepen om te overwegen - gebruikmakend van een e-commerce app als voorbeeld, zijn zij handelaren (dienstverleners) en kopers (eindgebruikers). Er zijn twee manieren om het identiteitsmodel hier te bouwen: 1. Zet de kopers- en handelarengebruikersgroepen onder dezelfde tenant. eCommerce app single tenant identiteitsmodel

eCommerce app single tenant identiteitsmodel

2. Zet de kopers en handelaren respectievelijk in twee verschillende tenants. eCommerce app multi tenant identiteitsmodel

Om het voorbeeld makkelijker te begrijpen, nemen we aan dat kopers bestellingen kunnen plaatsen of productbeschrijvingen kunnen bekijken; handelaren kunnen productprijzen wijzigen, productbeschrijvingen wijzigen en productvoorraad bekijken. Handelaren bekijken productbeschrijvingen om hen te helpen problemen te vinden en productinformatie tijdig bij te werken. Voor identiteitsmodel 1 is er slechts één app. Alle gebruikers die zich registreren worden kopers. Als iemand dingen wil verkopen, kan hij zijn eigen producten toevoegen om te verkopen, dus dergelijke eindgebruikers verkrijgen verkopersrechten naast kopersrechten om hun eigen producten te beheren. Voor identiteitsmodel 2, aangezien elke tenant zijn eigen unieke identiteitsinformatie heeft en zijn eigen afzonderlijke autorisatiegateway, moet elke tenant zijn eigen aparte app hebben. In het voorbeeldgeval zou er een kopers-app en een verkopers-app zijn. Kopersaccounts kunnen geen verkopers worden, en verkopersaccounts kunnen ook geen kopers worden. Als verkopers hun eigen productbeschrijvingen willen controleren vanuit het perspectief van een koper zoals in model 1, moeten ze dezelfde functionaliteit opnieuw implementeren in de verkopers-app, of een account van de kopers-app registreren om het te bekijken. Dit voegt veel complexiteit toe, maar het voordeel is dat koper- en verkopersidentiteiten volledig geïsoleerd zijn. Als verkopers veel verschillende producten te beheren hebben, zou het beter zijn om identiteitsmodel 2 te gebruiken en een meer gespecialiseerde verkopers-app te ontwikkelen. Model 1 is geschikter voor platforms zoals eBay, waar verkopers niet veel producten hebben en ook niet te complexe productbeheerfunctionaliteit nodig hebben. ## Case 3: Apps gemaakt door IT-consultancybedrijf Stel er is een IT technisch consultancybedrijf wiens klanten zelf niet in staat zijn om IT-systemen te ontwikkelen, dus moeten ze technische diensten aanvragen bij dit bedrijf. Aangenomen dat het bedrijf twee klanten heeft, waarbij een een intern boekbeheersysteem voor een boekwinkel is, en de andere klant een reserveringssysteem voor een hotel is. Vanuit het perspectief van de boekwinkelhouder wil ik natuurlijk niet dat hotelgasten zich zomaar kunnen inloggen in mijn boekbeheersysteem, aangezien dat zeer onveilig zou zijn. Daarom, vanuit het oogpunt van bescherming van de privacy, moet er een aparte tenant worden ingesteld voor elke klant, gebruikmakend van het isolatiemechanisme van tenantinformatie, om ervoor te zorgen dat gegevens van klanten onzichtbaar zijn voor andere klanten. Identiteitsmodel voor IT-consultancybedrijf

Identiteitsmodel voor IT-consultancybedrijf

Zoals we eerder hebben vermeld, zelfs als je de behoefte hebt om meerdere tenants te creëren, Logto kan je helpen meerdere tenants binnen één account te beheren, wat handiger en veiliger is in vergelijking met sommige andere diensten waar je zelf meerdere accounts moet creëren en beheren. Door de voorbeelden die we hierboven hebben laten zien, moet je hebben begrepen wanneer je zeker meerdere tenants moet creëren, in welke scenario's je een enkele tenant of meerdere tenants kunt hebben, en volgens je eigen zakelijke behoeften, kies je de identiteitsmodeloplossing die het beste bij je past. Het Logto-team streeft ernaar om ervoor te zorgen dat de vraag "of er meerdere tenants moeten worden gecreëerd" geen blokkade vormt voor elk bedrijf. Als je niet zeker weet of je zakelijke scenario kan worden bereikt met een enkele tenant, neem dan [deel aan de Logto community](https://discord.gg/UEPaF3j5e6) voor overleg. Jouw vraag kan ook de vraag van iemand anders zijn, dus deel de uitdagingen waarmee je te maken hebt gehad met ons om de schaalbaarheid van Logto's producten te verbeteren. Als je een identiteitsframework voor je app aan het selecteren bent, is Logto het proberen waard. Het biedt een kant-en-klare oplossing die geschikt is voor verschillende zakelijke scenario's, van kleine bedrijven tot grootschalige toepassingen! Probeer Logto Vandaag