ওয়েব অ্যাপের সেশন ম্যানেজমেন্ট: কুকি বনাম JWT বনাম রিফ্রেশ

সেশন ম্যানেজমেন্ট আসলে কী করছে

একটি সেশন হল লগইন করার পর আপনার অ্যাপটি যে প্রশ্নটির উত্তর দেয়: “আপনি এখন কে?” একবার সেই উত্তর নির্ভরযোগ্য হলে, অ্যাপটি ঠিক করতে পারে ব্যবহারকারী কী দেখতে পাবে, কী পরিবর্তন করতে পারবে, এবং কোন কাজগুলো ব্লক করতে হবে।

“লগ ইন টিয়ে থাকা” একটা নিরাপত্তা সিদ্ধান্তও বটে। আপনি ঠিক করছেন ব্যবহারকারীর পরিচয় কতক্ষণ বৈধ থাকবে, পরিচয়ের প্রমাণ কোথায় থাকবে, এবং যদি সেই প্রমাণ অনুলিপি হয়ে যায় তাহলে কী হবে।

অধিকাংশ ওয়েব অ্যাপ সেটআপ তিনটি মূল উপাদানের ওপর নির্ভর করে:

• কুকি-ভিত্তিক সার্ভার সেশন: ব্রাউজার একটি কুকি রাখে, এবং সার্ভার প্রতিটি অনুরোধে সেশন খুঁজে দেখে।
• JWT অ্যাকসেস টোকেন: ক্লায়েন্ট একটি সাইন করা টোকেন পাঠায় যা সার্ভার ডাটাবেজ দেখতে না করেই ভেরিফাই করতে পারে।
• রিফ্রেশ টোকেন: বেশি স্থায়ী ক্রেডেনশিয়াল যা নতুন, স্বল্প-স্থায়ী অ্যাকসেস টোকেন পান করতে ব্যবহৃত হয়।

এগুলো পরস্পরের প্রতিদ্বন্দ্বী “স্টাইল” না; বরং একই ট্রেড-অফগুলো পরিচালনা করার ভিন্ন উপায়: গতি বনাম নিয়ন্ত্রণ, সরলতা বনাম নমনীয়তা, এবং “এখনই এটা অকার্যকর করা যাবে?” বনাম “এটি নিজে শেষ হবে?”।

কোনও ডিজাইনে একটি সহজ পরীক্ষা: যদি একজন আক্রমকারী আপনার অ্যাপের ব্যবহার করা প্রমাণ চুরি করে (কুকি বা টোকেন), তারা কী করতে পারে এবং কতক্ষণ করতে পারে? সার্ভার-সাইড কুকি সেশনগুলো প্রায়ই জিতেযায় যখন আপনার কাছে শক্ত সার্ভার-সাইড নিয়ন্ত্রণ দরকার—যেমন জোরপূর্বক লগআউট বা তৎক্ষণিক লকআউট। JWT বহু সেবার মধ্যে স্ট্যাটলেস যাচাইকরণের জন্য ভালো হতে পারে, কিন্তু তা তৎক্ষণিক রদবদলে ঝামেলা বাড়ায়।

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

কোন হুমকি মডেলগুলি সিদ্ধান্ত বদলে দেয়

ভালো সেশন ডিজাইন “সবচেয়ে ভালো” টোকেন টাইপের চেয়ে কম নির্ভর করে এবং অধিক নির্ভর করে আপনি কোন আক্রমণগুলিকে বাঁচতে চান।

যদি আক্রমকারী ব্রাউজার স্টোরেজ (যেমন localStorage) থেকে ডেটা চুরি করে, JWT অ্যাকসেস টোকেন সহজে হাতবদল হয়ে যায় কারণ পেজের JavaScript তা পড়তে পারে। একটি চুরি হওয়া কুকি ভিন্ন: যদি সেটি HttpOnly হিসেবে সেট করা থাকে, সাধারণ পেজ কোড তা পড়তে পারে না, ফলে সরল “টোকেন চুরি” আক্রমণ কঠিন হয়। কিন্তু যদি আক্রমকারী ডিভাইসটা নিয়ে যায় (গোচন ল্যাপটপ, ম্যালওয়্যার, শেয়ার করা কম্পিউটার), কুকি তখনও ব্রাউজার প্রোফাইল থেকে কপি করা যেতে পারে।

XSS (আপনার পেজে আক্রমক কোড চালানো) সব কিছু বদলে দেয়। XSS থাকলে আক্রমকারী হয়তো কিছুই চুরি না করেই ভিকটিমের আগেই-লগইন সেশন ব্যবহার করে কাজ করতে পারে। HttpOnly কুকি সেশন সিক্রেট পড়া রোধ করে, কিন্তু তারা পেজ থেকে অনুরোধ পাঠানো রোধ করে না।

