Autentisering til SPA'er

Ved innlogging til en SPA, er det anbefalt å bruke code flow med PKCE og state

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 none i 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

Example

Sjå eksempel med React-klient