JWT (JSON Web Tokens) is an RFC7519 industry standard. JWT can be used in many issues such as user authentication, web service security, information security. JWT is a very popular and preferred method.
A JWT authentication method works Session Stateless. This means that it is stateless and the server does not store any state about the client session on the server side. In other words, user information and session expiration date are kept neither on the server nor on the client side. All information is in the token.
Click the following link for Jwt disadvantages.
We can talk about a series of measures used in Olobase to eliminate the disadvantages described above.
A token signed with JWT consists of 3 main parts encoded with Base64. These are Header, Payload and Signature sections. If we pay attention to the token example below, there are 3 fields separated by dots as aaa.bbb.ccc.
Example Token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdGF0dXMiOiJ0ZWJyaWtsZXIhIDopIn0.sTLXY5iAs1IzJJ-8GVP_pMR65qqgCUpbMl-aSPcrQHcThis part to be used in JWT is written in JSON format and consists of 2 fields. These are the token type and the name of the algorithm to be used for signing.
For example:
{
"typ": "JWT",
"alg": "EdDSA"
}Many different algorithms can be used in the algorithm section, such as EdDSA, HS256, HMAC SHA256 or RSA. In the Type section, it says JWT. This part is encoded with Base64 and forms the first part of the token to be created.
This section contains claims. With the data held in this section, the token becomes unique between the client and the server. This retained claim information also provides this uniqueness. There are 3 types of claims in this section.
These are 3-letter long claims pre-reserved by JWT. In other words, you cannot use these set claim names in other claims. Use of this information is not required, but is recommended. Some of these claims are iss (issuer), exp (expiration time), sub (subject), aud (audience) and others. The most used of these is expiration time. For example, if you want your coin information to be invalid after 3 hours, you send this information in the exp field. Requests with the same token after 3 hours will be considered invalid.
These are optional, openly published claims.
These are secret claims used by the parties to convey information between themselves.
An example payload:
{
"sub": "1234567890",
"name": "John Doe",
"email": "[email protected]",
"iat": 1516239022
}This part is encoded with Base64 and forms the second part of the token to be created.
You should not put sensitive data such as user password in the token because JWT tokens are encoded with the base64 function so they can be easily read when captured.
This part is the last part of the coin. Header, payload and secret key (secret) are required to create this part. Data integrity is guaranteed with the signature section. The secret key we use here is used for the algorithm we specified in the Header section. Header and Payload sections are signed with this secret key.
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
your-256-bit-secret
)As we mentioned in the scenario above, the verification process is used by the client to check the authority of the user after the token is received. Whether the token is valid or not is verified with JWT. JWT validation process is quite simple. In the incoming token, Header and Payload are signed with the secret key on our server and the 3rd part is calculated. This generated signature is then compared with the signature received by the client. If the signatures are the same, the token is considered valid and the user is granted access.