CSRF (অন্য সাইট থেকে অনিচ্ছাকৃত অনুরোধ তৈরি) প্রধানত কুকি-ভিত্তিক সেশনগুলিকে ঝুঁকিতে ফেলে, কারণ ব্রাউজার স্বয়ংক্রিয়ভাবে কুকি যুক্ত করে। কুকির উপর নির্ভর করলে আপনাকে স্পষ্ট CSRF প্রতিরক্ষা দরকার: উদ্দেশ্যপূর্ণ SameSite সেটিংস, anti-CSRF টোকেন এবং স্টেট-চেঞ্জিং অনুরোধগুলোর সাবধান হ্যান্ডলিং। Authorization হেডারে পাঠানো JWT ক্লাসিক CSRF-এর তুলনায় কম প্রকাশ্য, তবে যদি সেগুলো যেখানে JavaScript পড়তে পারে সেখানে রাখা হয় তাহলে XSS দ্বারা ঝুঁকিতে থাকে।

রিপ্লে আক্রমণ (চুরি করা ক্রেডেনশিয়াল পুনরায় ব্যবহার) যেখানে সার্ভার-সাইড সেশনগুলো ভাল: আপনি দ্রুত একটি সেশন আইডি অকার্যকর করতে পারেন। স্বল্প-স্থায়ী JWT রিপ্লের সময় কমিয়ে দেয়, কিন্তু টোকেন বৈধ থাকার সময় রিপ্লে আটকায় না।

শেয়ার করা ডিভাইস ও হারানো ফোন “সাইন আউট”কে সত্যিকারের হুমকি মডেলে পরিণত করে। সিদ্ধান্তগুলো সাধারণত এমন প্রশ্নের ওপর আসে: ব্যবহারকারী কি অন্য ডিভাইস থেকে লগআউট করতে পারবে, সেটি কত দ্রুত প্রভাব ফেলতে হবে, যদি রিফ্রেশ টোকেন চুরি হয় কী হবে, এবং আপনি কি “মনে রেখো” সেশান অনুমোদন করবেন? অনেক টিম স্টাফ অ্যাক্সেসকে গ্রাহক অ্যাক্সেসের তুলনায় কঠোর মানদণ্ডে রাখে—যা টাইমআউট ও প্রত্যাহারের প্রত্যাশা বদলে দেয়।

কুকি সেশন: কিভাবে কাজ করে এবং কী রক্ষা করে

কুকি-ভিত্তিক সেশন হল ক্লাসিক সেটআপ। সাইন-ইনের পরে সার্ভার একটি সেশন রেকর্ড তৈরি করে (সাধারণত একটি আইডি ও ব্যবহারকারী আইডি, তৈরি সময়, মেয়াদ)। ব্রাউজার কেবল সেশন আইডি কুকিতে রাখে। প্রতিটি অনুরোধে ব্রাউজার ঐ কুকিটি পাঠায়, এবং সার্ভার সেশন দেখে সিদ্ধান্ত নেয় ব্যবহারকারী কে।

সবচেয়ে বড় নিরাপত্তা সুবিধা হল নিয়ন্ত্রণ। সার্ভার প্রতিবার সেশন ভ্যালিডেট করে। যদি আপনাকে কাউকে দ্রুত কিক আউট করতে হয়, আপনি সার্ভার-সাইড সেশন রেকর্ড মুছে দিলে তা তৎক্ষণাৎ কাজ বন্ধ করে দেয়, এমনকি ব্যবহারকারীর কাছে এখনও কুকি থাকলেও।

অনেক সুরক্ষা কুকি সেটিংস থেকে আসে:

• HttpOnly: JavaScript কে কুকি পড়া থেকে রোধ করে।
• Secure: কুকিটি শুধুমাত্র HTTPS-এ পাঠায়।
• SameSite: ক্রস-সাইট অনুরোধে কুকি কখন পাঠাবে তা সীমাবদ্ধ করে।

আপনি সেশন স্টেট কোথায় রাখেন সেই সিদ্ধান্ত স্কেলিংকে প্রভাবিত করে। অ্যাপ মেমরিতে সেশন রাখা সহজ, কিন্তু অনেক সার্ভার চালালে বা বারবার রিস্টার্ট করলে কাজ করবে না। ডাটাবেস স্থায়ীত্বের জন্য ভালো। দ্রুত লুকআপ ও বহু সক্রিয় সেশনের জন্য Redis সাধারণ। মূল বিষয়: সার্ভার প্রতি অনুরোধে সেশন খুঁজে পেতে ও ভ্যালিডেট করতে পারতে হবে।

কুকি সেশন তখনই ভালো মিল যখন আপনাকে কঠোর লগআউট আচরণ দরকার—যেমন স্টাফ ড্যাশবোর্ড বা কাস্টমার পোর্টাল যেখানে একজন অ্যাডমিন কোনো রোল বদলানোর পরে তৎক্ষণাৎ লগআউট করতে চাইবে। কোনো কর্মী ছেড়ে গেলে তাদের সার্ভার-সাইড সেশন ডিসেবল করে তৎক্ষণাৎ অ্যাক্সেস বন্ধ করা যায়, টোকেন এক্সপায়ারির জন্য অপেক্ষা করতে হবে না।

JWT অ্যাকসেস টোকেন: শক্তি এবং ধারালো দিক

