Understanding JSON Web Tokens

Sathya Bandara
Jul 23, 2017 · 5 min read

As you may already know JWT is a popular JSON based format of a security token. So, Lets start from the formal definition of JSON web tokens;

JSON Web Token (JWT) is a compact, URL-safe means of representing
claims to be transferred between two parties.

Simply put a JWT is a JSON based format of a security token which is basically a base64 url-encoded string which is used as a means of transferring
secure content between two applications. They are used to secure request data in Web APIs. These are included in Authorization HTTP headers as part of the bearer authentication scheme. Security protocols like OAuth2 use JWT tokens to secure APIs. OpenID Connect uses JWT tokens to authenticate web applications, but stores the token in a cookie. But they are different from the session cookies which is sent to the user in the request automatically whenever a user logs in.

A JWT token is composed of a header, a payload, and a signature and has the format header.payload.signature

A JWT is represented as the concatenation of the Encoded JWT Header, the JWT Second Part, and the JWT Third Part, in that order, with the parts being separated by period ('.') characters. When signed, the three parts of the JWT are the three parts of a JWS (JSON Web Signature) used to represent the JWT. When encrypted, the three parts of the JWT are the three parts of a JWE (JSON Web Encryption) used to represent the JWT. JWT Header specifies the cryptographic operations performed on the JWT claims. If the JWT Header is a JWS Header, the claims are signed and if the JWT Header is a JWE Header, the claims are encrypted.

sample JWT token includes the following elements.

Header : Algorithm and token type

{
“alg”: “HS256”,
“typ”: “JWT”
}

Payload : data

 {
“sub”: “1234567890”,
“name”: “John Doe”,
“admin”: true
}

Verify signature:

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

Final output:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
. eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9
.
TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Using JWT.IO we can easily decode, verify and generate JWT tokens.

Simple procedure on JWT token generation and validation at the same server

As depicted in the above diagrams after obtaining a JWT token from the server, the clients (eg: browser) can include those tokens in bearer authorization scheme in the authorization header. (Authorization: Bearer <token>). Bearer schemes are an effective way to prevent CSRF (Cross-Site Request Forgery) attacks because we have to attach the token to the request using our scripts explicitly and they can be used in cross domains. One disadvantage is that in this scheme HTTPS secure connections need to be used since token sent in the request can be stolen by third parties and they can use it to access to API until the token expires.

And also to ensure integrity, information contained in the token should be signed by a private key which is owned by the server. When the server gets the token back from the client, it just has to compare the signature sent by the client with the one it will generate with its private key. If the signatures are identical, the token is valid and the JWT claims(user information) contained in the token can be evaluated.


Following are some of the important claims that should be included in a JWT shared between two parties.

iss (Issuer) Claim
Identifies the principal that issued this JWT

sub (Subject) Claim
Identifies the principal that is the subject of the JWT. The claims in a JWT are usually statements about this subject. The subject value must be either scoped to be locally unique in the context of the issue or it should be globally unique.

aud (Audience) Claim
Identifies the recipients that the JWT is intended for. Each principal intended to process the JWT must identify itself as a value in the audience claim of the token. If its not identified as a value in the case where this aud claim is present in the token then the JWT must be rejected by the principal.

exp (Expiration Time) Claim
Identifies the expiration time on or after which the JWT must not be accepted for processing.

Lastly in this post I’m going to show some of the pros and cons of JWT tokens as per my understanding.

Pros

  • JWT tokens are stateless in the sense that session information is not stored server-side which saves server memory consumption.
  • JWT tokens are used to ensure the authenticity of the source. Data signing allows the receiver to verify whether the token was sent by an authentic source. This ensures trust and security between applications and its users.
  • JWT tokens can be used to authenticate users on multiple applications. For this, applications will be required ti share the same private key to sign and verify the tokens. In addition, each application’s token validation endpoints should be specified under the audience claims in order to gain access to this shared token. As a result, users can authenticate one time on the authorization server and if authorization is granted he can seamlessly use other applications that use the same private key to verify JWT tokens.

Cons

  • Since we specify a token expiry, in the case where a user account needs to be removed then the application has to wait for the token to expire for the user account deactivation to be effective.
  • Another major issue is that JWT tokens require re-authentication at the time of token expiration since no refresh tokens are specified in their implementation.
  • In the case of account hijacking a user may need to change their password ASAP. But with JWT if an authentication is done beforehand, then a token generated for previous password would be still valid even after user password is changed until the expiry time.
  • It is not possible to forcefully destroy a token because even if the token is deleted from the browser, it is still going to be valid until the expiry time. Hence user log out is not enforced until the token is expired.

To learn more on this topic, please refer RFC 7519

Sathya Bandara

Written by

Senior Software Engineer@WSO2 | GSoC Participant | CSE graduate@UoM

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade