Autentisering til SPA'er
Overordna beskrivelse av bruksområdet
Single-page applikasjoner (SPA) har økende popularitet. Disse skiller seg fra tradisjonelle nettjenester ved at SPAen er realisert som en ren javascript-applikasjon i brukers browser, kontra tradisjonelle nettjtenester der en sentral applikasjonserver generer HTML som blir vist i browseren.
En utfordring med SPAer er at de ikke klarer å beskytte klient-hemmeligheten (evt. virksomhetssertifikatets privatnøkkel) siden hele klienten lever i brukers nettleser. SPAer er altså det som i Oauth2-verdenen kalles public klienter. For slike klienter var det tidligere anbefalt å bruke implicit flow, men de nyeste anbefalingen går på å bruke code flow sammen med PKCE og state.
Merk også at den metoden for “silent renewal” ikke støttes av ID-porten. Denne metoden er også på vei “ut”, da de store browser-aktørene er i ferd med å sperre tilgang til 3djparts-cookies.
Anbefalinger / krav til bruk av SPAer
Trusselbildet er forskjellig ved bruk av SPA kontra tjenester som bruker ordinær autorisasjonskodeflyt. Siden access_token blir eksporert ut i brukers browser, er det øka risiko for at token lettere kan komme på avveie eller byttes ut/manipuleres.
Tjenesteeiere må:
-
Dersom SPA kun skal aksessere egne API (1st party API), bør man vurdere en backend-for-frontend (BFF) arkitektur, dvs. etablere en tynn API-gateway-komponent som operer som oauth2-klient og omsetter ID-portens id_token til egen sesjon (egne cookies) mellom BFF og SPA.
-
APIer som blir sikret av ID-portens access_token direkte, må bruke egne scopes og ikke bare
openid profile(ellers så kan alle gyldige ID-porten-innlogginger til alle andre tjenester også brukes mot ditt API) -
APIer som blir sikret av ID-portens access_token direkte bør bruke audience-begrensa tokens, der
aud-verdien settes lik URL til API-endepunktet
Forøvrig anbefaler vi å lese de siste anbefalingene fra IETF og følge anbefalingene i denne. Dette bør være del av egen isikovurdering av de dataene som blir eksport av APIet og vurdere om de sikringsmekanismer som ovennevte tilbyr gir tilstrekkelig beskyttelse.
Oppsett i selvbetjing
SPA-er som bruker ID-portens access_tokens som sikringsmekanisme mot eget API, må opprettast som integration_type=API_KLIENT i Sjølvbetjeningsløsninga. Då får ein mogelegheit til å sjølv styre levetid på autorisasjon, access_token og refresh_token. Dei må også opprettast som `application-type=web”
Flyt
I praksis er flyten den samme som ordinær autorisasjonskodeflyt, men der:
- Klienten må registreres med klient-autentiseringsmetode
nonei ID-porten (se klientregistrering) (dersom ikke BFF-mønster) - Bruk av PKCE er påkrevd
- Bruk av
state-claimet i autorisasjonsforespørsel er påkrevd