JWT Claims i OpenID Connect: exempel från verkligheten

Av Natalia Moskaleva den 22 januari 2026

4 min lästid

Dator på ett bord med kodning

OpenID Connect (OIDC) är en allmänt vedertagen standard för användarautentisering i moderna webb- och mobilapplikationer. En av de viktigaste funktionerna är användningen av anspråk, som är information om den autentiserade användaren som utfärdas av identitetsleverantören i form av en JSON Web Token (JWT). Genom att bädda in anspråk i JWT kan identitetsleverantörer kommunicera användarens detaljer på ett standardiserat och säkert sätt.

I den här artikeln kommer vi att täcka:

Vad JWT-anspråk är
Hur de utfärdas av identitetsleverantören
Vad som exakt händer när en användare loggar in i en webbapplikation med hjälp av ett nationellt eID.

Vi använder det danska MitID som ett exempel, men samma principer gäller för alla eID:n som stöds av Idura Verify.

JSON-webbtokens och anspråk

JWTs används ofta för att överföra autentiserings- och auktoriseringsinformation mellan parter i form av ett JSON-objekt.

En JWT består av tre delar:

Header, som innehåller allmän information om token.
Payload, som innehåller påståenden som ger den faktiska informationen om användaren som loggade in, till exempel deras identitet, roll eller behörigheter inom systemet.
Signatur, som identifierar utgivaren av token och säkerställer att token inte har manipulerats under överföringen.

Här är ett exempel på påståenden som kan ingå i en JWT:

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

I det här exemplet innehåller JWT:n fem påståenden:

sub: ämnet för token, som i det här fallet är en användares unika identifierare. "sub" är ett standardanspråk som representerar den enhet som token utfärdas till (vanligtvis en användare, en enhet eller en applikation).
name: användarens namn.
birthdate: användarensfödelsedatum .
iat: när token utfärdades (i Unix-tid).
exp: när token kommer att löpa ut (i Unix-tid).

Varje anspråk har en unik nyckel ("sub", "name") och ett motsvarande värde ("1234567890", "Ditlev Von Testesen"). Dessa anspråk ingår i JWT-token, som sedan kodas och signeras.

Du kan se exakt hur detta fungerar och försöka skapa din egen JWT-token på jwt.io.

I en riktig webbapplikation hanteras processen med att skapa och koda en JWT-token av OpenID Provider, och valideringen och avkodningen sker vanligtvis på serversidan och görs av webbapplikationens backend-kod.

Logga in med ett eID

Inom ramen för OIDC kan nationella eID:n fungera som identitetskällor via OpenID Providers.

Så när en användare loggar in i en webbapplikation med ett eID är det OpenID Providern som utfärdar en JWT som innehåller en uppsättning påståenden om användaren, som sedan returneras till webbapplikationen.

Låt oss ta ett exempel på en användare som loggar in i en webbapplikation med ett danskt MitID. Genom att logga in med MitID får användaren tillgång till applikationen eftersom OpenID Connect gör det möjligt att logga in i flera applikationer med en enda uppsättning autentiseringsuppgifter. För många människor är detta nu en välbekant process som de föredrar framför en vanlig kombination av användarnamn och lösenord.

Applikationen får i sin tur tillgång till användarens data i form av JWT-anspråk.

För att möjliggöra detta flöde använder applikationen Idura Verify för att presentera användaren med ett alternativ att logga in med MitID. Om användaren väljer detta alternativ kommer de att se den välbekanta skärmen och ange sina referenser.

När användaren har autentiserats genererar Idura Verify en JWT-token som innehåller information om användaren. Tokenet signeras sedan och returneras till applikationen. Vid den här tidpunkten har applikationen användarens information.

Nedan visas ett exempel på JWT-krav som returneras till applikationen efter att användaren har loggat in med danskt 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",
"namn": "Ditlev Von Testesen",
"land": "DK"
}

Detta exempel innehåller följande påståenden:

identityscheme: hänvisar till den e-legitimation som används för autentisering (MitID i vårt fall).
sub: användarens unika eID-identifierare, som i det tidigare exemplet.
namnidentifierare: "sub" men i det äldre formatet.
uuid: en beständig pseudonym som myndigheter använder för att identifiera en person. För medborgare identifierar den den fysiska personen. För anställda är det den juridiska personen.
cprNumberIdentifier: CPR-nummer (den danska versionen av SSN).

Det är också möjligt att lägga till adressinformation för användare som loggar in med MitID.

När applikationen tar emot token med anspråk kommer den att verifiera signaturen för att säkerställa att token verkligen utfärdades av den förväntade OpenID Providern och inte har manipulerats. (Läs mer om JWT-validering och dess implementering i vår detaljerade guide med kodprover). Applikationen kan nu också extrahera information om användaren från anspråken. (Detta kan användas för att t.ex. skapa en personlig användarupplevelse).

Idura Verify som OpenID-provider

Idura Verify är en OpenID Provider.

Det innebär att vi har implementerat en uppsättning standarder och protokoll samt byggt programvara för att autentisera användare och tillhandahålla identitetsinformation till andra applikationer och tjänster.

Som OpenID Provider kommer Idura Verify att utfärda JWT-tokens efter att användare loggat in i en webb- eller mobilapplikation med ett av de nationella eID:n som vi stödjer. Som förklarat kommer dessa JWT-tokens att innehålla information som användarens namn, födelsedatum och andra attribut. Varje nationellt eID har en uppsättning fördefinierade anspråk som skiljer sig något från andra. De JWT-tokens som utfärdas av Idura Verify kan sedan användas av webb- och mobilapplikationer för att verifiera användarens identitet och auktorisera åtkomst till skyddade resurser.

Idura Verify hjälper dig att förenkla hanteringen av användaridentiteter genom att låta dina användare logga in med sitt eget nationella eID via en välbekant och säker process.

eID tillhandahåller också användarens identitet, vilket lägger till ett extra lager av säkerhet i autentiseringsprocessen.

Slutligen, genom att använda Idura Verify isoleras din applikation från framtida förändringar i varje eID-implementering. Du behöver inte oroa dig för hur de faktiska identitetstjänsterna utvecklas över tid eller hur de är säkrade.