একটি JWT (JSON Web Token) হল একটি সাইন করা স্ট্রিং যা ব্যবহারকারীর কয়েকটি ক্লেইম বহন করে (যেমন ব্যবহারকারী আইডি, রোল, টেন্যান্ট) পাশাপাশি এক্সপায়ারি সময়। আপনার API লোকালি সিগনেচার ও এক্সপায়ারি যাচাই করে, ডাটাবেস কল না করে, তারপর অনুরোধ অনুমোদন করে।

এই কারণেই JWT API-ফার্স্ট প্রোডাক্ট, মোবাইল অ্যাপ এবং একাধিক সেবা একই পরিচয় যাচাই করা দরকার এমন সিস্টেমে জনপ্রিয়। যদি আপনার বহু ব্যাকএন্ড ইনস্ট্যান্স থাকে, প্রতিটি একই টোকেন যাচাই করে একই উত্তর পাবে।

শক্তি

JWT অ্যাকসেস টোকেন দ্রুত যাচাই করা যায় এবং API কলগুলোর সঙ্গে সহজেই বহন করা যায়। আপনার ফ্রন্টেন্ড অনেক এন্ডপয়েন্ট কল করলে, স্বল্প-স্থায়ী অ্যাকসেস টোকেন প্রবাহকে সরল রাখে: সিগনেচার যাচাই, ব্যবহারকারীর আইডি পড়া, এগিয়ে যাওয়া।

উদাহরণ: একটি কাস্টমার পোর্টাল আলাদা সার্ভিসে “List invoices” এবং “Update profile” কল করে। একটি JWT কাস্টমার আইডি এবং customer রোল বহন করতে পারে, তাই প্রতিটি সার্ভিস সেশন লুকআপ না করেই অনুরোধ অনুমোদন করতে পারে।

ধারালো দিক

সবচেয়ে বড় ট্রেড-অফ হচ্ছে রদবদল (revocation)। যদি একটি টোকেন এক ঘণ্টার জন্য বৈধ থাকে, সাধারণত তা ঐ সময় জুড়ে সারাদেশে বৈধ থাকে—এমনকি ব্যবহারকারী “লগ আউট” চাপলেও বা এক অ্যাডমিন অ্যাকাউন্ট নিষ্ক্রিয় করলেও—যদি না আপনি অতিরিক্ত সার্ভার-সাইড চেক যোগ করেন।

JWT সাধারণভাবে বিভিন্ন রাস্তায় লিক করে। সাধারণ দুর্বলতা হলো localStorage (XSS সেটি পড়তে পারে), ব্রাউজার মেমরি (দূষিত এক্সটেনশন), লগ ও এরর রিপোর্ট, প্রক্সি ও অ্যানালিটিক্স টুলস যা হেডার কিপ করে, এবং সাপোর্ট চ্যাট বা স্ক্রিনশটে কপি করা টোকেন।

এই কারণেই JWT অ্যাকসেস টোকেন স্বল্প-স্থায়ীর অ্যাক্সেসের জন্য ভালো কাজ করে, “চিরস্থায়ী লগইন” জন্য নয়। এগুলোকে ন্যূনতম রাখুন (ভিতরে সংবেদনশীল ব্যক্তিগত ডেটা না রাখুন), এক্সপায়ারি ছোট রাখুন, এবং ধরে নিন চুরি হওয়া টোকেন এক্সপায়ারি পর্যন্ত ব্যবহারযোগ্য থাকবে।

রিফ্রেশ টোকেন: JWT সেটআপকে ব্যবহারযোগ্য করা

JWT অ্যাকসেস টোকেন স্বল্প-স্থায়ী করার উদ্দেশ্যে। এটি নিরাপত্তার জন্য ভালো, কিন্তু ব্যবহারিক সমস্যা তৈরি করে: ব্যবহারকারীকে প্রতি কয়েক মিনিটে পুনরায় লগইন করাতে চাইবে না। রিফ্রেশ টোকেন এই সমস্যার সমাধান দেয়—অ্যাপ পুরোনো টোকেন মেয়াদোত্তীর্ণ হলে নিঃশব্দে নতুন অ্যাকসেস টোকেন নেয়।

রিফ্রেশ টোকেন কোথায় রাখা হয় তা অ্যাকসেস টোকেনের চেয়ে আরও গুরুত্বপূর্ণ। ব্রাউজার-ভিত্তিক ওয়েব অ্যাপে নিরাপদ ডিফল্ট হল HttpOnly, Secure কুকি যাতে JavaScript তা পড়তে না পারে। লোকাল স্টোরেজ বাস্তবায়নে সহজ, কিন্তু XSS থাকলে সহজে চুরি হয়। যদি আপনার হুমকি মডেলে XSS থাকে, দীর্ঘমেয়াদি সিক্রেট JavaScript-এ রাখবেন না।

রোটেশন হল যা রিফ্রেশ টোকেন বাস্তবে ব্যবহারযোগ্য করে। একই রিফ্রেশ টোকেন সপ্তাহের পর সপ্তাহ ব্যবহার করার বদলে, প্রতিবার ব্যবহারের সময় আপনি এটি বদলে ফেলবেন: ক্লায়েন্ট রিফ্রেশ টোকেন A দেখায়, সার্ভার একটি নতুন অ্যাকসেস টোকেন এবং রিফ্রেশ টোকেন B ইস্যু করে, এবং রিফ্রেশ টোকেন A অকার্যকর হয়ে যায়।

