JSON Web Token

**JSON Web Token** (**JWT**, hääldatakse /dʒɒt/, või "džot") on väljapakutud internetistandard andmete loomiseks koos digitaalallkirja ja/või krüpteerimisega, mis sisaldab JSON-i, mis omakorda seab ette teatud hulga väiteid. Tõendid allkirjastatakse avaliku ja salajase võtmega.

Näiteks võib server luua tõendi, millel on väide "sisse logitud administraatorina" ning anda selle kliendile. Klient saab seejärel tõendit kasutada tõestamaks, et on sisse logitud administraatorina. Tõendeid saab allkirjastada ühe osapoole salajase võtmega (tavaliselt serveri omaga) nii, et sama osapool saab hiljem kontrollida tõendi õigsust. Kui teisel osapoolel on sobival ja usaldusväärsel viisil olemas vastav avalik võti, on ka teine osapool võimeline kontrollima tõendi õigsust. Tõendid on loodud kompaktselt, URL-i jaoks turvaliselt ning kasutamiseks eelkõige veebibrauseri ühekordse sisselogimise (*single sign-on,* SSO) kontekstis.

JWT tugineb teistele JSON-il põhinevatele standarditele: JSON Web Signature ja JSON Web Encryption.

JWT tõendid on Eestis kasutusel riigi autentimisteenuses (TARA), millega on võimalik e-teenusestes autentida kasutades ID-kaarti, mobiil-ID-d või smart-ID-d.

## Struktuur

Kõik kolm osa kodeeritakse seejärel uuesti kasutades Base64url kodeeringut, ning ühendatakse kokku kasutades eraldajana punkte JWT tõendi loomiseks:

```javascript
const token = base64urlEncoding(header) + '.' + base64urlEncoding(payload) + '.' + base64urlEncoding(signature)
```

Saadud JWT tõend ja "secretkey" ehk salajane võti loovad tõendi:

Saadud tõendi saab hõlpsasti HTML-i ja HTTP-sse edasi anda.

## Kasutamine
Kui kasutaja logib edukalt sisse luuakse ja tagastatakse JWT tõend, mis seejärel salvestatakse lokaalselt (tavaliselt lokaalsesse- või sessioonimällu, kuid kasutada saab ka küpsiseid). Võrdluseks luuakse traditsiooniselt sessioon serveris ning kasutajale tagastatakse vaid küpsis, millega kasutajat hiljem ära tunda. Kui tegemist on ilma kasutajata protsessiga võib klient autentida ka otse luues ja ise allkirjastades JWT tõend koos salajase võtmega ja anda see edasi OAuth-i toetavale teenusele:


```mime
POST /oauth2/token?
Content-type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=eyJhb...
```


Kui klient annab edasi kehtiva JWT tõendi, loob server uue ligipääsutõendi `access_token`, millega saab sooritada kutseid teenusele ja neid kliendile tagasi saata.


```json
{
 "access_token": "eyJhb...",
 "token_type": "Bearer",
 "expires_in": 3600
}
```


Kui klient soovib juurdepääsu kaitstud marsruudile või ressursile, peaks ta saatma JWT tõendi `Authorization` päisesse, kasutades `Bearer` skeemi.
 Authorization: Bearer eyJhbGci *... &#x3C; jne &#x3E; ...* yu5CSpyHI

See on olekuta autentimismehhanism, kuna kasutaja olekut ei salvestata kunagi serveri mällu. Serveris kaitstud marsruudid otsivad päises kehtivat JWT tõendit ning kui see on olemas, antakse kliendile ligipääs kaitstud ressurssidele. Kuna JWT tõendid on iseseisvad, on kõik vajalikud andmed olemas ning andmebaasi ei pea tegema mitmeid päringuid.

## Standardväljad

## Haavatavused
JWT tõendid võivad sisaldada sessiooni olekut, kuid kui projekti nõuded lubavad sessiooni kehtetuks tunnistamist enne JWT aegumist, ei saa teenused enam usaldada tõendi seatud väiteid tõendit kasutades. Sessiooni valideerimiseks peab seetõttu tõendi väiteid kontrollima andmebaasi abil. See tähendab aga, et tõend ei ole enam olekuta, mistõttu ei ole JWT kasutamisel enam eelist.

Turvakonsultant Tim McLean leidis mõnes JWT teegis haavatavused, mis kasutasid `alg` välja ebakorrektselt tõendite õigsuse kontrollimisel, tüüpiliselt tehes seda lubades `alg=none` tõendit. Kuigi nimetatud teekides on need haavatavused tänaseks prandatud, soovitab McLean `alg` väljast täielikult loobuda, et vältida tulevikus sarnaseid probleeme. Uusi `alg=none` haavatavusi leitakse aga siiamaani.

## Viited