Behöver du bygga din egen autentisering för appar?
Jag har sett många utvecklare ställa frågor som "Ska jag bygga min egen autentisering för min app?". Även om svaret inte kan vara ett enkelt "Ja" eller "Nej", vill jag skriva en artikel för att bryta ner implementeringen och demonstrera för- och nackdelar för att hjälpa dig att bestämma.
GaoFounder
Sluta slösa veckor på användarautentisering
Lansera säkra appar snabbare med Logto. Integrera användarautentisering på några minuter och fokusera på din kärnprodukt.
Jag har sett många utvecklare ställa frågor som "Ska jag bygga min egen autentisering för min app?". Även om svaret inte kan vara ett enkelt "Ja" eller "Nej", vill jag skriva en artikel för att bryta ner implementeringen och demonstrera för- och nackdelar för att hjälpa dig att bestämma.
Kort sammanfattning: Det är nödvändigt att hitta en befintlig lösning som passar dina behov, om du inte verkligen vill ha full kontroll eller fortfarande lär dig mjukvaruutveckling.
Som utvecklare har jag byggt många applikationer under min karriär. Oavsett programmeringsspråk finns det en gemensam grund som jag alltid behöver konstruera: användarautentisering.
Det var en försumbar del eftersom allt var enkelt för 20 år sedan:
Implementera ett registrerings- och inloggningssystem med användarnamn och lösenord.
Skapa en mekanism för att upprätthålla en användares session.
Om säkerhet? MD5 är svaret.
Det var allt. Då kunde jag fokusera på "den verkliga verksamheten". Har du inte hört talas om MD5? Du missade "de goda tiderna" för mjukvaruutveckling. Numera står utvecklare inför fler utmaningar när de bygger inloggning/registrering.
Det kan låta alarmerande, men låt mig gå igenom ett exempel.
Låt säga att du försöker bygga en onlinebokhandel med en API-tjänst och en webbaserad frontend-app.
Först bör omfattningen av "autentisering" definieras. Autentisering kan förklaras som autentisering och auktorisering, och de har helt olika definitioner och användningsområden:
Låt oss börja med "autentisering", vilket är användarinloggning i vårt exempel. Förutom metoden med användarnamn och lösenord, här är några trendiga metoder som folk använder för en bättre användarkonvertering och säkerhet:
Lösenordslöst, dvs dynamisk verifieringskod (via e-post eller sms)
Social inloggning (Google, Facebook, etc.)
Valet av metod beror på affärsbeslutet, medan vi kan titta på den tekniska insatsen:
För lösenordslöst behöver du hitta en leverantör för att skicka verifieringskoder via e-post eller sms; sedan integrera med din API-tjänst (nya API:er kan behövas).
För social inloggning måste du följa integrationsriktlinjerna för de sociala identitetsleverantörer du vill använda. Dessutom måste du skapa en mappning mellan ditt bokhandelns användar-ID och identitetsleverantörens.
- Till exempel, när en användare loggar in med ett Gmail-konto [email protected], kan du länka den här e-postadressen till användaren foo i bokhandeln. Denna process hjälper dig att bygga ett enhetligt identitetssystem och låter användaren ändra eller avlänka sin sociala identitet i framtiden.
Efter att du har bestämt autentiseringsmetoder är en graciös och smidig inloggningsupplevelse för dina slutanvändare nästa mål. Konverteringen här är grundläggande men avgörande för verksamheten eftersom det är ett naturligt sätt att lämna kvar bestående kunddata.
När jag arbetade för Airbnb fanns det ett helt team dedikerat till att optimera inloggningsupplevelsen för flera plattformar. De genomförde många A/B-tester för att avgöra vilken kombination som hade den högsta konverteringsgraden.
Det är inte praktiskt att göra detta när en verksamhet startar. Men vi måste ändå göra vårt bästa för att göra varje del rätt. Vilka plattformar skulle du vilja driva bokhandeln på? Du kan börja med mobil, webben eller båda. Den exakta utformningen beror på de valda autentiseringsmetoderna:
Användarnamn och lösenord: Den enklaste, bara några inmatningsrutor och knappar.
Lösenordslöst: Ange telefon/e-post, skicka och verifiera en dynamisk kod.
Social inloggning: Läs dokumentationen från den valda sociala identitetsleverantören, följ den visuella riktlinjen, hantera omdirigeringslogiken och länka slutligen den sociala identiteten med bokhandelns identitet.
Fler saker att överväga för att göra det bättre:
Behöver du kombinera inloggnings- och registreringsprocessen för en specifik metod?
Behöver du ett "glömt lösenord"-flöde för att låta kunder återställa sina lösenord självständigt?
Om du väljer inhemsk utveckling fördubblas nästan arbetsbelastningen för en ytterligare plattform.
Säkerhet kan vara ett dolt isberg. Det är bra om du är bekant med OpenID Connect eller OAuth 2.0, eftersom de är allmänt använda och stridstestade. OpenID Connect är relativt nytt men är utformat för "användarautentisering", vilket är en bra matchning för en onlinebokhandel.
Utan att fördjupa sig i standardernas detaljer finns det ändå några saker att överväga:
Vilken krypteringsmetod ska användas för lösenord?
Vad är processen för standardautentisering och auktorisering?
Hur fungerar tokenutbyte (Access Token, Refresh Token, ID Token, etc.)?
Hur kan signeringsnycklar användas i tokens och hur kan signaturen valideras för att skydda resurser?
Hur kan klient- och serverattacker förhindras?
Slutligen kan du landa en bra inloggningsupplevelse och leverera den till dina kunder.
Som bokhandel behöver du separera resurser för kunder och säljare. Till exempel kan kunder bläddra i alla böcker, medan säljare kan hantera sina försäljningsobjekt. Det är okej att börja med enkla if-else-kontroller; men när verksamheten växer kan du behöva utnyttja en mer flexibel modell såsom Rollbaserad åtkomstkontroll (RBAC) eller Attributbaserad åtkomstkontroll (ABAC).
Du kan se att autentisering inte är ett "allt eller inget"-problem, eftersom det involverar flera tekniska komponenter och du eller ditt team kan ha olika teknisk expertis inom dessa områden. Det är viktigt att bryta ner det i mindre delar för att få en bättre förståelse av nuläget.
För att fatta beslutet ställer jag mig själv följande frågor:
Hur brådskande är projektet?
Hur mycket insats förväntar jag mig att lägga på autentisering kontra verksamheten?
Vad är prioriteten för användarupplevelse, säkerhet och underhållsmöjlighet?
Vilka delar behöver jag full kontroll över? Hur bekant bör jag bli med dem?
Om jag använder vissa ramverk/lösningar, är de tillräckligt bra för anpassning eller utökning?
Om verksamheten växer, behöver jag då införa en ny autentiseringsmodell?
Om jag hittar en lämplig leverantör, är det tillräckligt säkert att använda? Behöver jag en reträttpolicy om något händer med leverantören?
Med dessa frågor i åtanke upptäckte jag två fakta:
Att skapa ett tillförlitligt autentiseringssystem är mycket komplext.
Befintliga leverantörer kan inte uppfylla alla nödvändiga kriterier.
Så jag bestämde mig för att starta ett dedikerat projekt (Logto) för autentisering och omfamna open source-communityn från dag ett.