একটি সাধারণ রোটেশন সেটআপে কয়েকটি নিয়ম থাকে:

• অ্যাকসেস টোকেন সংক্ষিপ্ত রাখুন (মিনিট, ঘন্টা নয়)।
• রিফ্রেশ টোকেন সার্ভার-সাইডে স্টোর করুন স্ট্যাটাস ও লাস্ট-ইউজ সহ।
• প্রতিটি রিফ্রেশে রোটেট করুন এবং পূর্ববর্তী টোকেন অবৈধ করুন।
• সম্ভব হলে রিফ্রেশ টোকেন ডিভাইস বা ব্রাউজারের সঙ্গে বাইন্ড করুন।
• রিফ্রেশ ইভেন্ট লগ করুন যাতে অপব্যবহার তদন্ত করতে পারেন।

রিইউজ ডিটেকশনই কীটি অ্যালার্ম দেয়। যদি রিফ্রেশ টোকেন A একবার এক্সচেঞ্জ হয়ে গেছে, কিন্তু পরে আবার দেখা যায়, ধরে নিন এটি কপি হয়েছে। সাধারণ প্রতিক্রিয়া হল পুরো সেশন রদবদল করা (এবং প্রায়ই সেই ব্যবহারকারীর সব সেশন) এবং নতুন লগইন বাধ্য করা, কারণ কোন কপি বাস্তব তা আপনি জানেন না।

লগআউটের জন্য আপনার এমন কিছু দরকার যা সার্ভার কার্যকর করতে পারে। সাধারণত এর মানে একটি সেশন টেবিল (বা একটি রদবদল তালিকা) যা রিফ্রেশ টোকেনগুলোকে প্রত্যাহার হিসেবে চিহ্নিত করে। অ্যাকসেস টোকেনসমূহ শট পর্যন্ত কাজ করতে পারে, কিন্তু অ্যাকসেস টোকেনকে ছোট রাখলেই আপনি সেই উইন্ডো ছোট রাখতে পারবেন।

লগআউট চাহিদা এবং কী বাস্তবে আরোপযোগ্য

লগআউট শুনতে সহজ মনে হয় যতক্ষণ না আপনি এটি সংজ্ঞায়িত করেন। সাধারণত দুইটি আলাদা চাহিদা থাকে: “এই ডিভাইস থেকে লগআউট” (একটি ব্রাউজার বা একটি ফোন) এবং “সবখান থেকে লগআউট” (সব সক্রিয় সেশন সব ডিভাইসে)।

এখানেও সময়গত প্রশ্ন আছে। “তৎক্ষণাৎ লগআউট” মানে অ্যাপটি বা ক্রেডেনশিয়ালটি এখনই গ্রহণ বন্ধ করে। “এক্সপায়ারির পর লগআউট” মানে অ্যাপটি তখনই গ্রহণ বন্ধ করে যখন বর্তমান সেশন বা টোকেন নিজে এক্সপায়ার করে।

কুকি-ভিত্তিক সেশনগুলোর ক্ষেত্রে, তৎক্ষণাৎ লগআউট সরল কারণ সার্ভার সেশন নিয়ন্ত্রণ করে। আপনি ক্লায়েন্টে কুকি মুছে ফেলেন এবং সার্ভার-সাইড সেশন রেকর্ড অবৈধ করেন। যদি কেউ আগেই কুকি কপি করে থাকে, সার্ভার-রিজেকশনই প্রকৃতপক্ষে লগআউট কার্যকর করে।

শুধু JWT-ভিত্তিক অথ (স্ট্যাটলেস অ্যাকসেস টোকেন এবং কোনো সার্ভার লুকআপ নেই) দিয়ে আপনি সত্যিকারের তৎক্ষণাৎ লগআউট গ্যারান্টি দিতে পারবেন না। চুরি হওয়া JWT বৈধ থাকা পর্যন্ত কাজ করবে, কারণ সার্ভারের কাছে “এই টোকেন কি প্রত্যাহার করা হয়েছে?” জিজ্ঞেস করার জায়গা নেই। আপনি একটি ডিনাইলিস্ট যোগ করতে পারেন, কিন্তু এতে আপনি স্টেট রাখবেন ও চেক করবেন—যা মূল সরলতার অনেকটাই হারিয়ে দেয়।

একটি বাস্তবসম্মত প্যাটার্ন হল অ্যাকসেস টোকেনকে স্বল্প-স্থায়ী ধরে রাখা এবং রিফ্রেশ টোকেনের মাধ্যমে লগআউট প্রয়োগ করা। অ্যাকসেস টোকেন কয়েক মিনিট পর্যন্ত চলতে পারে, কিন্তু রিফ্রেশ টোকেনই সেশনকে জীবিত রাখে। ল্যাপটপ চুরি হলে, রিফ্রেশ টোকেন পরিবার প্রত্যাহার করলে ভবিষ্যত অ্যাক্সেস দ্রুত কাটা যায়।

আপনি ব্যবহারকারীদের কী বাস্তবে প্রতিশ্রুতি দিতে পারেন:

