Moet je je eigen authenticatie bouwen voor apps?

Achtergrond#

Ik heb veel ontwikkelaars vragen zien stellen zoals "Moet ik mijn eigen authenticatie voor mijn app bouwen?". Hoewel het antwoord niet simpel "Ja" of "Nee" kan zijn, wil ik graag een artikel schrijven om de implementatie uit te leggen en de voor- en nadelen te demonstreren om je te helpen beslissen.

TL;DR Het is noodzakelijk om een bestaande oplossing te vinden die aan je behoeften voldoet, tenzij je echt volledige controle wilt of je nog steeds softwareontwikkeling aan het leren bent.

Intro#

Als ontwikkelaar heb ik veel applicaties gebouwd gedurende mijn carrière. Ongeacht de programmeertaal is er een gemeenschappelijke basis die ik altijd moet opbouwen: gebruikersauthenticatie.

Het was een verwaarloosbaar onderdeel, aangezien alles eenvoudig was 20 jaar geleden:

• Implementeer een registratie- en inlogsysteem met gebruikersnaam en wachtwoord.
• Creëer een mechanisme om de sessie van een gebruiker te onderhouden.
• Over beveiliging? MD5 is het antwoord.

Dat is het. Dan kon ik me richten op "de echte zaken". Nooit van MD5 gehoord? Dan heb je de "goede oude tijd" van softwareontwikkeling gemist. Tegenwoordig worden ontwikkelaars geconfronteerd met meer uitdagingen bij het bouwen van inlog-/registreersystemen.

Het klinkt alarmerend, maar laat me een voorbeeld geven.

Voorbeeld: Een online boekwinkel#

Stel dat je bezig bent een online boekwinkel te bouwen met een API-service en een web frontend-app.

Ten eerste moet de scope van "auth" worden gedefinieerd. Auth kan worden uitgelegd als authenticatie en autorisatie, en ze hebben totaal verschillende definities en toepassingen:

Ik schreef een artikel CIAM 101: Authenticatie, Identiteit, SSO om deze concepten in detail te bespreken.

Kies authenticatiemethoden#

Laten we beginnen met "authenticatie", wat in ons voorbeeld gebruikersinloggen is. Naast de methode met gebruikersnaam en wachtwoord, zijn er enkele trendy methoden die mensen adopteren voor een betere gebruikersconversie en beveiliging:

• Wachtwoordloos, d.w.z. dynamische verificatiecode (via e-mail of sms)
• Sociale inlog (Google, Facebook, enz.)

De keuze van de methode hangt af van de zakelijke beslissing, terwijl we naar de technische inspanning kunnen kijken:

