Een dienst afnemen
Je koppelt een aanbieder die inloggen, wachtwoordherstel, tweefactor en sociale logins levert. Snel klaar en goed beveiligd. Je betaalt naar gebruikers en je gebruikersgegevens staan bij die partij.
Inloggen en accounts in je MVP
Bijna elk idee begint met de aanname dat gebruikers een account hebben. Inloggen oogt daarmee als een klein onderdeel, en het is een van de plekken waar zelf bouwen het vaakst duurder uitpakt dan verwacht. Niet vanwege het inlogscherm, maar vanwege alles eromheen.
01/06
Waarom inloggen groter is dan het lijkt
Het scherm is een uur werk. De rest is dat niet.
Een inlogformulier bouwen is eenvoudig. Wat erbij hoort is dat niet: registreren, e-mailadres bevestigen, wachtwoord vergeten, wachtwoord wijzigen, sessies die verlopen, uitloggen op alle apparaten, pogingen begrenzen na mislukte inlogs, en het veilig opslaan van wachtwoorden.
Daarna komt de tweede laag: tweefactorauthenticatie, inloggen met Google of Microsoft, uitnodigingen voor teamleden, rollen en rechten, en het overdragen van een account als iemand vertrekt. Elk onderdeel op zich is te doen. Samen zijn ze een project.
Het is bovendien de plek waar een fout het meest kost. Een bug in je rapportage is vervelend; een bug in je autorisatie betekent dat de ene klant de gegevens van de andere ziet. Dat is precies het soort fout dat je bij een gespecialiseerde partij inkoopt in plaats van zelf uitvindt.
02/06
Drie routes
Welke past, hangt af van je eisen en van waar je data mag staan.
Een platform met auth erin
Sommige backend-platforms leveren authenticatie als onderdeel van het geheel, naast database en opslag. Dat is efficiënt zolang je binnen dat platform blijft, en het bindt je er wel aan.
Zelf bouwen
Volledige controle en geen kosten per gebruiker. Je neemt dan ook het onderhoud, de beveiligingsupdates en de randgevallen over. Verstandig bij bijzondere eisen, zelden bij een eerste versie.
03/06
Vragen die de keuze bepalen
Loop deze vijf langs, dan valt de keuze meestal vanzelf.
- Wie logt er in? Consumenten willen inloggen met Google of Apple. Zakelijke gebruikers willen vaak aansluiten op hun eigen account bij Microsoft of Google. Dat laatste is een sterk argument voor een dienst die dat kant-en-klaar levert.
- Werken mensen in teams? Zodra meerdere mensen van dezelfde organisatie toegang hebben, komen uitnodigingen, rollen en beheerders erbij. Dat is het punt waarop zelf bouwen snel omvangrijk wordt.
- Waar mogen de gegevens staan? Sommige aanbieders slaan gebruikersgegevens buiten de EU op. Heb je daar eisen over, dan bepaalt dat de keuze eerder dan de prijs.
- Wat kost het bij groei? Diensten rekenen meestal per actieve gebruiker, met een gratis begin. Reken uit wat dat doet bij het aantal gebruikers dat je hoopt te halen, niet bij het aantal dat je nu hebt.
- Wat als je wilt wisselen? Vraag vooraf of je gebruikers en wachtwoorden kunt exporteren. Kan dat niet, dan zit je aan de aanbieder vast op het onderdeel dat het lastigst te verhuizen is.
04/06
In een prototype
De helft van de inlogfunctionaliteit is in een eerste versie nog niet nodig.
Wel meteen doen
- Een simpele koppeling met een bestaande dienst, zodat de basis meteen veilig is.
- Onderscheid tussen gebruikers, zodat je data per gebruiker gescheiden houdt.
- Uitloggen dat werkt en sessies die verlopen.
- Nadenken over wie welke gegevens mag zien, ook als er nog geen rollen zijn.
Kan later
- Tweefactorauthenticatie, tenzij je met gevoelige gegevens werkt.
- Teams, uitnodigingen en een rollenmodel met vijf niveaus.
- Inloggen met vijf verschillende sociale accounts.
- Een eigen wachtwoordherstelstroom met eigen e-mails.
05/06
Wat wij meestal doen op een bouwdag
Inloggen mag geen halve dag kosten, want het is zelden waar het idee op wordt beoordeeld.
In een bouwdag is inloggen bijna nooit het interessante deel. We koppelen daarom een bestaande dienst, zetten er één inlogmethode op en gaan door met wat je idee onderscheidend maakt. Blijkt de app door te gaan, dan is het uitbreiden naar teams, rollen en tweefactor een kwestie van configuratie in plaats van bouwen.
Soms slaan we inloggen zelfs helemaal over. Wil je testen of mensen je functie begrijpen, dan is een gedeelde link vaak genoeg. Een registratiestap toevoegen kost je testgebruikers, en op de dag zelf wil je juist zien of het idee werkt.
Wat we wel altijd meteen goed doen, is de scheiding tussen gebruikers. Data die per ongeluk bij de verkeerde persoon terechtkomt, is achteraf een verbouwing en soms een meldplicht.
06/06
Veelgestelde vragen
Is een kant-en-klare inlogdienst veilig genoeg?
Voor vrijwel alle toepassingen ja, en meestal veiliger dan wat je zelf bouwt. Deze partijen doen niets anders, krijgen beveiligingsonderzoek over zich heen en brengen updates uit bij nieuwe kwetsbaarheden. Zelf bouwen betekent dat je die verantwoordelijkheid overneemt.
Wat kost zoiets als mijn app groeit?
De meeste aanbieders rekenen per maandelijks actieve gebruiker, met een gratis laag gebruikersaantal aan het begin. Dat is prettig bij de start en het kan bij grote aantallen een serieuze post worden. Reken het door voor het aantal gebruikers dat je hoopt te halen, niet voor het aantal dat je nu hebt.
Kan ik later overstappen naar een eigen oplossing?
Dat kan, maar het is werk. Wachtwoorden zijn versleuteld opgeslagen en niet elke aanbieder geeft ze mee bij vertrek. Vraag daar vooraf naar. Lukt het niet, dan is de gebruikelijke route dat je bij de volgende inlog het wachtwoord opnieuw laat instellen.
Heb ik tweefactorauthenticatie nodig?
Werk je met gevoelige of zakelijke gegevens, dan wordt het al snel verwacht en soms geëist. Bij een consumentenapp met weinig gevoelige data kun je het rustig later aanzetten. Kies je voor een dienst, dan is het meestal een schakelaar in plaats van een bouwopdracht.
Kan ik mensen laten inloggen met hun werkaccount?
Ja, dat heet single sign-on en het is een van de sterkste redenen om een dienst te gebruiken. Zakelijke klanten vragen er vaak om, en het zelf implementeren van de bijbehorende protocollen is precies het soort werk dat je niet wilt doen naast het bouwen van je product.
Moet ik in een prototype al inloggen inbouwen?
Vaak niet. Als je wilt testen of mensen je idee snappen, is een gedeelde link genoeg en houd je de drempel laag. Inloggen wordt nodig zodra gebruikers hun eigen gegevens moeten terugvinden of zodra je wilt zien wie wat doet.
