Så lägger du till inloggning i din app: lösenord, magiska länkar, Google och roller

För att lägga till inloggning i en app väljer du en metod — e-post och lösenord, magiska länkar (en engångsinloggningslänk som skickas via e-post) eller “Logga in med Google” — och implementerar den med ett beprövat autentiseringsbibliotek eller en hostad leverantör i stället för från början. Bestäm sedan vad varje typ av användare får göra (roller), och tillämpa det på servern för varje sida och varje API-förfrågan. Sessioner ska använda säkra cookies, gå ut och avslutas ordentligt vid utloggning.

Den här guiden går igenom varje val och de detaljer som skiljer en fungerande inloggning från en säker. För koncepten bakom den, se vad är autentisering.

Bestäm först: behöver du inloggning alls?

Inloggning ger friktion och ansvar. Du behöver den när:

• Användare har privat data (sina bokningar, dokument, fakturor)
• Användare kan ändra saker som andra kommer att se
• Du tar betalt för åtkomst
• Olika personer behöver olika behörigheter (ägare kontra personal kontra kund)

Du behöver kanske inte det för en marknadsföringswebbplats, en offentlig katalog eller ett formulär som bara skickar dig ett e-postmeddelande. En väntelista behöver inga konton; ett e-postfält räcker.

De fyra vanliga inloggningsmetoderna

Många appar kombinerar två: Google-inloggning plus magiska e-postlänkar är en populär kombination som täcker de flesta utan att lagra några lösenord.

E-post och lösenord

Om du erbjuder lösenord är dessa icke förhandlingsbara:

• Hasha lösenord med en långsam lösenordshashalgoritm. OWASP:s vägledning för lösenordslagring rekommenderar Argon2id, med scrypt, bcrypt eller PBKDF2 som alternativ. Lagra aldrig lösenord i klartext eller med en snabb allmän hash.
• Lösenordsåterställningar använder en slumpmässig, engångslänk som går ut, skickad till den verifierade e-postadressen.
• Avslöja inte vilka e-postadresser som har konton. “Om den e-postadressen är registrerad har vi skickat en återställningslänk” är bättre än “Inget konto hittades”.
• Begränsa antalet försök för inloggning och återställning för att bromsa lösenordsgissning.
• Tillåt långa lösenord och lösenordshanterare; hoppa över regler som tvingar fram konstiga teckenkombinationer.

Magiska länkar och engångskoder

En magisk länk är en inloggningslänk som skickas till användaren via e-post. Att klicka på den loggar in dem. En engångskod är samma idé, men inskriven i stället för klickad.

• Länkar och koder går ut snabbt och fungerar bara en gång.
• Länken ska logga in användaren på enheten där den klickades, och token får inte stanna i loggar eller analysverktyg.
• Du behöver pålitlig e-postutskick — se hur du skickar e-post från din app. Testa med Gmail och Outlook, och kontrollera skräppostmapparna.

Logga in med Google (och andra OAuth-leverantörer)

“Logga in med Google” använder OAuth och OpenID Connect: Google bekräftar vem användaren är och berättar för din app deras e-post och namn. Installationen sker, från och med september 2026, i avsnittet Google Auth Platform i Google Cloud Console:

1. Skapa eller välj ett projekt, och fyll i sidan Varumärke — vad användarna ser på samtyckesskärmen (appnamn, supportadress, logotyp).
2. På sidan Klienter skapar du en klient av typen “Webbapplikation”.
3. Lägg till dina auktoriserade JavaScript-ursprung och omdirigerings-URI:er — de exakta adresserna din app körs på och dit Google skickar tillbaka användarna efter inloggning.
4. Lagra klient-ID och klienthemlighet i din apps hemligheter.

Saker som ofta går fel, enligt Googles OAuth-dokumentation:

• redirect_uri_mismatch: omdirigeringsadressen måste matcha exakt, inklusive http mot https, versaler och ett eventuellt avslutande snedstreck. Lägg till en för din förhandsvisningsadress och en för din live-domän.
• HTTPS krävs: omdirigerings-URI:er måste använda HTTPS, utom localhost under utveckling.
• Parametern state bör kontrolleras vid återkomst för att skydda mot cross-site request forgery. Bra bibliotek gör detta åt dig.

Om du bara begär grundläggande inloggningsuppgifter (namn, e-post, profil) säger Google att appverifiering inte är obligatorisk. Att begära åtkomst till användares Gmail, Drive eller Kalender är något annat och kräver verifiering.

Bygg själv eller använd en leverantör?

