Slik legger du til innlogging i appen din: passord, magiske lenker, Google og roller

For å legge til innlogging i en app velger du en metode (e-post og passord, magiske lenker, en engangslenke sendt på e-post, eller «Logg inn med Google») og implementerer den med et velprøvd autentiseringsbibliotek eller en hostet leverandør, ikke fra bunnen av. Deretter bestemmer du hva hver type bruker får lov til å gjøre (roller), og håndhever det på serveren for hver side og API-forespørsel. Økter bør bruke sikre kapsler, utløpe, og avsluttes ordentlig ved utlogging.

Denne guiden går gjennom hvert valg og detaljene som skiller en fungerende innlogging fra en trygg en. For begrepene bak, se hva er autentisering.

Bestem først: trenger du innlogging i det hele tatt?

Innlogging gir friksjon og ansvar. Du trenger den når:

• Brukere har private data (bestillinger, dokumenter, fakturaer)
• Brukere kan endre ting andre vil se
• Du tar betalt for tilgang
• Ulike personer trenger ulike tillatelser (eier, ansatt og kunde)

Du trenger ikke nødvendigvis innlogging for en markedsføringsside, en offentlig katalog eller et skjema som bare sender deg en e-post. En venteliste trenger ikke kontoer; et e-postfelt er nok.

De fire vanlige innloggingsmetodene

Mange apper kombinerer to. Logg inn med Google pluss magiske e-postlenker er en populær kombinasjon som dekker de fleste uten å lagre passord.

E-post og passord

Hvis du tilbyr passord, er dette ufravikelig:

• Hash passord med en treg passord-hashing-algoritme. OWASPs veiledning for passordlagring anbefaler Argon2id, med scrypt, bcrypt eller PBKDF2 som alternativer. Lagre aldri passord i klartekst eller med en rask generell hash.
• Passordtilbakestillinger bruker en tilfeldig, engangslenke som utløper, sendt til den bekreftede e-posten.
• Ikke avslør hvilke e-poster som har kontoer. «Hvis den e-posten er registrert, har vi sendt en tilbakestillingslenke» er bedre enn «Fant ingen konto».
• Begrens forsøk på innlogging og tilbakestilling for å bremse gjetting av passord.
• Tillat lange passord og passordbehandlere, og hopp over regler som tvinger på rare tegnkombinasjoner.

Magiske lenker og engangskoder

En magisk lenke er en innloggingslenke sendt til brukeren på e-post. Å klikke på den logger dem inn. En engangskode er den samme ideen, men skrevet inn i stedet for klikket.

• Lenker og koder utløper raskt og virker bare én gang.
• Lenken bør logge brukeren inn på enheten de klikket på, og tokenet må ikke ligge i logger eller analyseverktøy.
• Du trenger pålitelig e-postsending. Se hvordan sende e-post fra appen din. Test med Gmail og Outlook, og sjekk spam-mappen.

Logg inn med Google (og andre OAuth-leverandører)

«Logg inn med Google» bruker OAuth og OpenID Connect: Google bekrefter hvem brukeren er, og forteller appen din e-posten og navnet deres. Oppsettet, per september 2026, skjer i Google Auth Platform-seksjonen i Google Cloud Console:

1. Opprett eller velg et prosjekt, og fyll ut siden Branding: det brukerne ser på samtykkeskjermen (appnavn, støtte-e-post, logo).
2. På siden Clients oppretter du en klient av typen «Web application».
3. Legg til dine autoriserte JavaScript-opprinnelser og omdirigerings-URI-er: de nøyaktige adressene appen din kjører på, og som Google sender brukere tilbake til etter innlogging.
4. Lagre klient-ID-en og klienthemmeligheten i appens hemmeligheter.

Ting som ofte går galt, ifølge Googles OAuth-dokumentasjon:

• redirect_uri_mismatch: omdirigeringsadressen må stemme nøyaktig, inkludert http mot https, store og små bokstaver og eventuell avsluttende skråstrek. Legg til én for forhåndsvisningsadressen og én for ditt live-domene.
• HTTPS kreves: omdirigerings-URI-er må bruke HTTPS, unntatt localhost under utvikling.
• state-parameteren bør sjekkes ved retur for å beskytte mot cross-site request forgery. Gode biblioteker gjør dette for deg.

Hvis du bare ber om grunnleggende innloggingsinformasjon (navn, e-post, profil), sier Google at appverifisering ikke er obligatorisk. Å be om tilgang til brukeres Gmail, Drive eller Kalender er noe annet og krever verifisering.

Bygge selv eller bruke en leverandør?

