#modern authentication

In the world of software engineering, it's rare to find someone who hasn't heard of JSON Web Token (JWT) when dealing with authentication and authorization. However, even when we use it, we often remain somewhat unclear about its internal workings and security aspects. In this article, we will explore JWT from a new perspective—from its structure to its necessity in modern systems and best security practices.

1. What is JWT and Why is it Used?

JSON Web Token (JWT) is an open standard (RFC 7519) primarily used as a secure means of transmitting information between two parties. It is highly popular in modern distributed systems and microservice architectures because it is Stateless. This means the server does not need to store user session data in a database; the token itself carries its own identity.

2. Dissecting the Token: The Internal Structure of JWT

Generally, a JWT token is composed of three parts: header, payload, and signature. These parts are separated from each other by dots (.), and each part is encoded using Base64 URL encoding. A JWT token typically appears in the format: header.payload.signature.

a. Header

This section contains information about the token type (JWT) and the algorithm used to sign it (e.g., HS256 or RS256).

b. Payload

This is the core part of the token, containing user information or Claims. For example: user ID, name, token issuance time (iat), expiration time (exp), and so on.

c. Signature

The signature is used to verify the integrity of the token—to ensure it hasn't been tampered with after being issued. It is created using the header, payload, and a secret key.

3. Security Reality Check: What You Need to Know

When using JWT, some misconceptions can increase our security risks:

Encoded, Not Encrypted: Remember, JWT does not encrypt data; it only encodes it. Anyone can decode the token and view the information in the payload. Therefore, never store sensitive information like passwords or secret keys in the Payload.

Integrity vs. Confidentiality: The purpose of the signature is to prevent data tampering or alteration, not to hide data.

4. Modern Implementation and Best Practices

To build a secure system, the following practices are mandatory:

Use HTTPS: Always use an encrypted connection (HTTPS) to prevent token theft.

Short-lived Tokens: Access tokens should always have a short expiration period (e.g., 15-30 minutes).

Refresh Token Strategy: For prolonged login sessions, use refresh tokens and token rotation methods.

Strong Algorithms: If possible, use RS256 (Asymmetric key-based), which is more secure than HS256.

Blacklisting: If necessary, implement a blacklisting mechanism using a database or Redis to invalidate tokens.

5. Decision: When to Use JWT?

JWT is not a one-size-fits-all solution. Choose the right method based on your project's nature. Here are some key differences between Session-based Authentication and JWT:

Session-based Authentication:

Scalability: Storing session data on the server can make it difficult to scale, especially when multiple servers are used.

Control: The server can invalidate or delete a session at any time, immediately revoking user access.

Usage: It is generally suitable for traditional web applications.

JWT (Token-based) Authentication:

Scalability: JWT is Stateless, meaning no session data is stored on the server. This makes it highly scalable for microservices and distributed systems.

Control: Once issued, a token remains valid until its expiration. It is difficult for the server to revoke it immediately unless a blacklisting mechanism is used.

Usage: It is more suitable for mobile applications, Single-Page Applications (SPAs), and API-driven systems.

Conclusion

JWT is not a magical solution, but rather a powerful tool. Before using it, consider your system's security requirements and scalability. By adhering to proper best practices, JWT can make your application more dynamic and secure.

References and Further Reading:

RFC 7519 - JSON Web Token (JWT)

JWT.io - Introduction to JSON Web Tokens

OWASP - JSON Web Token Cheat Sheet

Auth0 - JWT Best Practices

সফটওয়্যার ইঞ্জিনিয়ারিংয়ের জগতে অথেনটিকেশন এবং অথোরাইজেশন নিয়ে কাজ করতে গেলে JSON Web Token (JWT) এর নাম শোনেননি এমন কাউকে খুঁজে পাওয়া দুষ্কর। তবে অনেক সময় আমরা এটি ব্যবহার করলেও এর অভ্যন্তরীণ কার্যপদ্ধতি এবং সিকিউরিটি নিয়ে কিছুটা ধোঁয়াশায় থাকি। আজকের এই আর্টিকেলে আমরা JWT-কে একটি নতুন আঙ্গিকে দেখব—এর গঠন থেকে শুরু করে আধুনিক সিস্টেমে এর প্রয়োজনীয়তা এবং সিকিউরিটি বেস্ট প্র্যাকটিস পর্যন্ত।