De två första är rimliga. Hostade leverantörer hanterar mer åt dig men lägger till ett beroende och kostar ibland per aktiv användare; kontrollera aktuella priser på deras webbplatser. Bibliotek håller allt i din databas men lämnar mer för dig att konfigurera korrekt. Oavsett vilket du väljer, be AI:n att använda det i stället för att handbygga lösenords- eller sessionslogik.

Roller och behörigheter

Inloggning talar om vem någon är. Behörigheter avgör vad de får göra. Håll det enkelt i början:

Regler som betyder mer än rollnamnen:

• Kontrollera på servern, varje gång. Att dölja en knapp på sidan stoppar inte någon från att anropa API:et direkt.
• Avgränsa efter ägare. En medlem som hämtar “bokning 123” ska bara få den om den är deras.
• Användare kan inte befordra sig själva. Ignorera rollfält som skickas från webbläsaren vid profiluppdateringar.
• Standard är ingen åtkomst. Nya rutter bör kräva inloggning om du inte bestämmer annat.

Testa med två konton: logga in som ett, notera en posts ID, logga in som det andra och försök öppna den. Vår säkerhetschecklista har hela testet.

Sessionssäkerhet

Efter inloggning kommer appen ihåg användaren med en session — oftast en cookie. OWASP:s vägledning för sessionshantering rekommenderar:

• Sessionscookies satta med Secure (bara HTTPS), HttpOnly (kan inte läsas av sidskript) och SameSite
• Ett nytt sessions-ID utfärdas vid inloggning, och igen när behörigheter ändras
• En tidsgräns för inaktivitet och en absolut maximal livslängd, tillämpade på servern
• Utloggning som avslutar sessionen på servern, inte bara raderar cookien
• Sessioner ogiltigförklaras när en användare byter lösenord

Att lagra inloggningstokens i webbläsarens localStorage är vanligt i handledningar, men exponerar dem för alla skript som körs på sidan; säkra cookies är oftast det bättre standardvalet för webbappar.

En prompt som täcker grunderna

Lägg till användarkonton i den här appen. Användare kan registrera sig och logga in med e-post och lösenord, eller med Google. Använd [bibliotek eller leverantör] i stället för egen autentiseringskod. Hasha lösenord med Argon2id eller bcrypt. Lägg till lösenordsåterställning via e-post med en engångslänk som går ut efter en timme. Behåll sessioner i säkra HttpOnly-cookies. Skydda /dashboard och varje /api-rutt så att bara inloggade användare kan använda dem, och se till att användare bara ser sina egna projekt. Lägg till en roll “admin” som kan se alla användare; bara admins kan nå /admin, kontrollerat på servern.

Testa sedan: registrera dig, logga ut, logga in, återställ lösenordet, försök öppna en privat URL utloggad och försök öppna en annan användares post.

Vanliga misstag i AI-byggd inloggning

• Skydd bara på sidan. Sidan skickar utloggade användare vidare, men API:et returnerar data till vem som helst.
• Hemligheter i webbläsaren. OAuth-klienthemligheter och administrativa nycklar för autentiseringsleverantörer hör hemma på servern.
• Förhandsvisnings- och live-URL:er blandade. Googles omdirigerings-URI eller återställningsmejlets länk pekar på förhandsvisningen, så inloggningen går sönder efter publicering.
• Ingen e-postverifiering. Vem som helst kan registrera sig som någon@företag.se. Verifiera e-post innan du ger något som är kopplat till adressen.
• Att bara testa lyckosamma flödet. Prova fel lösenord, utgångna länkar och ett andra konto.

Lägga till inloggning i Mythex

På Mythex är inloggning för din apps användare något du lägger till i din app — det är separat från ditt eget Mythex-konto. Mythex tillhandahåller ingen inbyggd autentiseringsprodukt, så du tar med ett autentiseringsbibliotek eller en leverantör och dess nycklar:

1. Välj en ansats — till exempel e-post och lösenord lagrade i din egen databas, eller en hostad leverantörs SDK.
2. Om du lagrar användare själv behöver appen en databas; be om en i chatten eller använd /database.
3. Lägg leverantörsnycklar i projekthemligheter (/secrets eller projektinställningarna).
4. Använd en prompt som den ovan, och testa sedan i förhandsvisningen. För Google-inloggning, lägg till omdirigerings-URI:er för både din förhandsvisning och din publicerade adress.

Se Lägg till inloggning i din app i dokumentationen. Om du bygger en betald produkt täcker hur du bygger en SaaS-MVP konton och fakturering tillsammans.

Frågor