JSON Web Token (JWT) Claim Çeşitleri

Claim Nedir
Claim bilgisi, payload yani 2. kısım içinde taşınır.  Açıklaması şöyle.

Claims are statements about the entity, which is typically a user, and any additional data. There are three types of claims:

- Registered claims: a set of recommended claims defined in the RFC 7519 spec. Some examples are iss, exp, and aud.

- Public claims: user-defined claims that can be defined by the token users, but should conform to naming conventions to avoid collision (should be defined in the IANA JSON Web Token Registry or be defined as a URI that contains a collision resistant namespace) because they are in the public namespace.

- Private claims: arbitrary custom claims that are used to share information between parties that agree on them (and don’t have to worry about name collision because they’re private).

Claim için zaman damgası olabilir. Açıklaması şöyle.

have a payload that contains the claim(s) (equipped with a timestamp)

1. Registered veya Reserved Claim Tipleri
Açıklaması şöyle.

There are the claims which are registered in IANA "JSON Web Token Claims" registry. These claims are not mandatory to use or to be implement in all cases, rather they are registered to provide a starting point in for a set of useful, interoperable claims.

Örnek
Açıklaması şöyle.

iss is who issued the token. This is a registered claim.
exp is when the token expired. Also a registered claim.
sub is the subject. This is usually a user identifier. Also a registered claim.
scope is a custom, private claim that is commonly used with OAuth 2.0.

Açıklaması şöyle.

1. iss (issuer): The "iss" (issuer) claim identifies the principal that issued the JWT. The processing of this claim is generally application specific. The "iss" value is a case-sensitive string containing a String or URI value. Use of this claim is OPTIONAL.

2. sub (subject): This claim represents the subject of JWT (the user). The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique. The processing of this claim is generally application specific. The "sub" value is a case-sensitive string containing a String or URI value. Use of this claim is OPTIONAL.

3. aud (audience): This claim represents the intended recipient of the JWT. If the party processing the claim does not identify itself with a value in the "aud" claim when this claim is present, then the JWT MUST be rejected. In the general case, the "aud" value is an array of case- sensitive strings, each containing a String or URI value. Use of this claim is OPTIONAL.

4. exp (expiration): The "exp" (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing. The processing of the "exp" claim requires that the current date/time MUST be before the expiration date/time listed in the "exp" claim. Usually the value is kept short preferably in seconds. Its value MUST be a number containing a NumericDate value. Use of this claim is OPTIONAL.

5. nbf (not before): The "nbf" (not before) claim identifies the time before which the JWT MUST NOT be accepted for processing. The processing of the "nbf" claim requires that the current date/time MUST be after or equal to the not-before date/time listed in the "nbf" claim. Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew. Its value MUST be a number containing a NumericDate value. Use of this claim is OPTIONAL.

6. iat (issued at): The "iat" (issued at) claim identifies the time at which the JWT was issued. This claim can be used to determine the age of the JWT. Its value MUST be a number containing a NumericDate value. Use of this claim is OPTIONAL.

7. jti (JWT ID): The "jti" (JWT ID) claim provides a unique identifier for the JWT. The identifier value MUST be assigned in a manner that ensures that there is a negligible probability that the same value will be accidentally assigned to a different data object; if the application uses multiple issuers, collisions MUST be prevented among values produced by different issuers as well. The "jti" claim can be used to prevent the JWT from being replayed. The "jti" value is a case-sensitive string. Use of this claim is OPTIONAL.

2. Public Claim Tipleri
Kendi isteğimize göre hazırlanır. Açıklaması şöyle.

These claim names can be defined at will by those using JWTs. However, in order to prevent collisions, any new Claim Name should either be registered in the IANA "JSON Web Token Claims" registry or be a Public Name: a value that contains a Collision-Resistant Name.

In each case, the definer of the name or value needs to take reasonable precautions to make sure they are in control of the part of the namespace they use to define the Claim Name.

3. Private Claim Tipleri
Sistemler arasında gidip gelmesi için hazırlanır. Açıklaması şöyle.

This could be thought of as analogous to creating private custom claims to share information specific to your application. These could be any names that are not Registered Claims Names or Public Claims Names. Unlike Public Claim Names, Private Claim Names are subject to collision and should be used with caution.

scope Claim Nedir

Hangi kaynağa izin verildiğini belirtir. Bu kaynağa ne tür izin verildiği de belirtilir. Örneğin "read:contacts" gibi. Açıklaması şöyle. 

The scope claim is commonly used to provide authorization information. For example, letting the application know what part of the application the user is authorized to access. This, of course, does not relieve the server of its duty to perform its own authorization checks. A general principle of web application security is redundancy. The client app provides one checkpoint, the server another.

Açıklaması şöyle.  Scope sayesinde kaynağın her türlü bilgisine değil de sadece belirtilen kısmına erişim verilir.

Scopes define the permissions that determine what data of a user an application can access. For instance, if a 3rd party application wants to recommend movies to a user, it requires access to the movies the user has watched (e.g., “watched_movies”). This is where scopes come into play. This 3rd party application can access user information only to the extent the user has permitted.

This process ensures the safety of user information. Instead of accessing all of a user’s data, the 3rd party can access user data within the permissions granted.

Authorities Nedir

Açıklaması şöyle.  

Authorities represent the actions (that one has permission for) a user can perform within an application. Compared to scopes, they are usually more detailed and specify which actions can be carried out within a specific application.

For example, a user can add a movie to their favorites (e.g., “user”). The permissions to perform this action are called authorities.

SpringSecurity JWT token'ı parse ederken “scope” veya “scp” satırlarını okur ve bunları bir string listesine çevirir. Listedeki her eleman için ‘SCOPE_’ ön ekini ekler ve SimpleGrantedAuthority nesnesi yaratır. 

JSON Web Token (JWT) Nerede Saklanır

Giriş

Açıklaması şöyle.

We have three options available for storing the data on the client side and each of those has its own advantages and disadvantages. And the options are:

1. Cookie

2. Local Storage

3. Session Storage

Cookie İçinde Saklamak

Bunun için bir ön koşul var. Açıklaması şöyle. Yani JWT 4K'dan küçük olmalı.

The purpose of JWTs is to be stateless, right? Cookies are capped out at 4k, which means the JWT needs to be < 4k for this to work.

Cookie içinde SameSite=strict, HttpOnly gibi bayraklarla birlikte saklamak.
- SameSite=strict CSRF saldırısına karşı korur.
- HttpOnly ise XSS saldırısına karşı korur. HttpOnly tarayıcıya enjekte edilen javascript kodlarının token'a erişip başka yere göndermesini engeller

Açıklaması şöyle

... using cookies alone is not the solution but extra steps to prevent XSS attack must be taken by enabling “HTTP-only” parameter in cookies which basically do not allow any third party JavaScript code to read your cookies and enabling the secure flag which transports your cookies only through HTTPS.

Local Storage İçinde Saklamak

Bu önerilmiyor. Açıklaması şöyle.

Local storage wasn’t designed to be used as a secure storage mechanism in a browser. It was designed to be a simple string only key/value store that developers could use to build slightly more complex single-page apps.

— Randall Degges

When you store sensitive information in local storage, you’re essentially using the most dangerous thing in the world(javascript) to store your most sensitive information in the worst vault ever created.

— Randall Degges

Session Storage İçinde Saklamak

Açıklaması şöyle.

The downside is that you need to manage a cache on the API side, but this is easily doable.

If you’re using JWTs anyway, you STILL NEED to have centralized sessions that handles revocation, right?.

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