ID-porten for innlogging til SPA
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.
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å:
- Lese de siste anbefalingene fra IETF og følge anbefalingene i denne
- Gjennomføre en risikovurdering av de dataene som blir eksport av APIet og vurdere om de sikringsmekanismer som ovennevte tilbyr,gir tilstrekkelig beskyttelse.
Flyt
I praksis er flyten den samme som ordinær autorisasjonskodeflyt, men der:
- Klienten må registreres som “public” klient i ID-porten (se klientregistrering)
- Det registreres ingen client-secret
- Bruk av PKCE er påkrevd
- Bruk av
state-claimet i autorisasjonsforespørsel er påkrevd