Sådan tilføjer du login til din app: adgangskoder, magiske links, Google og roller

For at tilføje login til en app vælger du en metode — e-mail og adgangskode, magiske links (et engangs-login-link sendt via e-mail) eller „Log ind med Google“ — og implementerer den med et bevist auth-bibliotek eller en hostet udbyder frem for fra bunden. Derefter beslutter du, hvad hver type bruger må (roller), og håndhæver det på serveren for hver side og API-anmodning. Sessioner skal bruge sikre cookies, udløbe, og afsluttes ordentligt ved log ud.

Denne guide gennemgår hvert valg og de detaljer, der adskiller et fungerende login fra et sikkert. For begreberne bag, se hvad er autentificering.

Beslut først: har du overhovedet brug for login?

Login medfører friktion og ansvar. Du har brug for det, når:

• Brugere har private data (deres bookinger, dokumenter, fakturaer)
• Brugere kan ændre ting, andre vil se
• Du tager betaling for adgang
• Forskellige personer har brug for forskellige rettigheder (ejer vs. medarbejder vs. kunde)

Du har måske ikke brug for det til et marketingsite, en offentlig fortegnelse eller en formular, der blot sender dig en e-mail. En venteliste kræver ikke konti; et e-mailfelt er nok.

De fire almindelige loginmetoder

Mange apps kombinerer to: Google-login plus e-mail-magiske links er en populær kombination, der dækker de fleste uden at gemme nogen adgangskoder.

E-mail og adgangskode

Hvis du tilbyder adgangskoder, er disse ikke til forhandling:

• Hash adgangskoder med en langsom adgangskode-hashalgoritme. OWASPs vejledning om lagring af adgangskoder anbefaler Argon2id, med scrypt, bcrypt eller PBKDF2 som alternativer. Gem aldrig adgangskoder i klartekst eller med en hurtig generel hash.
• Nulstilling af adgangskode bruger et tilfældigt, engangs-link, der udløber, sendt til den verificerede e-mail.
• Afslør ikke, hvilke e-mails der har konti. „Hvis den e-mail er registreret, har vi sendt et nulstillingslink“ er bedre end „Ingen konto fundet“.
• Begræns antallet af forsøg på login og nulstilling for at bremse gætning af adgangskoder.
• Tillad lange adgangskoder og adgangskodeadministratorer; spring regler over, der tvinger mærkelige tegnblandinger.

Magiske links og engangskoder

Et magisk link er et login-link sendt til brugeren via e-mail. Når de klikker på det, logges de ind. En engangskode er den samme idé, men indtastet i stedet for klikket.

• Links og koder udløber hurtigt og virker kun én gang.
• Linket skal logge brugeren ind på den enhed, hvor de klikkede, og tokenet må ikke blive i logs eller analyseværktøjer.
• Du har brug for pålidelig e-mailafsendelse — se sådan sender du e-mails fra din app. Test med Gmail og Outlook, og tjek spammapper.

Log ind med Google (og andre OAuth-udbydere)

„Log ind med Google“ bruger OAuth og OpenID Connect: Google bekræfter, hvem brugeren er, og fortæller din app deres e-mail og navn. Opsætningen sker pr. september 2026 i sektionen Google Auth Platform i Google Cloud Console:

1. Opret eller vælg et projekt, og udfyld siden Branding — det brugerne ser på samtykkeskærmen (appens navn, support-e-mail, logo).
2. På siden Clients opretter du en klient af typen „Web application“.
3. Tilføj dine autoriserede JavaScript-oprindelser og omdirigerings-URI'er — de præcise adresser din app kører på, og som Google sender brugerne tilbage til efter login.
4. Gem klient-ID og klienthemmelighed i din apps hemmeligheder.

Ting der ofte går galt, ifølge Googles OAuth-dokumentation:

• redirect_uri_mismatch: omdirigerings-adressen skal matche præcist, inklusive http vs. https, store/små bogstaver og eventuelt skråstreg til sidst. Tilføj én for din preview-adresse og én for dit live-domæne.
• HTTPS kræves: omdirigerings-URI'er skal bruge HTTPS, undtagen localhost under udvikling.
• state-parameteren bør kontrolleres ved tilbagevenden for at beskytte mod cross-site request forgery. Gode biblioteker gør dette for dig.

Hvis du kun beder om grundlæggende loginoplysninger (navn, e-mail, profil), siger Google, at app-verifikation ikke er obligatorisk. At bede om adgang til brugeres Gmail, Drive eller Kalender er noget andet og kræver verifikation.

Byg selv eller brug en udbyder?