Begge de to første er fornuftige. Hostede leverandører tar mer av jobben, men legger til en avhengighet og koster noen ganger per aktiv bruker; sjekk oppdaterte priser på nettsidene deres. Biblioteker holder alt i din database, men overlater mer til deg å konfigurere riktig. Uansett valg, be AI-en bruke det i stedet for å skrive egen logikk for passord eller økter.

Roller og tillatelser

Innlogging forteller deg hvem noen er. Tillatelser avgjør hva de kan gjøre. Hold det enkelt i starten:

Regler som betyr mer enn rollenavnene:

• Sjekk på serveren, hver gang. Å skjule en knapp på siden stopper ikke noen fra å kalle API-et direkte.
• Avgrens til eier. Et medlem som henter «booking 123» skal bare få den hvis den er deres.
• Brukere kan ikke gi seg selv høyere rolle. Ignorer rollefelt sendt fra nettleseren ved profiloppdateringer.
• Standard er ingen tilgang. Nye ruter bør kreve innlogging med mindre du bestemmer noe annet.

Test det med to kontoer: logg inn som én, noter en posts ID, logg inn som den andre og prøv å åpne den. Vår sikkerhetssjekkliste har hele testen.

Øktsikkerhet

Etter innlogging husker appen brukeren med en økt, vanligvis en kapsel. OWASPs veiledning for øktadministrasjon anbefaler:

• Øktkapsler satt med Secure (bare HTTPS), HttpOnly (kan ikke leses av sidens skript) og SameSite
• En ny økt-ID utstedes ved innlogging, og igjen når rettigheter endres
• Tidsavbrudd ved inaktivitet og en absolutt maksimal levetid, håndhevet på serveren
• Utlogging som avslutter økten på serveren, ikke bare sletter kapselen
• Økter ugyldiggjøres når en bruker endrer passord

Lagring av innloggingstokener i nettleserens localStorage er vanlig i veiledninger, men det eksponerer dem for alle skript som kjører på siden. Sikre kapsler er vanligvis det bedre standardvalget for webapper.

En prompt som dekker det viktigste

Legg til brukerkontoer i denne appen. Brukere kan registrere seg og logge inn med e-post og passord, eller med Google. Bruk [bibliotek eller leverandør] i stedet for egen autentiseringskode. Hash passord med Argon2id eller bcrypt. Legg til passordtilbakestilling på e-post med en engangslenke som utløper etter én time. Behold øktene i sikre HttpOnly-kapsler. Beskytt /dashboard og hver /api-rute slik at bare innloggede brukere kan bruke dem, og sørg for at brukere bare kan se sine egne prosjekter. Legg til en «admin»-rolle som kan se alle brukere. Bare administratorer kan nå /admin, sjekket på serveren.

Test deretter: registrer deg, logg ut, logg inn, tilbakestill passordet, prøv en privat URL uten å være innlogget, og prøv en annen brukers post.

Vanlige feil i AI-bygd innlogging

• Beskyttelse bare i siden. Siden sender utloggede brukere videre, men API-et returnerer data til alle.
• Hemmeligheter i nettleseren. OAuth-klienthemmeligheter og administrative nøkler for autentiseringsleverandører hører hjemme på serveren.
• Forhåndsvisning og live-adresse blandet sammen. Googles omdirigerings-URI eller lenken i tilbakestillings-e-posten peker på forhåndsvisningen, så innlogging feiler etter publisering.
• Ingen e-postbekreftelse. Hvem som helst kan registrere seg som noen@firma.no. Bekreft e-post før du gir noe som er knyttet til den adressen.
• Å bare teste den gode veien. Prøv feil passord, utløpte lenker og en andre konto.

Legge til innlogging i Mythex

I Mythex er innlogging for appens brukere noe du legger til i appen din. Det er adskilt fra din egen Mythex-konto. Mythex tilbyr ikke et innebygd autentiseringsprodukt, så du tar med et autentiseringsbibliotek eller en leverandør og nøklene deres:

1. Velg en tilnærming, for eksempel e-post og passord lagret i din egen database, eller en hostet leverandørs SDK.
2. Hvis du lagrer brukere selv, trenger appen en database. Be om en i chatten eller bruk /database.
3. Legg leverandørnøklene i prosjekthemmeligheter (/secrets eller prosjektinnstillinger).
4. Bruk en prompt som den over, og test i Preview. For Google-innlogging, legg til omdirigerings-URI-er for både forhåndsvisningen og den publiserte adressen.

Se Legg til innlogging i appen din i dokumentasjonen. Hvis du bygger et betalt produkt, dekker hvordan bygge en SaaS MVP kontoer og fakturering sammen.

Spørsmål