• এই ডিভাইস থেকে লগআউট: ঐ সেশন বা রিফ্রেশ টোকেন প্রত্যাহার করুন, এবং লোকাল কুকি/স্টোরেজ মুছে দিন।
• সবখান থেকে লগআউট: অ্যাকাউন্টের সব সেশন বা সব রিফ্রেশ টোকেন পরিবার প্রত্যাহার করুন।
• "তৎক্ষণাৎ" প্রভাব: সার্ভার সেশনগুলোর ক্ষেত্রে গ্যারান্টিযুক্ত, অ্যাক্সেস টোকেনের ক্ষেত্রে এক্সপায়ারি পর্যন্ত বেষ্ট-এফোর্ট।
• জোরপূর্বক লগআউট ইভেন্ট: পাসওয়ার্ড পরিবর্তন, অ্যাকাউন্ট নিষ্ক্রিয়করণ, রোল ডাউনগ্রেড।

পাসওয়ার্ড পরিবর্তন ও অ্যাকাউন্ট নিষ্ক্রিয়করণের জন্য, "ব্যবহারকারী লগ আউট করবে" উপর ভরসা করবেন না। একটি অ্যাকাউন্ট-প্রতিবেশ সেশন ভার্সন (বা একটি "টোকেন বৈধ পরে" টাইমস্ট্যাম্প) স্টোর করুন। প্রতিটি রিফ্রেশে (এবং সময়-একি অনুরোধে) এটিকে তুলনা করুন। যদি এটি বদলে যায়, প্রবেশ বারণ করুন এবং পুনরায় সাইন-ইন দাবি করুন।

ধাপে ধাপে: আপনার অ্যাপের জন্য সেশন পদ্ধতি বাছাই

আপনি যদি সেশন ডিজাইন সহজ রাখতে চান, আগে আপনার নিয়মগুলি নির্ধারণ করুন তারপর যান্ত্রিকতা বাছুন। বেশিরভাগ সমস্যা তখনই শুরু হয় যখন টিমগুলো JWTs বা কুকি জনপ্রিয় বলে পছন্দ করে, কেবল সেগুলো তাদের ঝুঁকি ও লগআউট চাহিদার সাথে মেলে না।

প্রত্যেক জায়গায় ব্যবহারকারী কোথায় সাইন ইন করে তা তালিকা করুন। একটি ব্রাউজার অ্যাপ স্বদেশী মোবাইল অ্যাপ, একটি অভ্যন্তরীণ অ্যাডমিন টুল, বা একটি পার্টনার ইন্টিগ্রেশনের মতো ক্লায়েন্ট থেকে আলাদা আচরণ করে। প্রতিটি বদলে দেয় কী নিরাপদভাবে রাখা যায়, লগইন কিভাবে নবায়ন করা হবে, এবং “লগআউট” কী বোঝায়।

অধিকাংশ টিমের জন্য কার্যকর একটি বাস্তব পদক্ষেপক্রম:

1. আপনার ক্লায়েন্টগুলো তালিকা করুন: ওয়েব, iOS/Android, অভ্যন্তরীণ টুল, তৃতীয়-পক্ষ এক্সেস।
2. একটি ডিফল্ট হুমকি মডেল বেছে নিন: XSS, CSRF, চুরি ডিভাইস।
3. সিদ্ধান্ত নিন লগআউট কী গ্যারান্টি দেবে: এই ডিভাইস, সব ডিভাইস, অ্যাডমিন জোরপূর্বক লগআউট।
4. একটি বেসলাইন প্যাটার্ন বেছে নিন: কুকি-ভিত্তিক সেশন (সার্ভার মনে রাখে) অথবা অ্যাক্সেস টোকেন + রিফ্রেশ টোকেন।
5. টাইমআউট ও প্রতিক্রিয়া নিয়ম নির্ধারণ করুন: idle বনাম absolute এক্সপায়ারি, ও সন্দেহজনক রিইউজ দেখলে কী করবেন।

তারপর আপনার সিস্টেম যে সঠিক প্রতিশ্রুতি দিচ্ছে তা ডকুমেন্ট করুন। উদাহরণ: “ওয়েব সেশন 30 মিনিট idle পরে বা 7 দিন absolute এ এক্সপায়ার করে। অ্যাডমিন 60 সেকেন্ডের মধ্যে লগআউট জোরদার করতে পারে। হারানো ফোন দূর থেকে নিষ্ক্রিয় করা যাবে।” এই বাক্যগুলো লাইব্রেরি চেয়ে বেশি গুরুত্বপূর্ণ।

শেষে, আপনার প্যাটার্ন অনুযায়ী মনিটরিং যোগ করুন। টোকেন সেটআপের জন্য একটি শক্ত সংকেত হলো রিফ্রেশ টোকেনের রিইউজ (একই রিফ্রেশ টোকেন দুইবার ব্যবহার)। এটিকে সম্ভাব্য চুরির মতো বিবেচনা করুন, সেশন পরিবার প্রত্যাহার করুন এবং ব্যবহারকারীকে সতর্ক করুন।

