Jwt Authentication

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.

JWT Advantages

  1. It works Session Stateless. Stateless means that the server does not store any state about the client session on the server side. In other words, the information and its expiration date are kept neither on the server nor on the client side. All information is in the token.
  2. Works Portable. It can be easily used by both your web application and mobile applications.
  3. It uses JSON format.
  4. The verification process is faster than other authentication methods. A connection to the database is not established for the verification process.
  5. There is no need to use cookies. Thus, it provides an advantage for mobile based applications.

Click the following link for Jwt disadvantages.

Security Measures Available in Olobase for JWT

We can talk about a series of measures used in Olobase to eliminate the disadvantages described above.

  • EdDSA Algorithm
  • Token Validity and Refresh
  • Token Encryption
  • Session Lifetime
  • User Browser and IP Validation

JWT Structure

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-aSPcrQHc

Header

This 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.

Payload (Data)

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.

Registered Claims

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.

Public Claims

These are optional, openly published claims.

Private 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.

Signature

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
)

JWT Verification

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.

Configuration

In this section, you will need to take the following steps before signing in to your application:

  • Generating Jwt Keys
  • Authorization configuration for Local Environment
  • Control of SQL Table
  • Configuration of Token Renewal Times
  • Login Test
  • JwtAuthenticationMiddleware

Generating JWT Keys

  1. Generate random 16 character srtring for encryption.iv key. You can use online random.org to generate.
  2. Generate a encryption.secret_key for token encryption:
echo base64_encode(openssl_random_pseudo_bytes(32)); // ewQrCBs/3Mp7RKgtbjd4jjdOJLY8uyENcmKcssQnvWE=
  1. The jwt encoder uses two public and private keys, private_key when signing tokens and public_key when reading tokens. Perform the following operation in any php file.
$keyPair = sodium_crypto_sign_keypair();
$publicKey = base64_encode(sodium_crypto_sign_publickey($keyPair));
$privateKey = base64_encode(sodium_crypto_sign_secretkey($keyPair));

echo $publicKey."\n";  // W9JHddARm1iwrIV+DhlQ1t0vGxWwgwVTHyHpjq6n4L8=
echo $privateKey."\n"; // KXgCiGnLLkYI/j/uGOgmSn5P9lATSZcd/p86azEgwW1b0kd10BGbWLCshX4OGVDW3S8bFbCDBVMfIemOrqfgvw==
This documents is available for subscribers only

Get Full Accesss