Hvad er autentificering? Login, sessions og OAuth forklaret

Autentificering er, hvordan en app bekræfter, hvem en bruger er — typisk ved at tjekke noget, de kender (en adgangskode), noget, de har (en kode sendt til deres telefon eller e-mail), eller en identitet fra en anden betroet tjeneste (som "Log ind med Google"). Når en bruger er autentificeret, husker appen dem med en session eller et token, så de ikke skal logge ind på hver side. At afgøre, hvad den kendte bruger må gøre, er et separat trin, der kaldes autorisation.

Hvorfor det betyder noget, når du bygger med AI

At tilføje login er en af de mest almindelige anmodninger, folk stiller til en AI-builder, og en af de nemmeste at få subtilt galt. En loginside er nem at generere. Det svære er alt det omkring den:

• Gemmes adgangskoderne sikkert?
• Tjekker hver privat side og hvert API-endpoint faktisk, hvem der spørger?
• Kan en logget ind kunde se en andens data ved at ændre et tal i URL'en?
• Hvad sker der, når nogen glemmer deres adgangskode?

En app kan se helt sikker ud og stadig fejle på alle disse punkter. At forstå de bevægelige dele lader dig stille de rigtige spørgsmål og teste de rigtige ting.

En hverdagsanalogi

Tænk på at tjekke ind på et hotel.

Ved receptionen viser du ID. Det er autentificering: at bevise, hvem du er. Receptionisten giver dig så et nøglekort. Kortet er din session: resten af opholdet viser du ikke ID igen; du bruger kortet.

Kortet åbner dit værelse, fitnesscentret og elevatoren til din etage — men ikke andre gæsters værelser eller personalekontoret. Det er autorisation: hvad din identitet har lov til at få adgang til. Hvis du mister kortet, kan hotellet deaktivere det i receptionen (tilbagekalde en session). Når du checker ud, holder det op med at virke (logout eller udløb).

"Log ind med Google" er som et hotel, der accepterer et brev fra en betroet partner, der siger "dette er hvem de er", i stedet for selv at tjekke dit ID.

De vigtigste login-metoder

Hvordan adgangskoder bør gemmes

En sikker app gemmer aldrig din faktiske adgangskode. I stedet gemmer den en hash: resultatet af en envejsfunktion, der omdanner adgangskoden til en fast streng. Når du logger ind, hasher appen det, du skrev, og sammenligner resultatet med den gemte hash.

To detaljer gør det sikkert:

• Et salt — en tilfældig værdi, der tilføjes hver adgangskode før hashing, så to personer med samme adgangskode får forskellige hashes, og forudberegnede opslagstabeller er ubrugelige.
• En langsom algoritme lavet til adgangskoder — såsom Argon2, bcrypt eller scrypt. Almindelige hashes som MD5 eller SHA-256 er alt for hurtige alene; angribere kan prøve milliarder af gæt.

Hashing er ikke det samme som kryptering. Krypterede data kan dekrypteres med en nøgle; en adgangskode-hash er designet til slet ikke at kunne vendes.

Sessions vs. tokens

Efter login skal appen genkende dig ved hver forespørgsel. Der er to almindelige tilgange.

For cookies betyder tre indstillinger noget: HttpOnly (JavaScript på siden kan ikke læse cookien), Secure (sendes kun over HTTPS) og SameSite (begrænser afsendelse ved forespørgsler fra andre sites). At gemme tokens i browserens localStorage er almindeligt, men udsætter dem for ethvert script, der kører på siden.

OAuth og "Log ind med Google"

OAuth 2.0 er en standard for delegeret autorisation: den lader en app få begrænset adgang til din konto hos en anden tjeneste — for eksempel at læse din Google-kalender — uden nogensinde at se din Google-adgangskode. Du sendes til Google, godkender specifikke rettigheder (kaldet scopes), og Google giver appen et token til kun de rettigheder.

OAuth alene blev designet til at give adgang, ikke til at sige, hvem du er. OpenID Connect (OIDC) er et lag oven på OAuth 2.0, der tilføjer identitet, og det er det, "Log ind med Google" eller "Log ind med Apple" bruger. For at sætte det op registrerer du din app hos udbyderen og får et client ID og en client secret; hemmeligheden bliver på din server.

Et konkret eksempel: login til et kundeportal

Lad os sige, du bygger et portal, hvor et designbureaus kunder ser deres projekter og fakturaer.

• Autentificering: kunder logger ind med e-mail og et magisk link, så der ingen adgangskoder er at administrere. Bureauets medarbejdere logger ind med Google Workspace-konti.
• Roller: hver bruger har en rolle — client eller staff.
• Autorisationsregler:

• Hvor det håndhæves: på serveren, for hver forespørgsel. Serveren slår den indloggede bruger op og returnerer kun projekter, hvor project.company_id matcher brugerens firma. At skjule knappen "Marker betalt" er ikke nok — endpointet selv skal afvise.

Almindelige begreber forklaret

Almindelige fejl og misforståelser

• At tjekke rettigheder kun i siden. Hvis browseren skjuler en knap, men API'et ikke tjekker, kan alle kalde API'et direkte.
• At stole på ID'er i URL'en. /invoices/1042 skal tjekke, at faktura 1042 tilhører den indloggede bruger.
• At lave sin egen kryptering. Brug velkendte biblioteker eller udbydere; lad ikke AI'en opfinde et hashing-skema.
• Svag nulstilling af adgangskode. Nulstillingslinks skal kunne bruges én gang, udløbe hurtigt og ikke afsløre, om en e-mail har en konto.
• At blande dit login med builderens. Din apps brugere er adskilt fra din konto hos værktøjet, du bygger med.
• Ingen hastighedsbegrænsning på login. Uden den kan angribere prøve adgangskoder uendeligt.

Hvad du beder din AI-builder om

• "Tilføj oprettelse og login med [et velkendt bibliotek eller en udbyder]. Skriv ikke egen adgangskode-hashing."
• "Gem adgangskoder hashet med bcrypt eller Argon2."
• "Brug HttpOnly- og Secure-cookies til sessionen."
• "Tilføj roller: admin og member. List hvert endpoint, og hvilke roller der må kalde det."
• "Håndhæv på serveren, at brugere kun kan læse og redigere deres egne poster. Vis mig derefter, hvordan du har tjekket det."
• "Tilføj nulstilling af adgangskode med engangslinks, der udløber efter en time."
• "Begræns antallet af loginforsøg."

Test derefter selv: opret to konti og prøv at få adgang til den ene brugers data, mens du er logget ind som den anden. Vores guide til at tilføje login og sikkerhedstjekliste går længere.

Autentificering i Mythex

Mythex tilbyder ikke et indbygget auth-produkt til din apps brugere; du vælger en tilgang — e-mail og adgangskode gemt i dit projekts database eller en hostet udbyders SDK — og beder agenten tilføje den. Udbyder-nøgler lægges i projekthemmeligheder, ikke i chatten. Dette er adskilt fra, hvordan du logger ind på Mythex selv. Docs-opskriften om tilføjelse af login til din app har en startprompt, du kan tilpasse, og hvad er en API forklarer, hvor de serverside-tjek ligger.

Spørgsmål