Implicit-tilgangstype i OAuth 2.0

Implicit-tilgangstypen, også kjent som "token"-metoden, ble primært designet for klientside-applikasjoner der klienten ikke kan lagre en klienthemmelighet sikkert. Slike applikasjoner inkluderer enkeltsideapplikasjoner (SPA-er) eller andre nettleserbaserte applikasjoner. I stedet for å motta en autorisasjonskode som må byttes mot et tilgangstoken, får applikasjonen tilgangstokenet direkte.

Hvordan fungerer Implicit-tilgangstypen?

1. Omdirigering:

• Klientapplikasjonen omdirigerer brukeren til OAuth 2.0-autorisasjonsserverens autorisasjonsendepunkt. Denne omdirigeringen inkluderer vanligvis spørringsparametere som client_id, response_type (satt til "token" for Implicit Grant), redirect_uri (der autorisasjonsserveren vil omdirigere etter at tilgang er gitt/nektet), og scope (som indikerer det forespurte tilgangsnivået).

2. Brukerautentisering:

• Brukeren logger inn på autorisasjonsserveren (hvis de ikke allerede er innlogget) og vurderer tilgangsforespørselen fra klientapplikasjonen.

3. Utstedelse av tilgangstoken:

• Hvis brukeren gir tilgang, omdirigerer autorisasjonsserveren dem tilbake til klientapplikasjonen via den oppgitte redirect_uri. Omdirigerings-URI-en inkluderer tilgangstokenet (og dets utløp) direkte i fragmentdelen av URL-en.

4. Tilgang til beskyttet ressurs:

• Klientapplikasjonen trekker ut tilgangstokenet fra URL-fragmentet og lagrer det (f.eks. i lokal lagring eller en økt). Den bruker deretter dette tokenet for å gjøre forespørsler til ressursserveren (API) på vegne av brukeren.

Hvordan konfigurere Implicit-tilgangstypen?

1. Registrer applikasjonen din:

• Start med å registrere applikasjonen din hos OAuth 2.0-leverandøren. Du vil vanligvis motta en client_id etter vellykket registrering.

2. Oppsett av Redirect URI:

• Oppgi en redirect_uri under registrering. Autorisasjonsserveren vil omdirigere brukere til denne URI-en etter at de beslutter å gi eller nekte tilgang. Sørg for at denne URI-en er sikker (vanligvis ved bruk av HTTPS) og kan håndtere tokenutveksling fra URL-fragmentet.

3. Start OAuth-flyten:

• Omdiriger brukere til autorisasjonsserverens autorisasjonsendepunkt med de nødvendige parameterne. Bruk biblioteker eller SDK-er tilpasset applikasjonens språk eller rammeverk for å forenkle dette.

4. Trekk ut og lagre tokenet:

• Når du omdirigeres tilbake, trekk ut tilgangstokenet fra URL-fragmentet. Lagre tokenet sikkert, og vurder klientside-lagringsalternativer som Web Storage (localStorage eller sessionStorage) eller informasjonskapsler. Sørg for at det er beskyttet mot cross-site scripting (XSS)-angrep.

5. Bruk tokenet:

• Legg til tilgangstokenet i API-forespørsler til ressursserveren.

6. Håndtere tokenutløp:

• Siden Implicit Grant vanligvis ikke gir oppdateringstoken, kan du måtte starte OAuth-flyten på nytt for å innhente et nytt tilgangstoken når det utløper.

Hensyn:

• Sikkerhet: Implicit-tilgangstypen anses som mindre sikker enn Authorization Code-tilgangstypen, spesielt fordi tilgangstokenet eksponeres i URL-en. Dette kan være en risiko i miljøer der URL-er kan logges eller nås av tredjeparter.

• Ingen oppdateringstoken: Vanligvis gir ikke Implicit Grant oppdateringstoken. Derfor kan hele flyten måtte gjentas når et tilgangstoken utløper.

• Avvikling: På grunn av iboende sikkerhetsproblemer anbefaler OAuth 2.0 Security Best Current Practice-dokumentet å unngå Implicit Grant til fordel for Authorization Code med PKCE (Proof Key for Code Exchange) for offentlige klienter, som SPA-er.

Konklusjon:

Selv om Implicit-tilgangstypen tilbyr en enklere flyt for klientside-apper, har sikkerhetsproblemene ført til anbefalinger mot bruk i moderne applikasjoner. Hvis du bygger nye applikasjoner, spesielt SPA-er, vurder å bruke Authorization Code Grant med PKCE for en sikrere tilnærming.