অ্যাকাউন্ট দখলের দিকে নিয়ে যাওয়ার সাধারণ ভুলগুলো

অধিকাংশ অ্যাকাউন্ট দখল “চতুর হ্যাক” নয়। এগুলো সাধারণত সরল ভুলের কারণে ঘটে। ভালো সেশন হ্যান্ডলিং মূলত আক্রমণকারীর জন্য সহজভাবে ক্রেডেনশিয়াল চুরি বা রিপ্লে করা কঠিন করে দেওয়ার ব্যাপার।

একটি সাধারণ ফাঁদ হল অ্যাকসেস টোকেন localStorage-এ রাখা এবং কেবল আশা করা যে আপনি কখনও XSS পাবেন না। যদি কোনো স্ক্রিপ্ট আপনার পেজে চলে (একটি দুর্বল নির্ভরশীলতা, ইনজেক্টেড উইজেট, একটি স্টোরড কমেন্ট), তা localStorage পড়ে টোকেন পাঠিয়ে দিতে পারে। HttpOnly কুকি এই ঝুঁকি কমায় কারণ JavaScript তা পড়তে পারে না।

আরেকটি ফাঁদ হলো JWT দীর্ঘমেয়াদী করা যাতে রিফ্রেশ টোকেন এড়ানো যায়। 7 দিনের অ্যাকসেস টোকেন হলে সেটা যদি লিক হয় 7 দিন ধরে পুনরায় ব্যবহার করা যাবে। স্বল্প অ্যাকসেস টোকেন প্লাস ভালোভাবে ম্যানেজ করা রিফ্রেশ টোকেন অপব্যবহার কঠিন করে দেয়, বিশেষ করে যখন আপনি রিফ্রেশ বন্ধ করতে পারেন।

কুকি ব্যবহার করলে CSRF প্রতিরক্ষা ভুলে যাওয়াও বড় সমস্যা। যদি আপনার অ্যাপ কুকি সেশন ব্যবহার করে এবং আপনি স্টেট-চেঞ্জিং অনুরোধগুলিকে CSRF ছাড়া গ্রহণ করেন, একটি দুষ্ট সাইট লগইন করা ব্রাউজারকে বৈধ অনুরোধ পাঠাতে প্ররোচিত করতে পারে।

ইনসাইটে প্রায়ই যা দেখা যায়:

• রিফ্রেশ টোকেন কখনও রোটেট করে না, অথবা তারা রোটেট করে কিন্তু রিইউজ সনাক্ত করেনা।
• আপনি বহু লগইন পদ্ধতিকে সমর্থন করেন (কুকি সেশন এবং বেয়ারার টোকেন) কিন্তু সার্ভারের “কোনটি জিতবে” নিয়ম অস্বচ্ছ।
• টোকেন লগে পড়ে যায় (ব্রাউজার কনসোল, অ্যানালিটিক্স ইভেন্ট, সার্ভার রিকোয়েস্ট লগ), যেখানে সেগুলো কপি ও সংরক্ষিত হয়।

একটি বাস্তব উদাহরণ: একটি সাপোর্ট এজেন্ট "ডিবাগ লগ" একটি টিকেটে পেস্ট করে। লগে Authorization হেডার আছে। টিকেট অ্যাক্সেস যারা পায় তারা ঐ টোকেন রেপ্লে করে এজেন্ট হিসেবে কাজ করতে পারে। টোকেনকে পাসওয়ার্ডের মতো বিবেচনা করুন: তা প্রিন্ট করবেন না, সংরক্ষণ করবেন না, এবং সংক্ষিপ্ত-মেয়াদি রাখুন।

চালানোর আগে দ্রুত চেকলিস্ট

অধিকাংশ সেশন বাগ জটিল ক্রিপ্টো সম্পর্কে নয়। তারা একফ্ল্যাগ মিসিং, একটি টোকেন অনেক দিন ধরে থাকা, বা একটি এন্ডপয়েন্ট যা পুনঃপ্রমাণ প্রত্যাশা করা উচিত—এসবের কারণে।

রিলিজের আগে, একটি ছোট স্টেজিং পাস করুন যা দেখবে একজন আক্রমকারী একটি চুরি করা কুকি বা টোকেন দিয়ে কী করতে পারে। এটা আপনার নিরাপত্তা দ্রুত উন্নত করার একটি দ্রুত উপায়।

প্রিলঞ্চ চেকলিস্ট

স্টেজিংয়ে এগুলো যাচাই করুন, তারপর প্রোডাকশনে দেখুন:

