Vad är autentisering? Inloggning, sessioner och OAuth förklarat

Autentisering är hur en app bekräftar vem en användare är – oftast genom att kontrollera något de vet (ett lösenord), något de har (en kod som skickas till deras telefon eller e-post) eller en identitet från en annan betrodd tjänst (till exempel "Logga in med Google"). När en användare är autentiserad minns appen dem med en session eller token, så att de inte behöver logga in på varje sida. Att avgöra vad den kända användaren får göra är ett separat steg som kallas auktorisering.

Varför det spelar roll när du bygger med AI

Att lägga till inloggning är en av de vanligaste förfrågningarna till en AI-byggare, och en av de lättaste att få subtilt fel. En inloggningssida är enkel att generera. Det svåra är allt runt omkring:

• Lagras lösenorden säkert?
• Kontrollerar varje privat sida och varje API-endpoint verkligen vem som frågar?
• Kan en inloggad kund se en annan kunds data genom att ändra ett nummer i URL:en?
• Vad händer när någon glömmer sitt lösenord?

En app kan se helt säker ut men misslyckas med alla dessa. Att förstå de rörliga delarna låter dig ställa rätt frågor och testa rätt saker.

En vardaglig liknelse

Tänk dig att checka in på ett hotell.

Vid receptionen visar du legitimation. Det är autentisering: att bevisa vem du är. Receptionisten ger dig sedan ett nyckelkort. Kortet är din session: under resten av vistelsen visar du inte legitimation igen; du använder kortet.

Kortet öppnar ditt rum, gymmet och hissen till din våning – men inte andra gästers rum eller personalkontoret. Det är auktorisering: vad din identitet får komma åt. Om du tappar kortet kan hotellet inaktivera det vid disken (att återkalla en session). När du checkar ut slutar det fungera (utloggning eller att den går ut).

"Logga in med Google" är som när ett hotell accepterar ett brev från en betrodd partner som säger "det här är vem den här personen är", i stället för att kontrollera din legitimation själv.

De vanligaste inloggningsmetoderna

Hur lösenord ska lagras

En säker app lagrar aldrig ditt faktiska lösenord. Den lagrar i stället en hash: resultatet av en envägsfunktion som gör om lösenordet till en fast sträng. När du loggar in hashar appen det du skrev och jämför resultatet med den lagrade hashen.

Två detaljer gör detta säkert:

• Ett salt – ett slumpmässigt värde som läggs till varje lösenord före hashning, så att två personer med samma lösenord får olika hashar och förberäknade uppslagstabeller blir värdelösa.
• En långsam algoritm gjord för lösenord – till exempel Argon2, bcrypt eller scrypt. Allmänna hashfunktioner som MD5 eller SHA-256 är alldeles för snabba på egen hand; angripare kan prova miljarder gissningar.

Hashning är inte samma sak som kryptering. Krypterad data kan dekrypteras med en nyckel; en lösenordshash är avsedd att inte gå att vända alls.

Sessioner kontra token

Efter inloggningen behöver appen kunna känna igen dig vid varje anrop. Det finns två vanliga sätt.

För cookies spelar tre inställningar roll: HttpOnly (JavaScript på sidan kan inte läsa cookien), Secure (skickas bara över HTTPS) och SameSite (begränsar när den skickas med anrop från andra sajter). Att lagra token i webbläsarens localStorage är vanligt men exponerar dem för alla skript som körs på sidan.

OAuth och "Logga in med Google"

OAuth 2.0 är en standard för delegerad auktorisering: den låter en app få begränsad åtkomst till ditt konto hos en annan tjänst – till exempel att läsa din Google-kalender – utan att någonsin se ditt Google-lösenord. Du skickas till Google, godkänner specifika behörigheter (kallade scopes), och Google ger appen en token bara för dessa behörigheter.

OAuth ensamt är gjord för att ge åtkomst, inte för att säga vem du är. OpenID Connect (OIDC) är ett lager ovanpå OAuth 2.0 som lägger till identitet, vilket är det "Logga in med Google" eller "Logga in med Apple" använder. För att ställa in det registrerar du din app hos leverantören och får ett klient-ID och en klienthemlighet; hemligheten stannar på din server.

Ett praktiskt exempel: inloggning för en kundportal

Säg att du bygger en portal där en designbyrås kunder ser sina projekt och fakturor.

• Autentisering: kunder loggar in med e-post och en engångslänk, så det finns inga lösenord att hantera. Byråns personal loggar in med Google Workspace-konton.
• Roller: varje användare har en roll – client eller staff.
• Auktoriseringsregler:

• Var det tillämpas: på servern, för varje anrop. Servern slår upp den inloggade användaren och returnerar bara projekt där project.company_id matchar användarens företag. Att dölja knappen "Markera betald" räcker inte – endpointen själv måste neka.

Vanliga begrepp förklarade

Vanliga misstag och missuppfattningar

• Att bara kontrollera behörigheter i sidan. Om webbläsaren döljer en knapp men API:et inte kontrollerar något kan vem som helst anropa API:et direkt.
• Att lita på ID:n från URL:en. /invoices/1042 måste kontrollera att faktura 1042 tillhör den inloggade användaren.
• Att bygga egen kryptering. Använd välkända bibliotek eller leverantörer; låt inte AI:n hitta på ett eget hashschema.
• Svag lösenordsåterställning. Återställningslänkar bör vara engångs, gå ut snabbt och inte avslöja om en e-post har ett konto.
• Att blanda ihop din inloggning med byggverktygets. Din apps användare är separata från ditt konto hos verktyget du bygger med.
• Ingen hastighetsbegränsning vid inloggning. Utan den kan angripare prova lösenord i oändlighet.

Vad du ska fråga din AI-byggare om

• "Lägg till registrering och inloggning med [ett välkänt bibliotek eller en leverantör]. Skriv inte egen lösenordshashning."
• "Lagra lösenord hashade med bcrypt eller Argon2."
• "Använd HttpOnly- och Secure-cookies för sessionen."
• "Lägg till roller: admin och member. Lista varje endpoint och vilka roller som får anropa den."
• "Se till på servern att användare bara kan läsa och ändra sina egna poster. Visa sedan hur du kontrollerade det."
• "Lägg till lösenordsåterställning med engångslänkar som går ut efter en timme."
• "Begränsa antalet inloggningsförsök."

Testa sedan själv: skapa två konton och försök nå ena kontots data medan du är inloggad som det andra. Vår guide om att lägga till inloggning och checklistan för säkerhet går längre.

Autentisering i Mythex

Mythex tillhandahåller ingen inbyggd autentiseringsprodukt för din apps användare; du väljer ett sätt – e-post och lösenord lagrade i projektets databas, eller en hanterad leverantörs SDK – och ber agenten lägga till det. Leverantörsnycklar läggs i projekthemligheter, inte i chatten. Detta är separat från hur du loggar in i Mythex själv. Receptet i dokumentationen om att lägga till inloggning i din app har en startprompt du kan anpassa, och vad ett API är förklarar var kontrollerna på servern finns.

Frågor