দুটি token একটি সরাসরি দ্বন্দ্ব সমাধানের জন্য থাকে: একটি access token অবশ্যই প্রতিটি request-এ পাঠাতে হয় (তাই এটি অনেক বেশি উন্মুক্ত হয়), অথচ আপনি এমন session-ও চান যা ঘন ঘন লগইন বাধ্য না করে দীর্ঘ সময় টেকে। একটি token-এ নিরাপদে দুটোই পাওয়া যায় না — তাই আপনি কাজটি ভাগ করে দেন।
Authorization header-এ পাঠানো হয়। যেহেতু এটি অবিরত প্রেরিত হয়, ফাঁস হওয়া সম্ভব; এটি ছোট রাখা মানে চুরি যাওয়া token প্রায় সঙ্গে সঙ্গেই মেয়াদোত্তীর্ণ হয়।Login ──▶ access (15m) + refresh (30d)
Every API call ──▶ send access
Access expired ──▶ send refresh ──▶ new access (+ rotated refresh)
| একটি দীর্ঘস্থায়ী access token | Access + refresh | |
|---|---|---|
| উন্মোচন (Exposure) | প্রতি request-এ পাঠানো, দীর্ঘ বাঁচে → বড় চুরির জানালা | Access স্বল্পস্থায়ী; refresh কদাচিৎ পাঠানো |
| Revocation | কঠিন (stateless JWT un-issue করা যায় না) | refresh token revoke করুন; access কয়েক মিনিটেই মরে |
| UX | ছোট হলে ঘন ঘন re-login | credential পুনরায় না দিয়েই লগইন থাকে |
| ফাঁসের ক্ষতির ব্যাপ্তি | বড় | ছোট (access দ্রুত মেয়াদোত্তীর্ণ হয়) |
httpOnly cookie-তে সংরক্ষিত, XSS-এর নাগালের বাইরে।এটিই আধুনিক auth-এর মানক ডিজাইন, এবং ইন্টারভিউয়াররা এটি জিজ্ঞাসা করেন দেখতে যে আপনি কেন-টা বোঝেন, শুধু কীভাবে-টা নয়। মূল অন্তর্দৃষ্টি হলো trade-off: statelessness ও স্বল্প উন্মোচন (access) বনাম দীর্ঘ session ও revocability (refresh)। ভুল করলে — দীর্ঘস্থায়ী access token, কোনো rotation নেই, refresh localStorage-এ সংরক্ষিত — একটি ফাঁস হওয়া token-কে দীর্ঘস্থায়ী account compromise-এ পরিণত করে। বিভাজনটির নাম করা এবং প্রতিটি token আপনাকে কী দেয় তা জানাই একজন নিরাপত্তা-সচেতন ইঞ্জিনিয়ারের কাছ থেকে প্রত্যাশিত।
বিস্তারিত উত্তরসহ IT ইন্টারভিউ প্রশ্নের একটি লাইব্রেরি — জুনিয়র থেকে সিনিয়র পর্যন্ত।
দান করুন