Innlogging er noe alle utviklere treffer på før eller senere.
Problemstillinger som lagring og kryptering av passord, utsending av e-poster, cookies, JWT-tokens og hvilke sosiale innlogger vi skal støtte kan fort bli overveldende.
At det i tillegg drøssevis av tjenester og programvarer der ute som tar sikte på å løse disse problemene, gjør det ikke enklere. Derfor lurte vi på: hva foretrekker norske utviklere?
I den pågående serien om utvikling av vår fiktive brusapp foreslo vi derfor dette scenarioet for brukerne i kode24-klubben:
Sjefen ringer på Skype: "Hvorfor får ingen logget inn i brus-appen vår? Porsgrunns forente brusvenner raser på Facebook!!"
"Det er nok fordi vi ikke har bygget autentisering ennå.", svarer du rolig.
"Hva? Dette er skandale!! Autentisering er herved hevet til høyeste nivå i Jira!! Nå skal vi være lean!!", kimer det tilbake.
Du må altså bygge autentisering for brus-webappen. Hva velger du?
Du kan høre hva utviklerne svarte i kode24-timens innboks-spalte her:
Og lese en oppsummering av svarene deres her:
#1. Firebase
Den soleklart mest foreslåtte autentiseringsmekanismen i klubben er Firebase. Eller Firebase Authentication, som er det fulle navnet på skytjenesten fra Google.
Firebase Authentication lanserte i 2014 og tilbyr seg blant annet å autentisere brukere kun med kode på klienten, støtter tredjeparter som Facebook, Github, Twitter og Google - i tillegg til e-post og passord, og kommer med et ferdig system for å administrere brukere.
Det er ikke rart at JavaScript-utviklere i dagens kodeverden har forelsket seg i Firebase.
- Firebase Auth fungerer strålende til dette 👌, skriver Remi Sture.
- Firebase er enkelt og greit, skriver Anders Sveen.
- Jeg har god erfaring med tjenesten for autentisering fra Firebase, skriver Magnus Kjelland.
- Firebase, "done & done" på 5 min, skriver Christian Wick.
NRK: - Ikke Firebase sin skyld
#2. Auth0
Auth0 er en konkurrent til Firebase, og er kjent for sin ekstremt gode dokumentasjon, noe medlemmer i klubben også nevner.
- Auth0 med det frontend-rammeverket som er valgt for appen, skriver Knut Melvær.
- Har selv nettopp sittet litt med Auth0 i forbindelse med et lite hobbyprosjekt jeg driver med og tjenesten og dokumentasjonen er bunnsolid. Hjelper på at de har gratisabonnement slik at man får prøvd ut funksjonalitet før man kjøper seg inn, skriver Snorre Magnus Davøen som svar på Knut Melvær sitt innlegg.
- Auth0 er gull. Og det er ikke bare fordi Auth0-t-skjorta jeg fikk på ndc for mange år siden er en av de beste merch t-skjortene jeg har fått, skriver Vegar Viken.
#3. KeyCloak
Flere klubbmedlemmer nevner KeyCloak, et autentiserings-system som ligger under Red Hat og lanserte i 2014. I motsetning til Firebase og Auth0 er KeyCloak en softwarepakke man laster ned og kjører selv.
Softwaren er helt gratis, og er utviklet i Java. Med i pakka får man både et administrasjons-GUI og støtte for en haug med autentiseringsmetoder.
- KeyCloak, da slipper jeg å skrive det selv og så får jeg brukeradmin på kjøpet. Som koster kroner null. Eneste problemet er at det suger endel ressurser på serversiden på grunn av Java VM. Fungerer fint på blant annet Kubernetes og kan kombineres med for eksempel OpenID Connect/OAuth og SAML. Biblioteker for nodejs, python, c#, Java med fler, forteller Dag Håkon Bårdsen.
- Har blitt glad i KeyCloak selv, man får mye ut av boksen og samtidig store muligheter for å fylle på med egenprodusert kode der man har mer eller mindre sære behov, forteller Torbjørn Skyberg Knutsen.
- Vi har valgt å gå for Keycloak ("Open Source Identity and Access Management") for brukerhåndtering og autentisering. Veldig godt fornøyd så langt og støtter blant annet synk mot AD, OpenID Connect, OAuth og SAML, samt har ferdige adaptere for integrasjon mot Google, Facebook, Twitter, etc. I tillegg støtter Keycloak en utrolig fleksibel gruppering av brukerer, som gjør at man kan få rollebasert tilgangskontroll (RBAC).Vi bruker Keycloak for autentisering, men for å håndheve tilgangsrettigheter (autorisasjon) har vi valgt å gå for Open Policy Agent (OPA). OPA er også åpen kildekode og passer veldig godt for en mikrotjeneste-arkitektur hvor vi kan desentralisere autorisasjonssjekkene og flytte disse nærmere tjenestene som skal bruke dem, forteller Kjetil Klaussen, i en alt for lang kommentar.
#4. IdentityServer
Identityserver er en autentiseringsløsning myntet på selskaper som bruker .NET. Den nyeste versjonen av softwaren heter IdentityServer4, og skal være et OpenID Connect- og Oauth 2.0-rammeverk for ASP.NET Core.
Flere utviklere i klubben ser ut til å bruke rammeverket.
- IdentityServer4 og en eller annen SQL-basert lagring av brukerdata, skriver Christian Lundheim.
- Eventuelt en Graph/JSON-database som CosmosDb, skriver Mats Magnem som svar på innlegget til Lundheim.
Slik koda NAV ny dagpenge-løsning på tre dager
#5. BankID og Buypass
I klubben er det også utviklere som trenger litt ekstra sikkerhet. Da er det ikke uvanlig å gå for norske tjenester som BankID og Buypass. Begge tjenestene tilbyr tilgang til offentlige tjenester på høyeste sikkerhetsnivå.
Der BankID utstedes av banken din, utstedes Buypass av Buypass AS selv, og har andre bruksområder enn BankID.
- IdentityServer sammen med BankId og tredjeparter via OpenID Connect, skriver Glenn F. Henriksen.
- Det høres dyrt ut, svarer Rolf Bjaanes.
- BankID er relativt dyrt ja, men sikker identifisering har andre fordeler, skriver Henriksen tilbake.
- Hmm... Tofaktorautentisering fra BuyPass, må jo sikre brusen, kimer det fra Kai H T Mortensen-Langhaug.
#6. Andre forslag
Selv om vi kanskje har tatt for oss de vanligste løsningene over, finnes det klubbmedlemmer som sier de ville valgt andre løsninger.
- Jeg skriver stort sett dette i Golang fra bunnen av. Da bruker jeg JWT med en access token og en refresh token hvor begge har sine unike IDer i payloaden som sjekkes opp mot en Redis cache for å se om de er revoked eller gyldig. Passord er selvfølgelig krypter ved hjelp av Argon2id. All brukerdata lagres i eksisterende database; stort sett PostgreSQL når jeg får velge selv. Har brukt dette i større produksjonsapper og i mine personlige apper, skriver Tony André Haugen.
- HTTP Basic Auth, skriver Alexander Karlstad, og blir møtt med enkelte flir fra andre klubbmedlemmer.
- Siden jeg har anbefalt MongoDB som database, MongoDB Realm som serverless backend, så er det naturlig å anbefale MongoDB Realm for autentisering også. Enkelt å sette opp autorisasjon og med f.eks. ACL i hvert dokument om en vil.Nå sitter jeg akkurat å plages litt med å kombinere MongoDB Realm autentisering med egen backend. Ender antakelig opp å sette opp custom jwt providere i Realm og bruke Auth0 i stede. Kanskje, skriver Vegan Vikan.
