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.
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.
I praksis er flyten den samme som ordinær autorisasjonskodeflyt, men der:
none i ID-porten (se klientregistrering) (dersom ikke BFF-mønster)state-claimet i autorisasjonsforespørsel er påkrevd© Digitaliseringsdirektoratet