Autentisering og API
I Sikt utvikler vi produktene våre med API-first, og våre frontender, brukerflater og app-er bruker API-ene på samme måte som eksterne partnere ville gjort når de kobler seg til API-ene våre. Feide tilbyr både sikker autentisering og identfisering av sluttbrukere, og autentisering og autorisasjon mellom frontend og våre API-er. På disse sidene vil du finne enkel hjelp til å komme i gang med bruk av Feide for autentisering og tilgangsstyring til dine frontends og dine API-er.
I konfigurasjon av din tjeneste vil du ha behov for enten:
- OpenID Connect issuer:
https://auth.dataporten.no, hvis klienten din støtter auto discovery.
eller du har behov for å konfigurere mer detaljer, med informasjon som er tilgjengelig via auto discovery endepunktet:
Velg applikasjonsarkitekturen under som passer best med din applikasjon for å finne mer egnet dokumentasjon for bruk av Feide.
1: SPA Frontend til API
Dersom du har en SPA frontend, så kan du gjøre autentisering direkte mot Feide fra frontend. Du vil da ha en såkalt «public client», hvor klienten din ikke er i stand til å oppbevare en hemmelighet (client secret). Applikasjonen konfigureres dermed kun med client_id, og med korrekt redirect_uri.
Du vil måtte lagre token i nettleseren i session storage aller local storage. Vær ekstra bevisst på risikoen ved at token blir tilgjengelig ved XSS angrep.
Vær oppmerksom på at du bør konfigurere redirect_uri for både utvikling på localhost, staging og produksjonsmiljø. Konfigurasjon av redirect_uri, og tilgang til client_id skjer i Feide kundeportal.
Bruk klientbiblioteket oauth4webapi for å håndtere autentisering på klientside.
npm i oauth4webapi --save
Se punkt 4 eller 5 for hvordan du kan konfigurere backend / API.
2: SSR Frontend til API
Dersom du har en SSR (server side rendring) frontend, f.eks. ved bruk av Next.js, så er det naturlig at autentisering skjer direkte mot Feide fra Next.js serverside. Da vil du kunne ha en «confidential client», hvor klienten har client_secret sikkert lagret på serversiden. Token vil det også være naturlig at beholdes kun på serverside, og at API kall går via server, hvor token legges til API forespørselen. Den aktive brukerseksjonen, vil håndteres av Next.js hvor en lokal sesjons cookie vil etablere tilstand og håndtere den lokale brukersesjonen mot klienten.
Vær oppmerksom på at du bør konfigurere redirect_uri for både utvikling på localhost, staging og produksjonsmiljø. Konfigurasjon av redirect_uri, og tilgang til client_id skjer i Feide kundeportal.
Se punkt 4 eller 5 for hvordan du kan konfigurere backend / API.
3; Tradisjonell web applikasjon
Dersom applikasjonen din kun har behov for å beskytte innhold bak en mur med Feide-autentisering, og ikke har behov for token for å kunne kalle API-er, så kan du benytte en autentiseringsproxy. Det finnes mange ulike programvarer som kan settes opp til dette, som f.eks Dex og NGINX. Men Platon har innebygget støtte for autentiseringproxy i PaaS, som er den aller enkleste løsningen:
4: Autorisasjon av API-er med autentisering mellomvare
API settes opp til å validere JWT utstedt fra Feide i henhold til Feides spesifkasjon og med konfigurert trust til Feide som JWT utsteder. Token fra Feide enkodes og signeres som JWT, og er ment brukt som HTTP Bearer tokens mot API-et, hvor API-et er markert som audience (aud) i JWT.
Dette kan gjøres i koden, men de fleste programmeringsspråk har ferdige biblioteker for å validere JWT. Vi vil komme med eksempler etterhvert.
Mer om innholdet i JWT, og validering av JWT token
5: Autorisasjon av API-er med API Gateway
API settes opp til å validere JWT utstedt fra Feide i henhold til Feides spesifkasjon og med konfigurert trust til Feide som JWT utsteder. Token fra Feide enkodes og signeres som JWT, og er ment brukt som HTTP Bearer tokens mot API-et, hvor API-et er markert som audience (aud) i JWT.
Sikt tilbyr somendel av IntArk produktet Gravitee som kan benyttes som en API gatekeeper. Vi har også tilgang til AWS API Gateway via Platon.