• অ্যাকসেস টোকেন সংক্ষিপ্ত রাখুন (মিনিট), এবং নিশ্চিত করুন API এক্সপায়ারির পরে সেগুলো অস্বীকার করে।
• রিফ্রেশ টোকেনকে পাসওয়ার্ডের মতো বিবেচনা করুন: সম্ভব হলে JavaScript পড়তে না পারার জায়গায় রাখুন, শুধুমাত্র রিফ্রেশ এন্ডপয়েন্টে পাঠান, এবং প্রতিবার ব্যবহারে রোটেট করুন।
• যদি আপনি কুকি দিয়ে অথ করেন, ফ্ল্যাগগুলো যাচাই করুন: HttpOnly চালু, Secure চালু, এবং SameSite ইচ্ছাকৃতভাবে সেট করেছেন কিনা। কুকি স্কোপ (ডোমেন ও পাথ) প্রয়োজনের চাইতে বেশি বিস্তৃত নেই নিশ্চিত করুন।
• যদি কুকি দিয়ে অনুরোধ অথেনটিকেট করেন, CSRF প্রতিরক্ষা যোগ করুন, এবং নিশ্চিত করুন স্টেট-চেঞ্জিং এন্ডপয়েন্ট CSRF সাড়া না দিলে ব্যর্থ হয়।
• রদবদল বাস্তবে আছে: পাসওয়ার্ড রিসেট বা অ্যাকাউন্ট নিষ্ক্রিয় করার পরে বিদ্যমান সেশন দ্রুত কাজ করা বন্ধ করা উচিত (সার্ভার-সাইড সেশন ডিলিট, রিফ্রেশ টোকেন অবৈধ করা, অথবা একটি "সেশন ভার্সন" চেক)।

এরপর আপনার লগআউট প্রতিশ্রুতিগুলো পরীক্ষা করুন। "লগ আউট" প্রায়ই মানে "লোকাল সেশন মুছুন", কিন্তু ব্যবহারকারীরা এর থেকে বেশি আশা করে।

একটি ব্যবহারিক পরীক্ষা: একটি ল্যাপটপ ও ফোনে লগইন করুন, তারপর পাসওয়ার্ড পরিবর্তন করুন। ল্যাপটপটি তার পরবর্তী অনুরোধে বাদ পড়া উচিত, ঘণ্টা নয়। যদি আপনি "সবখান থেকে লগ আউট" অফার করে থাকেন এবং একটি ডিভাইস তালিকা থাকে, নিশ্চিত করুন প্রতিটি ডিভাইস একটি আলাদা সেশন বা রিফ্রেশ টোকেন রেকর্ড হিসেবে ম্যাপ হয় যা আপনি প্রত্যাহার করতে পারেন।

উদাহরণ: স্টাফ অ্যাকাউন্টসহ কাস্টমার পোর্টাল এবং জোরপূর্বক লগআউট

একটি ছোট ব্যবসার কল্পনা করুন যার একটি ওয়েব কাস্টমার পোর্টাল (কাস্টমাররা চালান ইভয়েস, টিকেট ওপেন করে) এবং একটি মোবাইল অ্যাপ মাঠ কর্মীদের জন্য (জব, নোট, ছবি)। স্টাফরা মাঝে মাঝে সিগনালের বাইরে কাজ করে, তাই অ্যাপকে কিছু সময় অফলাইনে কাজ করতে হবে। অ্যাডমিনেরা চান একটি বড় লাল বোতাম: যদি একটি ট্যাবলেট হারিয়ে যায় বা একজন কন্ট্রাক্টর চলে যায়, তারা লগআউট জোর করে দিতে পারে।

এখন তিনটি সাধারণ হুমকি যোগ করুন: ভ্যানে শেয়ার করা ট্যাবলেট (কেউ সাইন আউট করতে ভুলে যায়), ফিশিং (স্টাফ ক্রেডেনশিয়াল একটি নকল পেজে টাইপ করে), এবং পোর্টালে gelegentlich একটি XSS বাগ (একটি স্ক্রিপ্ট ব্রাউজারে চালিয়ে যা যা পারে চুরি করে)।

এখানে একটি ব্যবহারিক সেটআপ হল স্বল্প-স্থায়ী অ্যাকসেস টোকেন প্লাস রোটেটিং রিফ্রেশ টোকেন, সার্ভার-সাইড রদবদলের সঙ্গে। এটা আপনাকে দ্রুত API কল ও অফলাইন সহনশীলতা দেয়, একই সময়ে অ্যাডমিনদের সেশন কেটে দেওয়ার ক্ষমতাও দেয়।

এটা কেমন হতে পারে:

• অ্যাকসেস টোকেন লাইফটাইম: 5 থেকে 15 মিনিট।
• রিফ্রেশ টোকেন রোটেশন: প্রতিটি রিফ্রেশে নতুন রিফ্রেশ টোকেন ইস্যু হয়, এবং পুরোনোটি অবৈধ হয়।
• রিফ্রেশ টোকেন নিরাপদে স্টোর করুন: ওয়েবে, রিফ্রেশ টোকেন HttpOnly, Secure কুকিতে রাখুন; মোবাইলে, OS-র সিকিউর স্টোরেজে রাখুন।
• সার্ভার-সাইডে রিফ্রেশ টোকেন ট্র্যাক করুন: একটি টোকেন রেকর্ড (ব্যবহারকারী, ডিভাইস, ইস্যু সময়, লাস্ট-ইউজ, রিভোকড ফ্ল্যাগ) সংরক্ষণ করুন। যদি একটি রোটেট হওয়া টোকেন পুনরায় ব্যবহার করা হয়, এটি চুরি বলে ধরে পুরো চেইন প্রত্যাহার করুন।