১. JWT আসলে কী এবং কেন?

JSON Web Token (JWT) হলো একটি ওপেন স্ট্যান্ডার্ড (RFC 7519), যা মূলত দুটি পক্ষের মধ্যে তথ্য আদান-প্রদানের একটি নিরাপদ মাধ্যম। আধুনিক ডিস্ট্রিবিউটেড সিস্টেম বা মাইক্রোসার্ভিস আর্কিটেকচারে এটি অত্যন্ত জনপ্রিয় কারণ এটি Stateless। অর্থাৎ, সার্ভারকে ইউজারের সেশন ডাটাবেসে সেভ করে রাখতে হয় না; টোকেন নিজেই নিজের পরিচয় বহন করে।

২. টোকেনের ব্যবচ্ছেদ: JWT-এর অভ্যন্তরীণ গঠন

সাধারণভাবে একটি JWT টোকেন header, payload এবং signature—এই তিনটি অংশের সমন্বয়ে তৈরি হয়। অংশগুলো পরস্পরের থেকে ডট (.) দ্বারা পৃথক থাকে এবং প্রতিটি অংশ Base64 URL encoding ব্যবহার করে এনকোড করা হয়। একটি JWT টোকেন দেখতে সাধারণত তিনটি অংশের সমষ্টি: header.payload.signature।

ক. হেডার (Header)

এখানে টোকেনের ধরন (JWT) এবং এটি সাইন করার জন্য কোন অ্যালগরিদম (যেমন: HS256 বা RS256) ব্যবহার করা হয়েছে, সেই তথ্য থাকে।

খ. পে-লোড (Payload)

এটি টোকেনের মূল অংশ যেখানে ইউজারের তথ্য বা Claims থাকে। যেমন: ইউজারের আইডি, নাম এবং টোকেন ইস্যু করার সময় (iat), মেয়াদ শেষ হওয়ার সময় (exp) ইত্যাদি।

গ. সিগনেচার (Signature)

টোকেনটি কি আসল নাকি কেউ মাঝপথে পরিবর্তন করেছে, তা যাচাই করার জন্য সিগনেচার ব্যবহার করা হয়। হেডার, পে-লোড এবং একটি সিক্রেট কি (Secret Key) ব্যবহার করে এটি তৈরি করা হয়।

৩. সিকিউরিটি রিয়ালিটি চেক: যা জানা জরুরি

JWT ব্যবহারের সময় কিছু ভুল ধারণা আমাদের সিকিউরিটি রিস্ক বাড়িয়ে দিতে পারে:

এনকোডেড, এনক্রিপ্টেড নয়: মনে রাখবেন, JWT ডাটা এনক্রিপ্ট করে না, শুধু এনকোড করে। যে কেউ টোকেনটি ডিকোড করে পে-লোডের তথ্য দেখতে পারে। তাই Payload-এ কখনোই পাসওয়ার্ড বা সিক্রেট কি-র মতো সেনসিটিভ তথ্য রাখবেন না।

অখণ্ডতা বনাম গোপনীয়তা: সিগনেচারের কাজ হলো ডাটা টেম্পারিং বা পরিবর্তন রোধ করা, ডাটা লুকিয়ে রাখা নয়।

৪. আধুনিক ইমপ্লিমেন্টেশন ও বেস্ট প্র্যাকটিস

একটি সিকিউর সিস্টেম তৈরিতে নিচের বিষয়গুলো অনুসরণ করা বাধ্যতামূলক:

HTTPS ব্যবহার: টোকেন চুরি রোধ করতে সবসময় এনক্রিপ্টেড কানেকশন (HTTPS) ব্যবহার করুন।

