Grant types, eller autentiseringsflyt, er ulike måter for hvordan en klient kan samhandle med STS-en.
OpenID Connect 1.0 definerer 3 forskjellige autentiseringsflyter (eksterne lenker):
OAuth 2.0 definerer 6 grant types (eksterne lenker):
- Authorization code grant
- Implicit grant
- Resource owner password credentials grant
- Client credentials grant
- Extension grant
- Refresh token
FIA STS implementerer, eller tilrettelegger for, det som kombinert blir 7 grant types (autentiseringsflyter), som vil kort forklares her.
Implicit flow er primært tiltenkt browserbaserte applikasjoner, det være seg enten for brukerautentisering alene, eller både autentiserings- og access token-forespørsler, der det sistnevnte vil gjelde for JavaScript-applikasjoner. En SPA (Single Page Application) er det typiske brukstilfellet for implicit flow.
Ved implicit flow vil tokens bli sendt via browseren, altså frontkanalen. Av sikkerhetsmessige årsaker tillates ikke refresh tokens ved implicit flow.
I motsetning til ved implicit flow, overføres tokens ikke via frontkanalen (browseren) med authorization code flow. En autorisasjonskode overføres via frontkanalen inn til klienten, som videre kontakter STS-ens Token-endepunkt vedlagt autorisasjonskoden, og får et identity token, et access token og eventuelt et refresh token i retur. I tillegg må klienten autentisere seg mot STS-en med eksempelvis en delt hemmelighet, eller et klientsertifikat, for å få lov til å bruke autorisasjonskoden til å hente ut informasjon. Dette for å hindre at autorisasjonskoden brukes av uvedkommende tredjepart.
Klientautentisering er beskrevet i spesifikasjonen for OpenID Connect Core 1.0.
I tilfeller der klienten befinner seg i et miljø som gjør at den ikke kan holde på en delt statisk hemmelighet over tid, er PKCE et alternativ. PKCE-protokollen er spesifisert her.
I korte trekk oppretter klienten en dynamisk hemmelighet, som hashes og vedlegges autentiseringsforespørselen for brukeren. FIA STS må på sin side internt assosiere den hashede hemmeligheten med autorisasjonskoden som utstedes etter autentisering hos den brukervalgte identitetstilbyderen. Når koden senere brukes mot token-endepunktet hos FIA STS, må hemmeligheten, i klartekst, vedlegges forespørselen. FIA STS hasher klarteksthemmeligheten og sammenligner med autorisasjonskodens assosierte hemmelighet.
Eksempel på flyt for en desktop- eller mobilapplikasjon med dynamisk opprettet PKCE-hemmelighet overfor FIA STS
Hybrid flow kombinerer mulighetene ved implicit og authorization code flow. For de fleste konfigurasjoner vil autorisasjonskode og identity token overføres via frontkanalen, mens access token og eventuelt refresh token hentes via bakkanalen. Det er mulig å også overføre access token via frontkanalen, for spesielle brukstilfeller.
Hybrid flow kan gjerne brukes for serverside-applikasjoner med en delt statisk hemmelighet, og native desktop- eller mobilapplikasjoner sammen med PKCE.
Client credentials er den enkleste granttypen, og brukes for server-til-server-kommunikasjon. Tokens forespørres alltid på vegne av en klient, ikke en bruker.
En klient autentiserer seg mot Token-endepunktet ved hjelp av klientidentifikatoren sin, samt en delt hemmelighet eller klientsertifikat.
Ikke relevant for FIA STS siden løsningen ikke eier en brukerbase.
Extension grants muliggjør å utvide Token-endepunktet med nye (custom) grant types, noe som tillater skreddersøm av samhandlingen mellom klient og STS.
Med refresh tokens oppnår man langvarig tilgang til et tjenestegrensesnitt, siden de tillater en klient å forespørre nye access tokens uten brukerinteraksjon. Det er mulig å nyttiggjøre refresh tokens i hybrid, authorization code eller resource owner password flows, gitt at man har forespurt scopet offline_access.