JSON Web Token - JWT

Giriş
RFC 7519 ile tanımlı. Açıklaması şöyle.

JWT are self sufficient tokens which are used to share authentication information between different systems. They solve the problem of relying on third parties for validating an authentication token as all the information required to validate the JWT is contained within the token itself. This simplifies the process of on-boarding in a single sign-on system as there is minimal integration required. JWT are also HTTP friendly as they are just BASE-64 strings.

JWT Nedir?
Açıklaması şöyle.

A JWT is an open standard (RFC 7519) for using JSON to transmit information between parties as digitally signed string tokens. They can be signed with the HMAC algorithm or using a public/private key pair using RSA or ECDSA.

To say this another way: JWTs are a JSON token that is a URL-safe, compact, and self-contained string. Typically, they carry information about a user’s verified identity. They are generally encoded and encrypted. They’re quickly becoming a de facto standard for token implementations across the web. URL-safe means that the token string can be used in a URL because all special characters have been encoded as simple alphanumeric characters. JWTs are also considered opaque because the string by itself provides no information without decoding or decryption.

Tokens are often thought of as an authorization mechanism, but they can also be used as a way to securely store and transmit information between a web application and a server, much the same way that session IDs are used.

Opaque Token Nedir?
JWT'nin rakibi Opaque Token ve PASETO

JWS Nedir?
Açıklaması şöyle.

When a JWT is signed, it’s referred to as a JWS. When it’s encrypted, it’s referred to as a JWE.

JWT Token Nerede Saklanır

JWT Token Nerede Saklanır yazısına taşıdım

JWT ve OAuth 2.0 İlişkisi

Token Based Authentication için kullanılan iki tane popüler yöntem var. Açıklaması şöyle.

OAuth 2.0 (RFC 6749 and RFC 6750).
JWT (RFC 7519).

Bazı OAuth gerçekleştirimleri altta JWT kullanıyor. Açıklaması şöyle.

Many OAuth 2.0 implementations are using JWTs for their access tokens. It should be stated that the OAuth 2.0 and JWT specifications are completely separate from each other and don’t have any dependencies on each other. Using JWTs as the token mechanism for OAuth 2.0 affords a lot of benefits ...

Whatever JWT implementation you use, you’ll have to store your nifty web token somewhere. Two popular options are cookies and HTML5 web storage. Both options have benefits and potential risks; ...

Nasıl Çalışır

Şeklen şöyle

JWT İçin POST İsteği

Basit bir application/json formatında HTTP Post isteği gönderilir. İstek şöyledir.

{
  "username":"myuser",
  "password": "mypassword"
}

Refresh Token
JWT'de Refresh Token yoktur. Açıklaması şöyle.

No “refresh” token is specified by the standard implementation. On expiry, the user will therefore have to re-authenticate.

Açıklaması şöyle.

If a user account needs to be blocked or deactivated, the application will have to wait for the token to expire for the lockout to be fully effective.

JWT 3 Kısımdan Oluşur
Bu nokta ile ayrılan 3 string'den oluşur. Açıklaması şöyle.

Header.Payload.Signature

Signature için kullanılan algoritma burada yazılıdır. Signature için genellikle HMAC-SHA256 kullanılır. Şeklen şöyle

1. Header
Temel olarak iki tane alandan oluşur. Açıklaması şöyle.

Though there is no limitation on what you can have in header, as long as there is mutual agreement between the parties involved. But usually the header consists of two parts.

typ: represents what is the type of the token and this will be JWT
alg: it denotes the algorithm used for signing this token, such as HMAC, RSA, SHA

Açıklaması şöyle.

The header is simply Base64Url encoded. It tells us the type of token and the hashing algorithms used, typically HMAC SHA256 or RSA.

Signature için kullanılan algoritma burada yazılıdır. Signature için genellikle HMAC-SHA256 kullanılır. JWT algoritmama tanımlanmamasın da izin veriyor. Açıklaması şöyle

JWTs aim to support a wide range of cryptographic algorithms, including no cryptography at all! Think about that for a minute; one of the core features of a JWT security token is the ability to disable said security.

Some of the most common JWT exploits we see are authentication bypass attacks, where an attacker is able to edit or forge a JWT and disable the token’s cryptographic verification.

Örnek
Header'ı açarsak şöyle bir şey görürüz.

{
  "typ": "JWT",
  "alg": "HS256"
}

Örnek
Sunucu ayarlarında şöyle yaparız.

JWT_ALGORITHM = "HS256"

2. Payload
Claim ve zaman damgası (timesptamp) bilgisini taşır. Açıklaması şöyle

There are two kinds of JWTs:

JWS: Payload is in "plain text" and has a signature to confirm its contents
JWE: The payload is completely encrypted.
These have slightly different use-cases. If all you need to do is verify that the data stored in the JWT is correct and has not been tampered with, then a JWS is fine (presuming you implement it properly and verify the signature on all requests). Therefore, you could store the balance in a JWS and later confirm that the reported balance is what you originally stored.

If you also want to keep the data private, then you can use a JWE. The encryption will also guarantee that the data is not modified (again, assuming you properly implement the JWE). Note that the only person who normally has access to the JWT is the end user, so we're talking about keeping it private from them - probably not necessary for your use case

Payload Ne Olursa Olsun Hassas Bilgi İçermemeli
Açıklaması şöyle.

Also, this should not contain any sensitive information about the user, e.g. password, email, etc.

Örnek
Hesap bakiyesini payload içinde tutmak isteyelim. Bu yanlış bir karar. Açıklaması şöyle.

If another transaction was made without updating a JWT, or if an old JWT is presented (aka a replay attack), then you can have a valid JWT that has the incorrect balance. This is very likely even without active attackers. Consider a user who uses more than 1 app. In your hypothetical scenario, what happens if a balance is stored in a JWT in one device, and then the user logs into another device and makes a transaction? The data in the JWT for the first device is now incorrect, even though the JWT itself is valid and has not expired. This is just one of many ways in which valid but incorrect JWTs may happen.

Örnek
Payload'u açarsak şöyle bir şey görürüz.

{
  "iss": "http://trustyapp.com/",
  "exp": 1300819380,
  "sub": "users/8983462",
  "scope": "self api/buy"
}

3. Signature
Algoritma olarak HMAC-SHA256 ve none kullanılabilir. JWT'nin değiştirilmediğini garanti eder. JWT'yi şifrelemez.

İşlem sonucunda elimize nokta karakteri ile ayrılmış şu string geçer.

token= encodeBase64(header)+ '.' +encodeBase64(payload)+ '.'+encodeBase64(signature)

Örnek
Signature şöyledir.

HMACSHA256( 
    base64UrlEncode(header) + "." + 
    base64UrlEncode(payload), 
    secret
)

Sunucu Token'ı İmzalar

Açıklaması şöyle. 

For example, a server could generate a token that has the claim "logged in as admin" and provide that to a client. The client could then use that token to prove that they are logged in as admin. The tokens are signed by the server's key, so the server is able to verify that the token is legitimate.

Açıklaması şöyle.

It’s super important to understand that this signature does not provide confidentiality. This information is publicly visible. The signature guarantees that the token hasn’t been tampered with, but it doesn’t hide the data (a small child can decode Base64 on their uncle’s iPhone 4). A JWT must be encrypted if you want to send sensitive information.

İmza İçin HMAC Kullanılırsa
Açıklaması şöyle.

are signed with a message authentication code (e.g. HMAC-SHA256) (the algorithm is specified in the header of the JWT)

Claim Nedir

Claim Nedir yazısına taşıdım