🙏

জয়  শ্রী  রাম

🕉

---

Modern authentication and authorization protocols use tokens as a method of carrying just enough data to either authorize a user to execute an action or request data from a resource. In short, tokens are packets of information that allow some authorization process to be carried out. JWT tokens specifically provide a very convenient way to package up common properties about a user in the form of claims. The nice thing about claims is that they can be trusted and repeatedly validated because in most cases they are digitally signed using a private key with the HMAC algorithm. This signature ensures only a server possessing the key can decode and verify the contents of incoming tokens and grant or deny access to its resources.


The diagram above is relatively straight-forward in illustrating how access tokens get issued by an authentication server and then exchanged in subsequent requests to access protected resources. But, if we look at it for long enough we should strike upon one crucial question: how long is the lifetime of an access token? Does it last for an hour or a day or a month?

This question is important because if some malicious party were to get a hold of a token, they could use it for its entire lifetime while posing as a genuine recipient. This scenario can occur because the server will always trust a JWT token with a valid signature.

At this point, the only way to invalidate the compromised token is by modifying the key used to sign it - but if we do that we invalidate every issued token for every user! Changing the key for this purpose is not an acceptable approach, and this exact problem is what refresh tokens are intended to solve.


Refresh tokens hold only the information required to obtain a new access token. They are mainly a one-time-use token to be exchanged for a new access token issued by the authentication server. The primary use case is trading in old, expired access tokens. In this scenario, a new JWT can be obtained by the client without re-authenticating, so there is no need to bug the user to enter their credentials every time their access token expires. Depending on the implementation and lifetime the token is valid for - minutes, hours, etc. this provides a seamless experience for the user while maintaining a higher degree of security. 🔒

Better yet, if a refresh token becomes compromised, it can be revoked or blacklisted so when any client app attempts to exchange it for a new access token the request will be denied forcing the user to re-enter their credentials and identify themselves appropriately with the authentication server.

The length of time your access and refresh tokens are valid for will largely depend on your unique application and security requirements. Generally, access tokens are said to be short-lived meaning they can expire anywhere from a few minutes to hours after being issued while refresh tokens are long-lived with a longer lifetime and are securely stored to protect them from potential attackers.

Now that I have given you some background story, we will be implementing a simple authentication manager as per the below requirements.

Problem Statement:

There is an authentication system that works with authentication tokens. For each session, the user will receive a new authentication token that will expire timeToLive seconds after the currentTime. If the token is renewed, the expiry time will be extended to expire timeToLive seconds after the (potentially different) currentTime. If a token expires at time t, and another action happens on time t (example: request to renew the token or request to get count of unexpired tokens in the system), the expiration takes place before the other actions. Design the system and implement all the core features.

Solution (Java and Python):

Requirements Analysis:

Login to Access Content

High Level Design:

Login to Access Content

Low Level Design:

Login to Access Content

High Level Design: Further Improvements and Optimization:

Login to Access Content

Instructor: