Implicit Grant Type i OAuth 2.0

Implicit Grant Type, også kendt som "token"-metoden, blev primært designet til klient-side applikationer, hvor klienten ikke sikkert kan opbevare en client secret. Sådanne applikationer inkluderer single-page apps (SPA'er) eller andre browserbaserede applikationer. I stedet for at modtage en autorisationskode, der skal udveksles til et adgangstoken, får applikationen adgangstokenet direkte.

Implicit Grant Type i LoadFocus

Hvordan fungerer Implicit Grant Type?

  1. Omdirigering:
  • Klientapplikationen omdirigerer brugeren til OAuth 2.0-autorisationsserverens autorisationsendpoint. Denne omdirigering inkluderer normalt forespørgselsparametre som client_id, response_type (sat til "token" for Implicit Grant), redirect_uri (hvor autorisationsserveren omdirigerer efter godkendelse/afvisning) og scope (der angiver det anmodede adgangsniveau).
  1. Brugerautentificering:
  • Brugeren logger ind på autorisationsserveren (hvis ikke allerede logget ind) og gennemgår adgangsanmodningen fra klientapplikationen.
  1. Udstedelse af adgangstoken:
  • Hvis brugeren giver adgang, omdirigerer autorisationsserveren dem tilbage til klientapplikationen via den angivne redirect_uri. Omdirigeringens URI inkluderer adgangstokenet (og dets udløb) direkte i fragmentdelen af URL'en.
  1. Adgang til beskyttet ressource:
  • Klientapplikationen udtrækker adgangstokenet fra URL-fragmentet og gemmer det (f.eks. i local storage eller en session). Den bruger derefter dette token til at sende forespørgsler til ressourceserveren (API) på vegne af brugeren.

Sådan konfigurerer du Implicit Grant Type

  1. Registrer din applikation:
  • Start med at registrere din applikation hos OAuth 2.0-udbyderen. Du modtager typisk en client_id efter succesfuld registrering.
  1. Redirect URI-opsætning:
  • Angiv en redirect_uri under registreringen. Autorisationsserveren omdirigerer brugere til denne URI, efter de beslutter om godkendelse eller afvisning. Sørg for, at denne URI er sikker (typisk ved brug af HTTPS) og kan håndtere tokenudtrækning fra URL-fragmentet.
  1. Start OAuth-flow:
  • Omdiriger brugere til autorisationsserverens autorisationsendpoint med de nødvendige parametre. Brug biblioteker eller SDK'er, der passer til din applikations sprog eller framework.
  1. Udtræk og gem tokenet:
  • Når du er omdirigeret tilbage, udtræk adgangstokenet fra URL-fragmentet. Gem tokenet sikkert med klient-side lagringsmuligheder som Web Storage (localStorage eller sessionStorage) eller cookies. Sørg for, at det er beskyttet mod cross-site scripting (XSS) angreb.
  1. Brug tokenet:
  • Vedhæft adgangstokenet til API-forespørgsler sendt til ressourceserveren.
  1. Håndter tokenudløb:
  • Da Implicit Grant normalt ikke giver refresh tokens, kan du være nødt til at starte OAuth-flowet igen for at få et nyt, når et adgangstoken udløber.

Overvejelser:

  • Sikkerhed: Implicit Grant Type betragtes som mindre sikker end Authorization Code Grant Type, især fordi adgangstokenet eksponeres i URL'en. Dette kan være en risiko i miljøer, hvor URL'er kan logges eller tilgås af tredjeparter.

  • Intet refresh token: Typisk giver Implicit Grant ikke refresh tokens. Når et adgangstoken udløber, kan hele flowet derfor skulle gentages.

  • Udfasning: På grund af de iboende sikkerhedsproblemer anbefaler OAuth 2.0 Security Best Current Practice-dokumentet at undgå Implicit Grant til fordel for Authorization Code med PKCE (Proof Key for Code Exchange) for offentlige klienter som SPA'er.

Konklusion:

Mens Implicit Grant Type tilbyder et enklere flow for klient-side apps, har dets sikkerhedsproblemer ført til anbefalinger mod dets brug i moderne applikationer. Hvis du bygger nye applikationer, især SPA'er, overvej at bruge Authorization Code Grant med PKCE for en mere sikker tilgang.