Begge de to første er rimelige. Hostede udbydere håndterer mere for dig, men tilføjer en afhængighed og koster nogle gange pr. aktiv bruger; tjek de aktuelle priser på deres sider. Biblioteker holder alt i din database, men lader mere være op til dig at konfigurere korrekt. Uanset hvad du vælger, så bed AI'en bruge det frem for at skrive adgangskode- eller sessionslogik selv.

Roller og rettigheder

Login fortæller dig hvem nogen er. Rettigheder afgør hvad de må gøre. Hold det enkelt i starten:

Regler der betyder mere end rollenavnene:

• Kontrollér på serveren, hver gang. At skjule en knap på siden stopper ikke nogen i at kalde API'et direkte.
• Afgræns efter ejer. Et medlem der henter „booking 123“ må kun få den, hvis den er deres.
• Brugere kan ikke selv forfremme sig. Ignorér rollefelter sendt fra browseren ved profilopdateringer.
• Standard er ingen adgang. Nye ruter bør kræve login, medmindre du beslutter andet.

Test med to konti: log ind som den ene, notér et posts ID, log ind som den anden og prøv at åbne det. Vores sikkerhedstjekliste har den fulde test.

Sessionssikkerhed

Efter login husker appen brugeren med en session — normalt en cookie. OWASPs vejledning om sessionshåndtering anbefaler:

• Sessionscookies sat med Secure (kun HTTPS), HttpOnly (kan ikke læses af sidens scripts) og SameSite
• Et nyt session-ID udstedes ved login, og igen når rettigheder ændres
• En inaktivitets-timeout og en absolut maksimal levetid, håndhævet på serveren
• Log ud, der afslutter sessionen på serveren, ikke blot sletter cookien
• Sessioner ugyldiggøres, når en bruger ændrer sin adgangskode

At gemme login-tokens i browserens local storage er almindeligt i tutorials, men det udsætter dem for ethvert script, der kører på siden; sikre cookies er som regel den bedre standard for webapps.

En prompt der dækker det væsentlige

Tilføj brugerkonti til denne app. Brugere kan oprette sig og logge ind med e-mail og adgangskode, eller med Google. Brug [bibliotek eller udbyder] i stedet for egen auth-kode. Hash adgangskoder med Argon2id eller bcrypt. Tilføj nulstilling af adgangskode via e-mail med et engangslink, der udløber efter en time. Gem sessioner i sikre HttpOnly-cookies. Beskyt /dashboard og hver /api-rute, så kun indloggede brugere kan bruge dem, og sørg for at brugere kun ser deres egne projekter. Tilføj en „admin“-rolle, der kan se alle brugere; kun administratorer må komme til /admin, kontrolleret på serveren.

Test derefter: opret en konto, log ud, log ind, nulstil adgangskoden, prøv en privat URL uden at være logget ind, og prøv en anden brugers post.

Almindelige fejl i AI-bygget login

• Beskyttelse kun i siden. Siden omdirigerer udloggede brugere, men API'et returnerer data til alle.
• Hemmeligheder i browseren. OAuth-klienthemmeligheder og admin-nøgler til auth-udbyderen hører hjemme på serveren.
• Preview- og live-URL'er blandet sammen. Googles omdirigerings-URI eller nulstillings-e-mailens link peger på preview, så login går i stykker efter publicering.
• Ingen e-mailverifikation. Hvem som helst kan oprette sig som anyone@company.com. Verificér e-mailen, før du giver noget, der er knyttet til adressen.
• Kun at teste den glade sti. Prøv forkerte adgangskoder, udløbne links og en anden konto.

Tilføj login i Mythex

På Mythex er login for din apps brugere noget, du tilføjer til din app — det er adskilt fra din egen Mythex-konto. Mythex tilbyder ikke et indbygget auth-produkt, så du medbringer et auth-bibliotek eller en udbyder og dens nøgler:

1. Vælg en tilgang — for eksempel e-mail og adgangskode gemt i din egen database, eller en hostet udbyders SDK.
2. Hvis du selv gemmer brugere, skal appen have en database; bed om den i chatten eller brug /database.
3. Læg udbyderens nøgler i projekthemmeligheder (/secrets eller projektindstillinger).
4. Brug en prompt som ovenfor, og test derefter i Preview. Til Google-login tilføjer du omdirigerings-URI'er for både din preview- og din publicerede adresse.

Se Tilføj login til din app i dokumentationen. Hvis du bygger et betalt produkt, dækker sådan bygger du en SaaS-MVP konti og fakturering samlet.

Spørgsmål