JWT-påstander i OpenID Connect: Eksempel fra virkeligheten

OpenID Connect (OIDC) er en utbredt standard for brukerautentisering i moderne nett- og mobilapplikasjoner. En av de viktigste funksjonene er bruken av claims, som er informasjon om den autentiserte brukeren utstedt av identitetsleverandøren i form av et JSON Web Token (JWT). Ved å legge inn claims i JWT kan identitetsleverandørene kommunisere brukerens detaljer på en standardisert og sikker måte.

I denne artikkelen går vi gjennom dette:

• Hva JWT-krav er
• Hvordan de utstedes av identitetsleverandøren
• Hva som skjer når en bruker logger seg på en webapplikasjon ved hjelp av en nasjonal eID.

Vi bruker den danske MitID-en som eksempel, men de samme prinsippene gjelder for alle eID-er som støttes av Idura Verify.

JSON Web Tokens og krav

JWT-er brukes ofte til å overføre autentiserings- og autorisasjonsinformasjon mellom parter i form av et JSON-objekt.

En JWT består av tre deler:

• Header, som inneholder generell informasjon om tokenet.
• Payload, som inneholder påstander som gir den faktiske informasjonen om brukeren som logget inn, for eksempel identitet, rolle eller tillatelser i systemet.
• Signatur, som identifiserer utstederen av tokenet og sikrer at tokenet ikke har blitt tuklet med under overføringen.

Her er et eksempel på påstander som kan inngå i en JWT:

{
"sub": "1234567890",
"name": "Ditlev Von Testesen",
"email": "ditlev.von.testesen@example.com",
"iat": 1678382880,
"exp": 1678382885
}

I dette eksempelet inneholder JWT-en fem krav:

• sub: emnet for tokenet, som i dette tilfellet er en brukers unike identifikator. "sub" er et standardkrav som representerer enheten som tokenet er utstedt til (vanligvis en bruker, en enhet eller et program).
• name: navnet på brukeren.
• birthdate: brukerens fødselsdato .
• iat: når tokenet ble utstedt (i Unix-tid).
• exp: når tokenet utløper (i Unix-tid).

Hvert krav har en unik nøkkel ("sub", "name") og en tilsvarende verdi ("1234567890", "Ditlev Von Testesen"). Disse påstandene inngår i JWT-tokenet, som deretter kodes og signeres.

Du kan se nøyaktig hvordan dette fungerer og prøve å opprette ditt eget JWT-token på jwt.io.

I en ekte webapplikasjon håndteres prosessen med å opprette og kode et JWT-token av OpenID Provider, mens valideringen og dekodingen vanligvis skjer på serversiden og utføres av webapplikasjonens backend-kode.

Innlogging med en eID

I OIDC-sammenheng kan nasjonale eID-er fungere som identitetskilder via OpenID Providers.

Når en bruker logger seg på en webapplikasjon ved hjelp av en eID, er det OpenID Provideren som utsteder en JWT som inneholder et sett med påstander om brukeren, som deretter returneres til webapplikasjonen.

La oss ta et eksempel med en bruker som logger seg på en webapplikasjon med en dansk MitID. Ved å logge inn med MitID får brukeren tilgang til applikasjonen, siden OpenID Connect gjør det mulig å logge inn på flere applikasjoner ved hjelp av ett enkelt sett med legitimasjon. For mange er dette nå en velkjent prosess som de foretrekker fremfor en standard kombinasjon av brukernavn og passord.

Applikasjonen får i sin tur tilgang til brukerens data i form av JWT-krav.

For å muliggjøre denne flyten bruker applikasjonen Idura Verify til å gi brukeren muligheten til å logge inn med MitID. Hvis brukeren velger dette alternativet, får han eller hun se det velkjente skjermbildet og skrive inn legitimasjonen sin.

Når brukeren er autentisert, genererer Idura Verify et JWT-token som inneholder informasjon om brukeren. Tokenet signeres deretter og returneres til applikasjonen. På dette tidspunktet har applikasjonen brukerens informasjon.

Nedenfor er et eksempel på JWT-krav som returneres til applikasjonen etter at brukeren har logget inn med dansk MitID.

{
"identityscheme": "dkmitid",
"nameidentifier": "0f9960a0d28d4353a3e2ea07f8ffa185",
"sub": "{0f9960a0-d28d-4353-a3e2-ea07f8ffa185}",
"uuid": "74ffcd31-fbaf-4c33-bdac-169f25c1e416",
"cprNumberIdentifier": "2101270087",
"birthdate": "1927-01-21",
"age": "93",
"name": "Ditlev Von Testesen",
"land": "DK"
}

Dette eksempelet inneholder følgende påstander:

• identityscheme: refererer til eID-en som brukes til autentisering (MitID i vårt tilfelle).
• sub: brukerens unike eID-identifikator, som i det tidligere eksempelet.
• nameidentifier: "sub", men i det gamle formatet.
• uuid: et vedvarende pseudonym som myndighetene bruker for å identifisere personen. For borgere identifiserer det den fysiske personen. For ansatte er det den juridiske personen.
• cprNumberIdentifier: CPR-nummer (den danske versjonen av SSN).

Det er også mulig å legge til adresseinformasjon for brukere som logger inn med MitID.

Når applikasjonen mottar tokenet med krav, vil den verifisere signaturen for å sikre at tokenet faktisk ble utstedt av den forventede OpenID-leverandøren og ikke har blitt tuklet med. (Les mer om JWT-validering og implementeringen av denne i vår detaljerte veiledning med kodeeksempler). Programmet kan nå også hente ut informasjon om brukeren fra kravene. (Dette kan for eksempel brukes til å skape en personlig brukeropplevelse).

Idura Verify som OpenID-leverandør

Idura Verify er en OpenID Provider.

Det betyr at vi har implementert et sett med standarder og protokoller og bygget programvare for å autentisere brukere og levere identitetsinformasjon til andre applikasjoner og tjenester.

Som OpenID Provider vil Idura Verify utstede JWT-tokens når brukere logger seg på en nett- eller mobilapplikasjon med en av de nasjonale eID-ene vi støtter. Som forklart vil disse JWT-ene inneholde informasjon som brukerens navn, fødselsdato og andre attributter. Hver nasjonale eID har et sett med forhåndsdefinerte krav som er litt forskjellige fra andre. JWT-tokens utstedt av Idura Verify kan deretter brukes av nett- og mobilapplikasjoner for å verifisere brukerens identitet og autorisere tilgang til beskyttede ressurser.

Idura Verify hjelper deg med å forenkle prosessen med å administrere brukeridentiteter ved å la brukerne logge inn med sin egen nasjonale eID ved hjelp av en kjent og sikker prosess.

eID-en gir også brukerens identitet, noe som gir et ekstra sikkerhetslag i autentiseringsprosessen.

Til slutt isolerer Idura Verify applikasjonen din fra eventuelle fremtidige endringer i hver eID-implementering. Du trenger ikke å bekymre deg for hvordan de faktiske identitetstjenestene utvikler seg over tid, eller hvordan de sikres.

Er du klar til å integrere Idura Verify i applikasjonen din?

• Registrer deg for en gratis utviklingskonto med ubegrenset antall testpålogginger
• Les vår tekniske dokumentasjon
• Kontakt en Idura-ekspert