• Voor wachtwoordloos moet je een leverancier vinden om verificatiecodes te verzenden via e-mail of sms; vervolgens integreren met je API-service (nieuwe API's kunnen nodig zijn).
• Voor sociale inlog moet je voldoen aan de integratierichtlijnen van de social identity provider(s) die je wilt gebruiken. Daarnaast moet je een koppeling maken tussen de gebruikers-ID's van je boekwinkel en die van de identity provider.
  • Bijvoorbeeld, wanneer een gebruiker inlogt met een Gmail-account [email protected], kun je dit e-mailadres koppelen aan de gebruiker foo in de boekwinkel. Dit proces helpt je om een uniform identiteitsysteem te bouwen en stelt de gebruiker in staat om zijn sociale identiteit in de toekomst te wijzigen of los te koppelen.

Ontwerp en implementeer inlogervaring#

Nadat je authenticatiemethoden hebt gekozen, is de volgende doel een gracieuze en soepele inlogervaring voor je eindgebruikers. De conversie hier is fundamenteel maar cruciaal voor het bedrijf, aangezien het een natuurlijke manier is om de verstrekte klantgegevens achter te laten.

Toen ik bij Airbnb werkte, was er een heel team gewijd aan het optimaliseren van de inlogervaring voor meerdere platforms. Ze voerden tal van A/B-tests uit om te bepalen welke combinatie de hoogste conversieratio had.

Het is niet praktisch om dat te doen wanneer een bedrijf net is gestart. Maar we moeten nog steeds ons best doen om elk stukje goed te maken. Op welke platforms wil je de boekwinkel runnen? Je kunt beginnen met mobiel, web of beide. Het exacte ontwerp hangt af van de gekozen authenticatiemethoden:

• Gebruikersnaam en wachtwoord: De eenvoudigste, slechts enkele invoervelden en knoppen.
• Wachtwoordloos: Voer telefoon/e-mail in, en verzend en verifieer vervolgens een dynamische code.
• Sociale inlog: Lees de documentatie van de gekozen social identity provider, volg de visuele richtlijn, handel de omleidingslogica af, en koppel uiteindelijk de sociale identiteit aan de boekwinkel identiteit.

Meer zaken om over na te denken om het beter te maken:

• Moet je de inlog- en registratieservice voor een specifieke methode combineren?
• Heb je een "wachtwoord vergeten"-proces nodig om klanten in staat te stellen hun wachtwoorden onafhankelijk te resetten?

Als je kiest voor native ontwikkeling, zal de werklast bijna verdubbelen voor één extra platform.

Beveiliging en tokenuitwisseling#

Beveiliging kan een verborgen ijsberg zijn. Het zou geweldig zijn als je bekend bent met OpenID Connect of OAuth 2.0, aangezien ze veel worden gebruikt en getest zijn in de praktijk. OpenID Connect is relatief nieuw maar is ontworpen voor "gebruikersauthenticatie", wat een geweldige pasvorm is voor een online boekwinkel.

Zonder in te gaan op de details van de standaarden, zijn er nog steeds enkele zaken om te overwegen:

• Welke versleutelmethode moet worden gebruikt voor wachtwoorden?
• Wat is het proces voor standaard authenticatie en autorisatie?
• Hoe werkt tokenuitwisseling (Access Token, Refresh Token, ID Token, enz.)?
• Hoe kunnen tekensleutels worden gebruikt in tokens en hoe kan de handtekening worden gevalideerd om resources te beschermen?
• Hoe kunnen aanvallen op client en server worden voorkomen?

Uiteindelijk kun je een goede inlogervaring realiseren en deze aan je klanten leveren.

Autorisatiemodel#

Als boekwinkel moet je resources scheiden voor klanten en verkopers. Klanten kunnen bijvoorbeeld alle boeken bekijken, terwijl verkopers hun te koop staande boeken kunnen beheren. Het is prima om te beginnen met eenvoudige if-else-controles; maar naarmate het bedrijfsleven groeit, moet je mogelijk een flexibeler model gebruiken, zoals Role-based Access Control (RBAC) of Attribute-based Access Control (ABAC).

Ik schreef ook een artikel CIAM 102: Autorisatie & Rolgebaseerde Toegangscontrole om basisautorisatieconcepten en het RBAC-model te demonstreren.

Neem de beslissing#

Je kunt zien dat authenticatie geen 'alles of niets'-probleem is, aangezien het meerdere technische componenten omvat en jij of je team verschillende technische expertise in deze gebieden kunnen hebben. Het is belangrijk om het op te splitsen in kleinere delen om een beter begrip van de huidige situatie te krijgen.

Om de beslissing te nemen, stel ik mezelf de volgende vragen:

• Hoe urgent is het project?
• Hoeveel moeite verwacht ik te besteden aan authenticatie versus het bedrijf?
• Wat is de prioriteit van gebruikerservaring, beveiliging en onderhoudbaarheid?
• Welk(e) deel(en) heb ik volledige controle over nodig? Hoe vertrouwd moet ik ermee raken?
• Als ik met sommige frameworks/oplossingen ga, zijn ze dan goed genoeg voor aanpassing of uitbreiding?
• Als het bedrijf groeit, moet ik dan een nieuw authenticatiemodel introduceren?
• Als ik een geschikte leverancier vind, is het dan veilig genoeg om te gebruiken? Heb ik een terugtrekkingsplan nodig als er iets met de leverancier gebeurt?

Met de vragen in gedachten ontdekte ik twee feiten:

• Het ontwerpen van een betrouwbaar authenticatiesysteem is zeer complex.
• Bestaande leveranciers kunnen niet aan alle noodzakelijke criteria voldoen.

Dus besloot ik een toegewijd project (Logto) voor authenticatie te starten en de open-source community vanaf dag één te omarmen.

Ik hoop dat dit artikel helpt.