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 ofte brukte 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 som ødelegger for silent renewal.
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.
-
Dersom man heller velger at SPAens backend-APIer blir sikret av ID-portens access_token direkte, må kunden opprette et egen oauth2-scope for formålet og ikke bare bruke
openid profile(ellers så kan alle gyldige ID-porten-innlogginger til alle andre tjenester også brukes mot ditt API) -
Man bør bruke kortlevede access_token, og relativt kort_levede
Forøvrig anbefaler vi å lese de siste anbefalingene fra IETF og følge anbefalingene i denne. Dette bør være del av egen risikovurdering av de dataene som blir eksport av APIet og vurdere om de sikringsmekanismer som ovennevte tilbyr gir tilstrekkelig beskyttelse.
Oppsett i selvbetjening
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.
Fram til release 21-06 må klienten opprettast som application-type=web (og client_secret må anses som kjent) dersom den skal få refresh_token.
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