স্বল্পমেয়াদী টোকেন (Short-lived Tokens): এক্সেস টোকেনের মেয়াদ সবসময় কম হওয়া উচিত (যেমন: ১৫-৩০ মিনিট)।

রিফ্রেশ টোকেন স্ট্র্যাটেজি: দীর্ঘক্ষণ লগ-ইন রাখার জন্য রিফ্রেশ টোকেন এবং টোকেন রোটেশন (Token Rotation) পদ্ধতি ব্যবহার করুন।

শক্তিশালী অ্যালগরিদম: সম্ভব হলে RS256 (Asymmetric key-based) ব্যবহার করুন, যা HS256 এর চেয়ে বেশি নিরাপদ।

ব্ল্যাকলিস্টিং: প্রয়োজন হলে টোকেন ইনভ্যালিড করার জন্য ডাটাবেস বা রেডিস (Redis) ব্যবহার করে ব্ল্যাকলিস্টিং মেকানিজম রাখুন।

৫. সিদ্ধান্ত: কখন JWT ব্যবহার করবেন?

JWT সব সমস্যার সমাধান নয়। আপনার প্রজেক্টের ধরন অনুযায়ী সঠিক পদ্ধতি বেছে নিন। এখানে সেশন-বেসড অথেনটিকেশন এবং JWT-এর মধ্যে কিছু গুরুত্বপূর্ণ পার্থক্য তুলে ধরা হলো:

সেশন-বেসড অথেনটিকেশন:

স্কেলেবিলিটি: সেশন ডাটা সার্ভারে সংরক্ষণ করার কারণে এটি স্কেল করা কঠিন হতে পারে, বিশেষ করে যখন একাধিক সার্ভার ব্যবহার করা হয়।

কন্ট্রোল: সার্ভার যেকোনো সময় সেশন বাতিল বা ডিলিট করতে পারে, যা ব্যবহারকারীর অ্যাক্সেস তাৎক্ষণিকভাবে বন্ধ করে দেয়।

ব্যবহার: এটি সাধারণত ট্র্যাডিশনাল ওয়েব অ্যাপ্লিকেশনগুলির জন্য উপযুক্ত।

JWT (টোকেন-বেসড) অথেনটিকেশন:

স্কেলেবিলিটি: JWT হলো Stateless, অর্থাৎ সার্ভারে কোনো সেশন ডাটা সংরক্ষণ করা হয় না। এটি মাইক্রোসার্ভিস এবং ডিস্ট্রিবিউটেড সিস্টেমের জন্য অত্যন্ত স্কেলেবল।

কন্ট্রোল: একবার ইস্যু হওয়ার পর টোকেনটি তার মেয়াদ শেষ না হওয়া পর্যন্ত বৈধ থাকে। সার্ভারের পক্ষে তাৎক্ষণিকভাবে এটি বাতিল করা কঠিন, যদি না ব্ল্যাকলিস্টিং মেকানিজম ব্যবহার করা হয়।

ব্যবহার: মোবাইল অ্যাপ্লিকেশন, সিঙ্গেল-পেজ অ্যাপ্লিকেশন (SPA) এবং API-ভিত্তিক সিস্টেমের জন্য এটি বেশি উপযোগী।

উপসংহার

JWT কোনো জাদুকরী সমাধান নয়, বরং এটি একটি শক্তিশালী টুল। এটি ব্যবহারের আগে আপনার সিস্টেমের সিকিউরিটি রিকোয়ারমেন্ট এবং স্কেলেবিলিটি নিয়ে ভাবুন। সঠিক বেস্ট প্র্যাকটিস মেনে চললে JWT আপনার অ্যাপ্লিকেশনকে করতে পারে আরও গতিশীল এবং নিরাপদ।

তথ্যসূত্র ও আরও পড়াশোনা:

RFC 7519 - JSON Web Token (JWT)

JWT.io - Introduction to JSON Web Tokens

OWASP - JSON Web Token Cheat Sheet

Auth0 - JWT Best Practices