জোরপূর্বক লগআউট প্রয়োগযোগ্য হয়ে ওঠে: অ্যাডমিন ঐ ডিভাইসের রিফ্রেশ টোকেন রেকর্ড (বা ব্যবহারকারীর সব ডিভাইস) প্রত্যাহার করে। চুরি করা ডিভাইসটি চলতি অ্যাকসেস টোকেন যতক্ষণ পর্যন্ত বৈধ থাকে ততক্ষণ ব্যবহার করতে পারবে, তবে নতুনটি পাবে না। ফলে পুরো অ্যাক্সেস কাটা পড়ার সর্বোচ্চ সময় হবে আপনার অ্যাকসেস টোকেন লাইফটাইম।

হারানো ডিভাইসের ক্ষেত্রে সুনির্দিষ্ট নিয়ম লিখে দিন: “10 মিনিটের মধ্যে অ্যাপ সিঙ্ক করা বন্ধ করবে এবং আবার সাইন-ইন লাগবে।” অফলাইন কাজ ডিভাইসে থাকা যেতে পারে, কিন্তু পরবর্তী অনলাইন সিঙ্ক ব্যর্থ হবে যতক্ষণ না ব্যবহারকারী আবার সাইন-ইন করে।

পরবর্তী ধাপ: বাস্তবায়ন, পরীক্ষা, এবং রক্ষণযোগ্য রাখা

প্লেইন প্রোডাক্ট ভাষায় আপনি কী বোঝান তা লিখে রাখুন। উদাহরণ: “লগআউট এই ডিভাইস থেকে অ্যাক্সেস মুছবে,” “সবখান থেকে লগআউট 1 মিনিটের মধ্যে সব ডিভাইসকে বের করে দেবে,” বা “পাসওয়ার্ড পরিবর্তন অন্য সেশনগুলোকে লগ আউট করবে।” এই প্রতিশ্রুতিগুলোই নির্ধারণ করে আপনি সার্ভার-সাইড সেশন স্টেট, রদবদল তালিকা, অথবা স্বল্প-স্থায়ী টোকেনের দরকার কিনা।

প্রতিশ্রুতিকে ছোট একটি টেস্ট প্ল্যানে রূপান্তর করুন। টোকেন ও সেশন বাগগুলো প্রায়ই হ্যাপি-পাথ ডেমোতে ঠিক থাকে, কিন্তু বাস্তবে (স্লিপ মোড, খারাপ নেটওয়ার্ক, বহু ডিভাইস) ব্যর্থ হয়।

একটি ব্যবহারিক টেস্ট চেকলিস্ট

গরম কেসগুলো কভার করে এমন টেস্ট চালান:

• এক্সপায়ারি: অ্যাকসেস বন্ধ হয় ঠিক সময়ে যখন অ্যাকসেস টোকেন বা সেশন শেষ হয়, এমনকি ব্রাউজার খোলা থাকলেও।
• রদবদল: “সবখান থেকে লগআউট” করার পরে পুরোনো ক্রেডেনশিয়াল পরবর্তী অনুরোধে ব্যর্থ হয়।
• রোটেশন: রিফ্রেশ টোকেন রোটেশন প্রতিবার নতুন টোকেন ইস্যু করে এবং পুরোনোটি অবৈধ করে।
• রিইউজ ডিটেকশন: পুরোনো রিফ্রেশ টোকেন রেপ্লে করলে লকডাউন প্রতিক্রিয়া ঘটে।
• মাল্টি-ডিভাইস: “এই ডিভাইস মাত্র” বনাম “সব ডিভাইস” নিয়মগুলি প্রয়োগ হয় এবং UI-ও মিলছে কিনা।

টেস্টের পরে, আপনার টিম নিয়ে একটি সহজ আক্রমণ অনুশীলন করুন। তিনটি দৃশ্যমান গল্প বেছে নিয়ে তাদের সম্পূর্ণভাবে অনুসরণ করুন: একটি XSS বাগ যা টোকেন পড়তে পারে, কুকি সেশনের বিরুদ্ধে একটি CSRF চেষ্টা, এবং একটি চুরি হওয়া ফোনে সক্রিয় সেশন। আপনি যাচাই করছেন আপনার ডিজাইন আপনার প্রতিশ্রুতির সাথে মেলে কিনা।

যদি দ্রুত চলতে চান, কাস্টম গ্লু কোড কম রাখুন। AppMaster (appmaster.io) একটি অপশন যখন আপনি একটি জেনারেটেড, প্রোডাকশন-রেডি ব্যাকএন্ড প্লাস ওয়েব ও নেটিভ মোবাইল অ্যাপ চান, যাতে আপনি এক জায়গায় expiry, রোটেশন, ও জোরপূর্বক লগআউটের মতো নিয়মগুলো সমন্বিত রাখতে পারেন।

লঞ্চের পরে একটি ফলো-আপ রিভিউ নির্ধারণ করুন। বাস্তব সাপোর্ট টিকেট ও ঘটনা ব্যবহার করে টাইমআউট, সেশন সীমা, ও “সবখান থেকে লগআউট” আচরণ সমন্বয় করুন, তারপর একই চেকলিস্ট পুনরায় চালান যাতে ফিক্সগুলো regress না করে।