Hva er autentisering? Innlogging, sesjoner og OAuth forklart

Autentisering er hvordan en app bekrefter hvem en bruker er – vanligvis ved å sjekke noe brukeren vet (et passord), noe brukeren har (en kode sendt til telefonen eller e-posten) eller en identitet fra en annen pålitelig tjeneste (for eksempel «Logg inn med Google»). Når en bruker er autentisert, husker appen dem med en sesjon eller et token, slik at de ikke må logge inn på hver side. Å bestemme hva den kjente brukeren har lov til å gjøre, er et eget steg som kalles autorisasjon.

Hvorfor det betyr noe når du bygger med KI

Å legge til innlogging er en av de vanligste forespørslene folk gjør til en KI-appbygger, og en av de lettest å få subtilt feil. En innloggingsside er enkel å generere. Det vanskelige er alt rundt den:

• Lagres passordene trygt?
• Sjekker hver private side og hvert API-endepunkt faktisk hvem som spør?
• Kan en innlogget kunde se en annen kundes data ved å endre et nummer i URL-en?
• Hva skjer når noen glemmer passordet sitt?

En app kan se helt sikker ut og likevel feile på alle disse punktene. Å forstå de bevegelige delene lar deg stille de riktige spørsmålene og teste de riktige tingene.

En hverdagslig analogi

Tenk deg at du sjekker inn på et hotell.

I resepsjonen viser du ID. Det er autentisering: å bevise hvem du er. Resepsjonisten gir deg så et nøkkelkort. Kortet er din sesjon: resten av oppholdet viser du ikke ID igjen; du bruker kortet.

Kortet åpner rommet ditt, treningsrommet og heisen til etasjen din – men ikke andre gjesters rom eller personalkontoret. Det er autorisasjon: hva identiteten din har lov til å få tilgang til. Hvis du mister kortet, kan hotellet deaktivere det i resepsjonen (tilbakekalle en sesjon). Når du sjekker ut, slutter det å fungere (utlogging, eller utløp).

«Logg inn med Google» er som at et hotell aksepterer et brev fra en pålitelig partner som sier «dette er hvem de er», i stedet for å sjekke ID-en din selv.

De viktigste innloggingsmetodene

Hvordan passord bør lagres

En sikker app lagrer aldri det faktiske passordet ditt. I stedet lagrer den en hash: resultatet av en envegsfunksjon som gjør passordet om til en fast streng. Når du logger inn, hasher appen det du skrev og sammenligner resultatet med den lagrede hashen.

To detaljer gjør dette trygt:

• Et salt – en tilfeldig verdi som legges til hvert passord før hashing, slik at to personer med samme passord får ulike hasher, og forhåndsberegnede oppslagstabeller er ubrukelige.
• En treg algoritme laget for passord – for eksempel Argon2, bcrypt eller scrypt. Generelle hasher som MD5 eller SHA-256 er alt for raske alene; angripere kan prøve milliarder av gjetninger.

Hashing er ikke det samme som kryptering. Kryptert data kan dekrypteres med en nøkkel; en passordhash er laget for at den ikke skal kunne reverseres i det hele tatt.

Sesjoner vs tokener

Etter innlogging må appen kjenne deg igjen i hver forespørsel. Det finnes to vanlige tilnærminger.

For informasjonskapsler betyr tre innstillinger noe: HttpOnly (JavaScript på siden kan ikke lese informasjonskapselen), Secure (sendes bare over HTTPS) og SameSite (begrenser sending i forespørsler fra andre sider). Å lagre tokener i nettleserens localStorage er vanlig, men det eksponerer dem for alle skript som kjører på siden.

OAuth og «Logg inn med Google»

OAuth 2.0 er en standard for delegert autorisasjon: den lar en app få begrenset tilgang til kontoen din hos en annen tjeneste – for eksempel å lese Google-kalenderen din – uten å noen gang se Google-passordet ditt. Du sendes til Google, godkjenner bestemte tillatelser (kalt scopes), og Google gir appen et token for akkurat disse tillatelsene.

OAuth alene var laget for å gi tilgang, ikke for å si hvem du er. OpenID Connect (OIDC) er et lag oppå OAuth 2.0 som legger til identitet, og det er det «Logg inn med Google» eller «Logg inn med Apple» bruker. For å sette det opp registrerer du appen din hos leverandøren og får en klient-ID og en klienthemmelighet; hemmeligheten holdes på serveren din.

Et praktisk eksempel: innlogging for et kundeportal

Tenk deg at du bygger et portal der kundene til et designbyrå ser prosjektene og fakturaene sine.

• Autentisering: kundene logger inn med e-post og en magic link, så det er ingen passord å håndtere. Ansatte i byrået logger inn med Google Workspace-kontoer.
• Roller: hver bruker har en rolle – client eller staff.
• Autorisasjonsregler:

• Hvor det håndheves: på serveren, for hver forespørsel. Serveren slår opp den innloggede brukeren og returnerer bare prosjekter der project.company_id samsvarer med brukerens selskap. Å skjule «Merk betalt»-knappen er ikke nok – endepunktet selv må nekte.

Vanlige begreper forklart

Vanlige feil og misforståelser

• Å sjekke tillatelser bare i siden. Hvis nettleseren skjuler en knapp, men API-et ikke sjekker, kan hvem som helst kalle API-et direkte.
• Å stole på ID-er fra URL-en. /invoices/1042 må sjekke at faktura 1042 tilhører den innloggede brukeren.
• Å lage egen kryptografi. Bruk kjente biblioteker eller leverandører; la ikke KI-en finne opp en egen hashingmetode.
• Svak tilbakestilling av passord. Tilbakestillingslenker bør være engangslenker, utløpe raskt og ikke avsløre om en e-post har en konto.
• Å blande din innlogging med byggerens. Brukerne i appen din er separate fra kontoen din hos verktøyet du bygger med.
• Ingen begrensning på antall innloggingsforsøk. Uten den kan angripere prøve passord uendelig.

Hva du bør be KI-appbyggeren din om

• «Legg til registrering og innlogging med [et kjent bibliotek eller en leverandør]. Ikke skriv egen passordhashing.»
• «Lagre passord hashet med bcrypt eller Argon2.»
• «Bruk HttpOnly- og Secure-informasjonskapsler for sesjonen.»
• «Legg til roller: admin og member. List opp hvert endepunkt og hvilke roller som kan kalle det.»
• «Håndhev på serveren at brukere bare kan lese og redigere sine egne poster. Vis meg så hvordan du sjekket det.»
• «Legg til tilbakestilling av passord med engangslenker som utløper etter én time.»
• «Begrens antall innloggingsforsøk.»

Test det deretter selv: opprett to kontoer og prøv å nå den ene kontoens data mens du er logget inn som den andre. Vår guide til å legge til innlogging og sikkerhetssjekklisten går lenger.

Autentisering i Mythex

Mythex tilbyr ikke et innebygd autentiseringsprodukt for appens brukere; du velger en tilnærming – e-post og passord lagret i prosjektets database, eller en hostet leverandørs SDK – og ber agenten legge det til. Nøkler til leverandører legges som prosjekthemmeligheter, ikke i chatten. Dette er separat fra hvordan du logger inn i Mythex selv. Dokumentasjonsoppskriften om å legge til innlogging i appen din har en startprompt du kan tilpasse, og hva et API er forklarer hvor de serverbaserte sjekkene ligger.

Spørsmål