Behöver du verkligen flera hyresgäster för att hantera ditt identitetssystem?
Begreppet 'hyresgäst' är relativt obekant för de flesta användare, men det är särskilt viktigt för att bygga identitetsmodeller. I den här artikeln kommer vi att gå igenom exempel för att hjälpa alla att förstå vilken typ av identitetsmodell som passar deras verksamhet.
Developer
Med den ökande mognaden av låga kodverktyg och molntjänster idag, åtföljt av accelerationen av AI-verktyg, sänks tröskeln för att utveckla appar kraftigt, och fler och fler appar dyker upp på marknaden.
Oavsett om det är komplexa eller enkla appar, de flesta appar involverar användarregistrering och inloggningsscenarier, så att användare kan få mer stabila, säkra och anpassade tjänster. Och för att lösa problemet med användarinloggning och registrering är det första steget att bygga ett identitetssystem.
För många konsumentinriktade appar är deras identitetsmodeller ofta relativt enkla, eller kräver till och med bara e-post och lösenord. För appar som är i ett stadium av snabb tillväxt och attrahera nya användare är detta tillräckligt; men när appen har sin egen affärsmodell, i det enklaste fallet, till exempel att servera annonser, behöver det finnas en åtskillnad mellan vanliga användarkonton och annonsörskonton. Annonsörskonton kan anpassa annonseringsskalor, innehåll, etc; medan vanliga användare bara kan bläddra i vissa gratisinnehåll och annonser, etc.
Logto är en molnbaserad identitetslösning, och det finns också en öppen källkodslösning (OSS) med samma kärna som molntjänster för användare med speciella behov för att utföra anpassning. Logtos tjänst är byggd på ett multi-hyresgästs system, där varje Logto-användare skapar sitt eget konto och kan hantera flera hyresgäster inom kontot. Andra olika identitetsmolntjänster har också liknande arkitekturer, där varje olika molntjänst har sin egen definition av "hyresgäst", så hyresgästsmodellen vi diskuterar i den här artikeln är begränsad till Logtos scenario, och för andra leverantörer kan det finnas andra motsvarande koncept.
Noterbart är att i Logtos multi-hyresgästmodell, är data mellan hyresgäster (all information om slutkunder) isolerad, så Logto-användare kan hantera slutkundskontodata enligt sina affärsbehov inom ett Logto-konto. Många andra identitetsmolntjänster kan bara stödja varje konto med en hyresgäst, vilket gör att användare som behöver hantera flera hyresgäster samtidigt ofta måste byta konto, vilket resulterar i en dålig upplevelse.
Med allt det sagt, hur ska du välja en kontomodell som är lämplig för din app? Här tittar vi på tre fall.
Fall 1: App tillhandahåller direkt tjänst till slutkunder
Identitetsmodellen i den här typen av appar är ganska enkel. Låt oss använda en musikstreamingapp som exempel — förutom administratören (Logtos användare "foo", som är hyresgästägaren i det här fallet, har naturligtvis administratörsbehörighet), finns det bara slutkunder.
I detta scenario kan slutkunder delas in i tre typer:
- Gratisanvändare: Kan bara spela gratis musik
- Betalplananvändare: Kan spela gratis musik och skapa sina egna spellistor
- Premiumanvändare: Utöver att spela gratis musik och skapa spellistor, kan även spela HiFi-musik
I det ovanstående applikationsscenariot behöver vi bara tre typer av roller (gratis, betald, premium), var och en tilldelad med olika behörigheter. Så efter att slutkunden loggar in kan Logto bestämma om vissa specifika tjänster (t.ex. tillgång till HiFi-musik) ska tillhandahållas honom baserat på rollen han har. Vid denna punkt behöver vi bara en enda hyresgäst för att uppfylla kraven.
Fall 2: eHandelsplattformens app
En plattform som kopplar samman tredjeparts serviceleverantörer och slutkunder, vilket också är en mycket vanlig 2C-affärsmodell nuförtiden. Det finns två användargrupper att överväga - med en e-handelsapp som exempel, är de handlare (serviceleverantörer) och köpare (slutkunder).
Det finns två sätt att bygga identitetsmodellen här:
- Sätt köparna och handlarna i samma hyresgäst.
- Sätt köparna och handlarna i två olika hyresgäster respektive.
För att göra exemplet lättare att förstå, antar vi att köpare kan lägga beställningar eller visa produktbeskrivningar; handlare kan ändra produktpriser, ändra produktbeskrivningar och visa produktlager. Handlare visar produktbeskrivningar för att hjälpa dem upptäcka problem och uppdatera produktinformation i tid.
För identitetsmodell 1 finns det bara en app. Alla användare som registrerar sig blir köpare. Om någon behöver sälja saker kan de lägga till sina egna produkter till salu, så sådana slutkunder kommer att få köparbehörigheter utöver köparbehörigheter för att hantera sina egna produkter.
För identitetsmodell 2, eftersom varje hyresgäst har sin egen unika identitetsinformation och sitt eget separata auktoriserings gateway, behöver varje hyresgäst ha sin egen separata app. I exemplet skulle det finnas en köpareapp och en handlarapp. Köparkonton kan inte bli handlare, och handlarakonton kan inte heller bli köpare. Om handlare vill kontrollera sina egna produktbeskrivningar från en köpares perspektiv som i modell 1, behöver de återimplementera samma funktionalitet i handlarappen, eller registrera ett köparkontot för att visa det. Detta tillför mycket komplexitet, men fördelen är att köpar- och handlaridentiteter är fullständigt isolerade.
Om handlarna har många olika produkter att hantera, bör det vara ett bättre val att använda identitetsmodell 2 och utveckla en mer specialiserad handlarapp. Modell 1 är mer lämplig för plattformar som eBay, där handlarna inte har många produkter och inte heller behöver alltför komplex produktförvaltning.
Fall 3: Appar gjorda av IT-konsultföretag
Anta att det finns ett IT-teknikkonsultföretag vars kunder inte har förmågan att utveckla IT-system själva, så de behöver söka tekniska tjänster från detta företag.
Om vi antar att företaget har två kunder, en som är ett internt bokhanteringssystem för en bokhandel, och den andra kunden är ett bokningssystem för ett hotell.
Ur bokhandelns ägares perspektiv vill jag uppenbarligen inte att hotellgäster ska kunna logga in slumpmässigt på mitt bokhanteringssystem, eftersom det skulle vara mycket osäkert. Därför, ur integritetsskyddets aspekt, måste en separat hyresgäst upprättas för varje kund, vilket utnyttjar hyresgästen informationsisoleringsmekanism, för att säkerställa att kundernas data är osynliga för andra kunder.
Som vi nämnt tidigare, även om du har behov av att skapa flera hyresgäster, kan Logto hjälpa dig att hantera flera hyresgäster inom ett konto, vilket är mer bekvämt och säkert jämfört med vissa andra tjänster som kräver att du själv skapar och hanterar flera konton.
Genom de exempel som visas ovan måste du ha räknat ut när du definitivt behöver skapa flera hyresgäster, i vilka scenarier du kan ha antingen en enkel hyresgäst eller flera hyresgäster, och enligt dina egna affärsbehov, välj den identitetsmodellslösning som passar dig bäst.
Logto-teamet strävar efter att säkerställa att frågan om "om flera hyresgäster bör skapas" inte är ett hinder för någon verksamhet. Om du är osäker på om ditt affärsscenario kan uppnås med en enda hyresgäst, vänligen gå med i Logto-gemenskapen för konsultation. Din fråga kan också vara någon annans fråga, så dela de utmaningar du har stött på med oss för att hjälpa till att förbättra skalbarheten hos Logtos produkter.
Om du väljer en identitetsram för din app är Logto värt att prova. Det erbjuder en färdig lösning lämplig för olika affärsscenarier från småföretag till storskaliga applikationer!