১৯ এপ্রি, ২০২৫·8 মিনিট
আধুনিক ফ্রেমওয়ার্কগুলো কিভাবে প্রমাণীকরণ ও অনুমোদন পরিচালনা করে
জানুন কিভাবে আধুনিক ফ্রেমওয়ার্কগুলো প্রমাণীকরণ ও অনুমোদন বাস্তবায়ন করে: সেশন, টোকেন, OAuth/OIDC, মিডলওয়্যার, রোল, পলিসি এবং প্রধান নিরাপত্তা ঝুঁকি।
জানুন কিভাবে আধুনিক ফ্রেমওয়ার্কগুলো প্রমাণীকরণ ও অনুমোদন বাস্তবায়ন করে: সেশন, টোকেন, OAuth/OIDC, মিডলওয়্যার, রোল, পলিসি এবং প্রধান নিরাপত্তা ঝুঁকি।
প্রমাণীকরণ জবাব দেয় “আপনি কে?”। অনুমোদন জবাব দেয় “আপনি কী করতে পারবেন?” আধুনিক ফ্রেমওয়ার্কগুলো এগুলোকে সম্পর্কযুক্ত কিন্তু আলাদা বিষয় হিসেবে দেখে, এবং এই বিভাজনই অ্যাপ বাড়ার পরও নিরাপত্তা ধারাবাহিক রাখে সাহায্য করে।
প্রমাণীকরণ হলো ব্যবহারকারী (বা সার্ভিস) তাদের দাবিকৃত পরিচয় প্রমাণ করা। ফ্রেমওয়ার্কগুলো সাধারণত একক পদ্ধতি হার্ড-কোড করে না; বরং পাসওয়ার্ড লগইন, সামাজিক লগইন, SSO, API কী, এবং সার্ভিস ক্রিডেনশিয়াল-সহ সাধারণ বিকল্পের জন্য এক্সটেনশন পয়েন্ট দেয়।
প্রমাণীকরণের আউটপুট হলো একটি পরিচয়: একটি ইউজার আইডি, অ্যাকাউন্ট স্ট্যাটাস, এবং কখনো কখনো মৌলিক বৈশিষ্ট্য (যেমন ইমেইল ভেরিফায়েড কি না)। গুরুত্বপূর্ণ: প্রমাণীকরণ সিদ্ধান্ত করা উচিত না যে কোনো কাজ অনুমোদিত—শুধু বলা উচিত কে অনুরোধ করছে।
অনুমোদন প্রতিষ্ঠিত পরিচয় এবং অনুরোধ প্রসঙ্গ (রুট, রিসোর্স মালিক, টিন্যান্ট, স্কোপ, পরিবেশ ইত্যাদি) ব্যবহার করে সিদ্ধান্ত নেয় যে কোনো কর্ম করা যাবে কি না। এখানে রোল, পারমিশন, পলিসি, এবং রিসোর্স-ভিত্তিক নিয়ম থাকে।
ফ্রেমওয়ার্কগুলো অনুমোদন নিয়মগুলোকে প্রমাণীকরণ থেকে আলাদা রাখে যাতে আপনি করতে পারেন:
বেশিরভাগ ফ্রেমওয়ার্ক অনুরোধ লাইফসাইকেলের কেন্দ্রীভূত পয়েন্টগুলোর মাধ্যমে নিয়ম প্রয়োগ করে:
নামগুলো আলাদা হলেও, নির্মাণ ব্লকগুলো পরিচিত: একটি identity store (ব্যবহারকারী ও ক্রেডেনশিয়াল), একটি session বা token যা অনুরোধগুলোর মধ্যে পরিচয় বহন করে, এবং middleware/guards যা ধারাবাহিকভাবে প্রমাণীকরণ ও অনুমোদন জারি করে।
এই লেখার উদাহরণগুলো ধারণাগত রাখা হয়েছে যাতে আপনি এগুলোকে আপনার পছন্দের ফ্রেমওয়ার্কে ম্যাপ করতে পারেন।
কোনো ফ্রেমওয়ার্ক কাউকে “লগ ইন” করানোর আগে দুইটি জিনিস লাগে: পরিচয় ডেটা খুঁজে দেখবার জায়গা (identity store) এবং কোডে ঐ পরিচয় উপস্থাপনার ধারাবাহিক উপায় (user model)। অনেক “অথেনটিকেশন ফিচার” আধুনিক ফ্রেমওয়ার্কে এই দুই অংশকে ঘিরে অ্যাবস্ট্রাকশন।
ফ্রেমওয়ার্কগুলো সাধারণত একাধিক ব্যাকএন্ড সমর্থন করে, বিল্ট-ইন বা প্লাগইনের মাধ্যমে:
মূল পার্থক্য হলো কে সত্যি সূত্র। ডেটাবেস ইউজারসের ক্ষেত্রে আপনার অ্যাপ ক্রেডেনশিয়াল এবং প্রোফাইল ডেটার মালিক। IdP বা ডিরেক্টরির সাথে, আপনার অ্যাপ প্রায়ই একটি “লোকাল শ্যাডো ইউজার” সংরক্ষণ করে যা বাহ্যিক পরিচয়ের সাথে লিংক করে।
যখন ফ্রেমওয়ার্ক ডিফল্ট ইউজার মডেল জেনারেট করে, বেশিরভাগ দল কয়েকটি ফিল্ড স্ট্যান্ডার্ড করে:
is_verified, is_active, is_locked, deleted_at.এই ফ্ল্যাগগুলো গুরুত্বপূর্ণ কারণ প্রমাণীকরণ শুধু “ঠিক পাসওয়ার্ড?” নয়—এর সাথে “এই অ্যাকাউন্ট কি এখন সাইন ইন করার জন্য অনুমোদিত?”-ও জড়িত।
প্রায়োগিক পরিচয় স্টোর সাধারণ লাইফসাইকেল ইভেন্টগুলো সমর্থন করে: রেজিস্ট্রেশন, ইমেইল/ফোন ভেরিফিকেশন, পাসওয়ার্ড রিসেট, সংবেদনশীল পরিবর্তনের পর সেশন বাতিলকরণ, এবং নিষ্ক্রিয়করণ বা সফট-ডিলেট। ফ্রেমওয়ার্কগুলো প্রায়ই প্রিমিটিভ (টোকেন, টাইমস্ট্যাম্প, হুক) দেয়, কিন্তু আপনি নিয়ম নির্ধারণ করেন: মেয়াদ উত্তীর্ণ উইন্ডো, রেট লিমিট, এবং অ্যাকাউন্ট নিষ্ক্রিয় হলে বিদ্যমান সেশনগুলোর জন্য কি হবে।
অধিকাংশ আধুনিক ফ্রেমওয়ার্ক user providers, adapters, বা repositories-এর মতো এক্সটেনশন পয়েন্ট দেয়। এই কম্পোনেন্টগুলো অনুবাদ করে “কোনো লগইন শনাক্তকারী দেওয়া হলে, ইউজার খুঁজে আনো” এবং “কোন ইউজার আইডি দিলে, বর্তমান ইউজার লোড করো”—সেই স্টোরে যা আপনি বেছে নিয়েছেন, হোক তা SQL কুয়েরি, এক IdP কল, বা এন্টারপ্রাইজ ডিরেক্টরি লুকআপ।
সেশন-ভিত্তিক প্রমাণীকরণ হল ক্লাসিক পদ্ধতি যা অনেক ওয়েব ফ্রেমওয়ার্ক এখনও ডিফল্ট হিসেবে ব্যবহার করে—বিশেষ করে সার্ভার-রেন্ডার্ড অ্যাপগুলোর জন্য। ধারণা সহজ: সার্ভার মনে রাখে আপনি কে, আর ব্রাউজার সেই স্মৃতির একটি ছোট পয়েন্টার রাখে।
সফল লগইনের পরে, ফ্রেমওয়ার্ক সার্ভার-সাইডে একটি সেশন রেকর্ড তৈরি করে (প্রায়শই র্যান্ডম সেশন আইডি ইউজারের সাথে ম্যাপ করে)। ব্রাউজার সেই সেশন আইডি ধারণকারী কুকি পায়। প্রতিটি অনুরোধে ব্রাউজার স্বয়ংক্রিয়ভাবে কুকিটি পাঠায়, এবং সার্ভার সেটি ব্যবহার করে লগ-ইন করা ব্যবহারকারী খুঁজে পায়।
কারণ কুকি শুধুমাত্র একটি শনাক্তকারী (পরিচয় সূচক), সংবেদনশীল তথ্য সার্ভারের উপরেই থাকে।
আধুনিক ফ্রেমওয়ার্কগুলো সেশন কুকিগুলো আরও চুরি প্রতিরোধী করতে নিরাপদ ডিফল্ট দেয়:
আপনি প্রায়ই এগুলোকে “session cookie settings” বা “security headers”-এর অধীনে কনফিগার করা দেখতে পাবেন।
ফ্রেমওয়ার্কগুলো সাধারণত আপনাকে সেশন স্টোর বেছে নিতে দেয়:
উপরে সাধারণত ট্রেড-অফ হলো গতি বনাম টেকসইতা বনাম অপারেশনাল জটিলতা।
লগআউটের মানে দুইভাবে হতে পারে:
ফ্রেমওয়ার্কগুলো প্রায়ই “সব জায়গা থেকে লগআউট” ইমপ্লিমেন্ট করতে ইউজার “সেশন ভার্সন” ট্র্যাক করে, একাধিক সেশন আইডি সংরক্ষণ করে, এবং সেগুলো রিভোক করে। যদি আপনি তাত্ক্ষণিক রিভোকেশন চান, সেশন-ভিত্তিক অথ টোকেনের তুলনায় সাধারণত সহজ—কারণ সার্ভার একটি সেশন তাত্ক্ষণিকভাবে ভুলে যেতে পারে।
টোকেন-ভিত্তিক প্রমাণীকরণ সার্ভার-সাইড সেশন লুকআপকে প্রতিস্থাপন করে এমন একটি স্ট্রিং ব্যবহার করে যা ক্লায়েন্ট প্রতিটি অনুরোধে উপস্থাপন করে। ফ্রেমওয়ার্কগুলো সাধারণত টোকেনগুলো তখন সুপারিশ করে যখন আপনার সার্ভার মূলত একটি API (বহু ক্লায়েন্ট দ্বারা ব্যবহৃত), মোবাইল অ্যাপ আছে, SPA আলাদা ব্যাকএন্ডকে কল করে, অথবা সার্ভিসগুলোর মধ্যে কল করার দরকার আছে বেভার ব্রাউজার সেশন ছাড়া।
একটি টোকেন হলো লগইনের পরে ইস্যু করা একটি অ্যাক্সেস ক্রেডেনশিয়াল (বা OAuth ফ্লো পরবর্তী)। ক্লায়েন্ট তা পরবর্তিতে পাঠায় যাতে সার্ভার কলারকে প্রমাণীকৃত মনে করে এবং তারপর অ্যাকশনকে অনুমোদন করে। অধিকাংশ ফ্রেমওয়ার্ক এটিকে এক-প্রকার প্যাটার্ন হিসেবে বিবেচনা করে: একটি “issue token” এন্ডপয়েন্ট, টোকেন যাচাই করা মिडলওয়্যার, এবং পরিচয় প্রতিষ্ঠিত হওয়ার পরে চালু হওয়া গার্ড/পলিসি।
Opaque tokens হল র্যান্ডম স্ট্রিং যেগুলো ক্লায়েন্টের পক্ষে কোনো অর্থ বহন করে না (যেমন tX9...)। সার্ভার সেগুলোকে ডাটাবেস বা কেশ এন্ট্রি দেখে ভ্যালিডেট করে। এভাবে রিভোকেশন সহজ হয় এবং টোকেনের কনটেন্ট গোপন থাকে।
JWTs (JSON Web Tokens) গঠিত এবং সাইনড। একটি JWT সাধারণত ক্লেইমস ধারণ করে যেমন ইউজার আইডেন্টিফায়ার (sub), ইস্যু করা (iss), অডিয়েন্স (aud), ইস্যু/মেয়াদ (iat, exp), এবং কখনো কখনো রোল/স্কোপ। গুরুত্বপূর্ণ: JWTs ডিফল্টভাবে এনক্রিপ্ট করা নয়—তাই টোকেন ধরলে সেটির ক্লেইম পড়তে পারা যায়, যদিও তারা জাল করা না যায়।
ফ্রেমওয়ার্কের গাইডলাইন সাধারণত দুইটি নিরাপদ ডিফল্টের দিকে convergence করে:
Authorization: Bearer \u003ctoken\u003e হেডারের মাধ্যমে অ্যাক্সেস টোকেন পাঠান। এতে স্বয়ংক্রিয়ভাবে পাঠিয়ে দেওয়া কুকি সম্পর্কিত CSRF ঝুঁকি কমে, কিন্তু XSS প্রতিরোধ আরও কড়া রাখা লাগে কারণ জাভাস্ক্রিপ্ট সাধারণত টোকেন পড়ে এটাচ করতে পারে।HttpOnly, Secure, এবং SameSite বানাতে পারেন, এবং যখন আপনি CSRF সঠিকভাবে হ্যান্ডেল করতে প্রস্তুত (সাধারণত আলাদা CSRF টোকেনের সঙ্গে)।অ্যাক্সেস টোকেনগুলো সংক্ষেপে রাখা হয়। ক্রমাগত লগইন বাধ্য করা এড়াতে, অনেক ফ্রেমওয়ার্ক refresh tokens সমর্থন করে: দীর্ঘমেয়াদি ক্রেডেনশিয়াল যা কেবল নতুন অ্যাক্সেস টোকেন তৈরিতে ব্যবহৃত হয়।
একটি সাধারণ কাঠামো:
POST /auth/login → অ্যাক্সেস টোকেন (এবং রিফ্রেশ টোকেন) রিটার্ন করেPOST /auth/refresh → রিফ্রেশ টোকেন রোটেট করে এবং নতুন অ্যাক্সেস টোকেন রিটার্ন করেPOST /auth/logout → সার্ভার-সাইডে রিফ্রেশ টোকেন অবৈধ করেরোটেশন (প্রতিবার নতুন রিফ্রেশ টোকেন ইস্যু করা) চুরি হলে ক্ষতি সীমিত করে এবং অনেক ফ্রেমওয়ার্ক টোকেন আইডেন্টিফায়ার স্টোর করার, পুনঃব্যবহার শনাক্ত করার, এবং দ্রুত রিভোক করার হুক দেয়।
OAuth 2.0 এবং OpenID Connect (OIDC) প্রায়ই একসাথে বলা হয়, কিন্তু ফ্রেমওয়ার্কগুলো এগুলোকে আলাদা ভাবে দেখে কারণ এগুলো ভিন্ন সমস্যা সমাধান করে।
OAuth 2.0 ব্যবহার করুন যখন আপনি ডেলিগেটেড অ্যাক্সেস চান: আপনার অ্যাপ ব্যবহারকারীর পক্ষে একটি API কল করার অনুমতি পায় (উদাহরণ: ক্যালেন্ডার পড়া বা রিপোতে পোস্ট করা) চরম হিসেব না নিয়ে।
OpenID Connect ব্যবহার করুন যখন আপনি লগইন/পরিচয় চান: আপনার অ্যাপ জানতে চায় ব্যবহারকারী কে এবং একটি ID টোকেন পেতে চায় পরিচয় ক্লেইমসহ। বাস্তবে, “Login with X” সাধারণত OIDC যা OAuth 2.0-এর ওপরে।
অধিকাংশ আধুনিক ফ্রেমওয়ার্ক এবং তাদের অথ লাইব্রেরি দুইটি ফ্লোতে ফোকাস করে:
ফ্রেমওয়ার্ক ইন্টিগ্রেশন সাধারণত একটি কোলব্যাক রুট এবং হেল্পার মিডলওয়্যার দেয়, কিন্তু আপনাকে এখনও সঠিকভাবে কনফিগার করতে হবে:
ফ্রেমওয়ার্কগুলো সাধারণত প্রোভাইডার ডেটা লোকাল ইউজার মডেলে নরমালাইজ করে। মূল ডিজাইন সিদ্ধান্ত হলো কি চলমানভাবে অনুমোদন চালায়:
একটি সাধারণ প্যাটার্ন: স্থিতিশীল শনাক্তকারী (যেমন sub) লোকাল ইউজারের সাথে ম্যাপ করা, তারপর প্রোভাইডার রোল/গ্রুপ/ক্লেইমগুলোকে আপনার অ্যাপের লোকাল রোল বা পলিসিতে অনুবাদ করা।
পাসওয়ার্ড এখনও অনেক অ্যাপের ডিফল্ট সাইন-ইন পদ্ধতি, তাই ফ্রেমওয়ার্কগুলো সাধারণত নিরাপদ স্টোরেজ প্যাটার্ন এবং সাধারণ গার্ডরেইলস নিয়ে আসে। মূল নিয়ম অপরিবর্তিত: কখনোই পাসওয়ার্ড (বা সরল হ্যাশ) ডাটাবেসে সংরক্ষণ করবেন না।
আধুনিক ফ্রেমওয়ার্ক এবং তাদের অথ লাইব্রেরি সাধারণত bcrypt, Argon2, বা scrypt-এর মতো উদ্দেশ্যভিত্তিক পাসওয়ার্ড হ্যাশার ডিফল্ট করে। এই অ্যালগরিদমগুলো ইচ্ছাকৃতভাবে ধীর এবং salting অন্তর্ভুক্ত করে, যা প্রিকম্পিউটেড টেবিল আক্রমণ প্রতিরোধ করে এবং বড়-অস্তরের ক্র্যাকিংকে ব্যয়বহুল করে।
একটি সাধারণ ক্রিপ্টোগ্রাফিক হ্যাশ (যেমন SHA-256) পাসওয়ার্ডের জন্য নিরাপদ নয় কারণ এটি দ্রুত—ডেটাবেস লিক হলে দ্রুত হাজার কোটি পাসওয়ার্ড অনুমান করা যায়। পাসওয়ার্ড হ্যাশাররা ওয়ার্ক ফ্যাক্টর (কস্ট প্যারামিটার) দেয় যাতে হার্ডওয়্যার উন্নতির সাথে আপনি সুরক্ষা টিউন করতে পারেন।
ফ্রেমওয়ার্কগুলো সাধারণত হুক (বা মিডলওয়্যার/প্লাগইন) দেয় যে সুনির্দিষ্ট নিয়মগুলো প্রতিটি এন্ডপয়েন্টে হার্ড-কোড না করে প্রয়োগ করতে সাহায্য করে:
অধিকাংশ ইকোসিস্টেম পাসওয়ার্ড যাচাইকরণের পরে এমএফএ যোগ করার অপশন দেয়:
পাসওয়ার্ড রিসেট একটি সাধারণ আক্রমণ পথ, তাই ফ্রেমওয়ার্কগুলো সাধারণত এই ধরণের প্যাটার্নগুলো উৎসাহ দেয়:
একটি ভাল নিয়ম: বৈধ ব্যবহারকারীর জন্য পুনরুদ্ধার সহজ করুন, কিন্তু আক্রমণকারীর জন্য স্বয়ংক্রিয়ভাবে ব্যয়বহুল করুন।
অধিকাংশ আধুনিক ফ্রেমওয়ার্ক নিরাপত্তাকে অনুরোধ পাইপলাইনের অংশ হিসেবে বিবেচনা করে: ধাপে ধাপে কিছু স্টেপ যা আপনার কন্ট্রোলারের আগে (এবং কখনো কখনো পরে) চলে। নামগুলো ভিন্ন হতে পারে—middleware, filters, guards, interceptors—কিন্তু ধারণা একই: প্রতিটি ধাপ অনুরোধ পড়তে পারে, প্রাসঙ্গিক কনটেক্সট যোগ করতে পারে, বা প্রসেসিং বন্ধ করে দিতে পারে।
একটি সাধারণ ফ্লো দেখতে এমনায়:
/account/settings)।ফ্রেমওয়ার্কগুলো উৎসাহ দেয় আপনি সিকিউরিটি চেকগুলোকে ব্যবসায়িক লজিকের বাইরে রাখুন, যাতে কন্ট্রোলারগুলি “কি করতে হবে” নিয়ে ফোকাসেড থাকে, “কে করতে পারে” নিয়ে নয়।
প্রমাণীকরণ হল সেই ধাপ যেখানে ফ্রেমওয়ার্ক কুকি, সেশন আইডি, API কী, অথবা বিয়ারার টোকেন থেকে ইউজার কনটেক্সট প্রতিষ্ঠা করে। সফল হলে এটি একটি অনুরোধ-স্কোপড পরিচয় তৈরি করে—প্রায়শই user, principal, বা context.auth নামে এক অবজেক্ট হিসেবে এক্সপোজ করা হয়।
এই সংযুক্তি গুরুত্বপূর্ণ কারণ পরবর্তী ধাপগুলো (এবং আপনার অ্যাপ কোড) হেডার পুনরায় পার্স করা বা টোকেন পুনরায় যাচাই করা উচিত নয়। তারা ইতিমধ্যে পূরণকৃত user অবজেক্ট পড়া উচিৎ, যা সাধারণত অন্তর্ভুক্ত করে:
অনুমোদন সাধারণত হিসেবে বাস্তবায়িত হয়:
দ্বিতীয় ধরণই ব্যাখ্যা করে কেন অনুমোদন হুকগুলো প্রায়শই কন্ট্রোলার ও সার্ভিসের কাছাকাছি থাকে: সঠিক সিদ্ধান্ত নিতে তাদের রুট প্যারামিটার বা ডাটাবেস-লোড করা অবজেক্ট প্রয়োজন হতে পারে।
ফ্রেমওয়ার্কগুলো সাধারণত দুটি সাধারণ ব্যর্থতা মোড আলাদা করে:
ভাল-ডিজাইন করা সিস্টেমগুলো 403 রেসপন্সে বিস্তারিত তথ্য প্রকাশ করা এড়ায়; তারা যেই নিয়ম ব্যর্থ হয়েছে তা ব্যাখ্যা না করে অ্যাক্সেস অস্বীকার করে।
অনুমোদন প্রশ্নের উত্তর দেয়: “এই সাইন-ইন করা ব্যবহারকারী এখন নির্দিষ্টভাবে এটি করতে পারবে কি?” আধুনিক ফ্রেমওয়ার্কগুলো সাধারণত একাধিক মডেল সমর্থন করে, এবং অনেক দল এগুলো সংমিশ্রণ করে।
RBAC ব্যবহারকারীকে এক বা একাধিক রোল (যেমন admin, support, member) দেয় এবং ঐ রোলের উপর ভিত্তি করে ফিচার গেট করে।
এটি বোঝা সহজ এবং দ্রুত ইমপ্লিমেন্ট করা যায়, বিশেষত যখন ফ্রেমওয়ার্ক requireRole('admin')-এর মতো হেল্পার দেয়। রোল হায়ারার্কি (“admin implies manager implies member”) ডুপ্লিকেশন কমাতে পারে, কিন্তু সুবিধা লুকিয়ে রাখতে পারে: একটি প্যারেন্ট রোলের ছোট পরিবর্তন সাইলেন্টলি অ্যাপ জুড়ে প্রবেশাধিকার বাড়িয়ে দিতে পারে।
RBAC বড়, স্থিতিশীল বিভাজনের জন্য সেরা।
পারমিশন-ভিত্তিক অনুমোদন কোনো অ্যাকশনের বিরুদ্ধে রিসোর্স চেক করে, প্রায়শই প্রকাশ করা হয়:
read, create, update, delete, inviteinvoice, project, user, কখনো কখনো আইডি বা মালিকানা সহএই মডেলটি RBAC-এর তুলনায় আরও নির্ভুল। উদাহরণ: “প্রজেক্ট সম্পাদনা করতে পারে” এবং “শুধু তাদের নিজের প্রজেক্ট সম্পাদনা করতে পারে” আলাদা—যার জন্য পারমিশন এবং ডাটা শর্ত দুটোই চেক করতে হয়।
ফ্রেমওয়ার্কগুলো প্রায়ই একটি কেন্দ্রীয় “can?” ফাংশন (বা সার্ভিস) বাস্তবায়ন করে যা কন্ট্রোলার, রিজলভার, ওয়ার্কার, বা টেমপ্লেট থেকে ডাকা হয়।
পলিসি পুনরায় ব্যবহারযোগ্য ইভ্যালুয়েটর হিসেবে অনুমোদন লজিক প্যাক করে: “একজন ব্যবহারকারী মন্তব্য মুছতে পারে যদি তিনি সেটি লিখেছেন বা তিনি একজন মডারেটর।” পলিসি কনটেক্সট (ব্যবহারকারী, রিসোর্স, অনুরোধ) নেয় এবং তাই তারা উপযুক্ত:
যখন ফ্রেমওয়ার্ক পলিসিগুলো রাউটিং ও মিডলওয়্যারে ইন্টিগ্রেট করে, আপনি নিয়মগুলো ধারাবাহিকভাবে সব এন্ডপয়েন্টে বলবৎ করতে পারেন।
অ্যানোটেশন (যেমন @RequireRole('admin')) হ্যান্ডলারকে কাছাকাছি রাখতে উদ্দেশ্য রাখে, কিন্তু নিয়ম জটিল হলে ফ্র্যাগমেন্টেড হয়ে উঠতে পারে।
কোড-ভিত্তিক চেক (অথাৎ অথোরাইজারকে স্পষ্টভাবে কল করা) বেশ বর্ণনামূলক, কিন্তু পরীক্ষায় ও রিফ্যাক্টরে সহজ। সাধারণ সমঝোতা হলো কোর্স গেটের জন্য অ্যানোটেশন এবং জটিল লজিকের জন্য পলিসি।
আধুনিক ফ্রেমওয়ার্কগুলো কেবল ইউজার লগইন করাতেই সাহায্য করে না—তারা অথেন্টিকেশনের চারপাশে ঘটা সবচেয়ে সাধারণ "ওয়েব গ্লু" আক্রমণের বিরুদ্ধে প্রতিরোধও দেয়।
আপনার অ্যাপ যদি সেশন কুকি ব্যবহার করে, ব্রাউজার অটোম্যাটিকভাবে সেগুলো অনুরোধে যোগ করে—কখনো কখনো এমন অনুরোধ অন্য একটি সাইট থেকে ট্রিগার হলেও। ফ্রেমওয়ার্ক CSRF সুরক্ষা সাধারণত একটি প্রতি-সেশন (বা প্রি-রেকয়েস্ট) CSRF টোকেন যোগ করে যা স্টেট-চেঞ্জিং অনুরোধের সাথে পাঠাতে হয়।
সাধারণ প্যাটার্নগুলো:
CSRF টোকেনকে SameSite কুকির (প্রায়শই Lax ডিফল্ট) সঙ্গে জোড়া করুন ঝুঁকি কমাতে, এবং নিশ্চিত করুন আপনার সেশন কুকি যেখানে উপযুক্ত সেখানে HttpOnly ও Secure।
CORS একটি অথ মেকানিজম নয়; এটি ব্রাউজারের অনুমতি সিস্টেম। ফ্রেমওয়ার্কগুলো সাধারণত মিডলওয়্যার/কনফিগ দেয় যাতে নির্ভরযোগ্য উত্সগুলোকে আপনার API কল করতে দেয়া যায়।
ভুল কনফিগারেশনের কিছু উদাহরণ এড়িয়ে চলুন:
Access-Control-Allow-Origin: * এর সাথে Access-Control-Allow-Credentials: true (ব্রাউজার প্রত্যাখ্যান করবে, এবং এটি বিভ্রান্তি নির্দেশ করে)।Origin হেডারই রিফ্লেক্ট করা, কঠোর allowlist না থাকা।Authorization) বা মেথড অনুমোদন না করা, ফলে ক্লায়েন্ট "curl-এ চলে কিন্তু ব্রাউজারে ব্যর্থ" অভিজ্ঞতা পায়।অধিকাংশ ফ্রেমওয়ার্ক নিরাপদ ডিফল্ট সেট করার সুবিধা দেয় বা সহজে হেডার যোগ করার পথ দেয়, যেমন:
X-Frame-Options অথবা Content-Security-Policy: frame-ancestors ক্লিকজ্যাকিং রোধ করতে।Content-Security-Policy (বৃহত্তর স্ক্রিপ্ট/রিসোর্স কন্ট্রোল)।Referrer-Policy এবং X-Content-Type-Options: nosniff ব্রাউজার আচরণ নিরাপদ রাখে।ভ্যালিডেশন ডেটা সঠিক ফর্ম্যাটে আছে কি না নিশ্চিত করে; অনুমোদন চেক করে ব্যবহারকারী কি এগুলো করতে পারে। একটি বৈধ অনুরোধ এখনও নিষিদ্ধ হতে পারে—ফ্রেমওয়ার্ক সবচেয়ে ভাল কাজ করে যখন আপনি দুটোই প্রয়োগ করবেন: ইনপুট দ্রুত ভ্যালিডেট করুন, তারপর নির্দিষ্ট রিসোর্সে পারমিশন জোড়া দিন।
“সঠিক” অথ প্যাটার্ন কড়ানোভাবে নির্ভর করে কোড কোথায় রান করে এবং অনুরোধ কিভাবে আপনার ব্যাকএন্ড পৌঁছে। ফ্রেমওয়ার্কগুলো অনেক বিকল্প সমর্থন করতে পারে, কিন্তু এক অ্যাপ টাইপের ডিফল্ট অন্যটিতে অদ্ভুত বা ঝুঁকিপূর্ণ হতে পারে।
SSR ফ্রেমওয়ার্কগুলো সাধারণত কুকি-ভিত্তিক সেশনগুলোর সাথে ভাল জোড়ে। ব্রাউজার কুকি স্বয়ংক্রিয়ভাবে পাঠায়, সার্ভার সেশন লুকআপ করে, এবং পেজগুলো ইউজার কনটেক্সট নিয়ে রেন্ডার করতে পারে অতিরিক্ত ক্লায়েন্ট কোড ছাড়াই।
প্রায়োগিক নিয়ম: সেশন কুকি HttpOnly, Secure, এবং উপযুক্ত SameSite দিয়ে রাখুন, এবং ব্যক্তিগত ডেটা রেন্ডার করার প্রতিটি অনুরোধে সার্ভার-সাইড অনুমোদন চেক করুন।
SPA-গুলো প্রায়শই জাভাস্ক্রিপ্ট থেকে API কল করে, যা টোকেন পছন্দগুলো স্পষ্ট করে তোলে। অনেক দল ছোট-মেয়াদী অ্যাক্সেস টোকেন সহ OAuth/OIDC ফ্লো পছন্দ করে।
যদি সম্ভব দীর্ঘমেয়াদি টোকেন localStorage-এ রাখা এড়ান; এটি XSS-এর বিস্তার বাড়ায়। একটি সাধারণ বিকল্প হলো BFF (backend-for-frontend) প্যাটার্ন: SPA আপনার সার্ভারের সাথে সেশন কুকি দিয়ে কথা বলে, এবং সার্ভার upstream APIs-এর জন্য টোকেন এক্সচেঞ্জ/ধারণ করে।
মোবাইল অ্যাপ ব্রাউজারের কুকি নিয়মের উপর নির্ভর করতে পারে না। তারা সাধারণত PKCE সহ OAuth/OIDC ব্যবহার করে, এবং রিফ্রেশ টোকেন প্ল্যাটফর্মের নিরাপদ স্টোরেজে রাখে (Keychain/Keystore)।
"হারিয়ে যাওয়া ডিভাইস" পুনরুদ্ধারের পরিকল্পনা করুন: রিফ্রেশ টোকেন রিভোক করুন, ক্রেডেনশিয়াল রোটেট করুন, এবং এমএফএ সক্রিয় থাকলে পুনরায় অথেন্টিকেশন সহজ করুন।
বহু সার্ভিস থাকলে, আপনি কেন্দ্রীভূত পরিচয় বনাম সার্ভিস-লেভেল বহুল প্রয়োগের মধ্যে নির্বাচন করবেন:
সার্ভিস-টু-সার্ভিস অথের জন্য, ফ্রেমওয়ার্কগুলো সাধারণত mTLS (চ্যানেল আইডেন্টিটি) বা OAuth client credentials (সার্ভিস অ্যাকাউন্ট)-এর সঙ্গে ইন্টিগ্রেট করে। লক্ষ্য হলো কলারকে প্রমাণীকৃত করা এবং এটি কি করতে পারে তা অনুমোদন করা।
অ্যাডমিন "ইম্পার্সনেট ইউজার" ফিচার শক্তিশালী কিন্তু বিপজ্জনক। স্পষ্ট ইম্পার্সনেশন সেশন পছন্দ করুন, অ্যাডমিনদের জন্য পুনঃঅথেনটিকেশন/এমএফএ বাধ্যতামূলক রাখুন, এবং সবসময় অডিট লগ লিখুন (কে কাকে ইম্পার্সনেট করল, কখন, এবং কি অ্যাকশন নেয়া হলো)।
নিরাপত্তা ফিচারগুলো শুধুমাত্র কার্যকর থাকবে যদি কোড পরিবর্তন হলে এগুলো ঠিকঠাক কাজ করে। আধুনিক ফ্রেমওয়ার্কগুলো অথেনটিকেশন ও অথোরাইজেশন টেস্ট করা সহজ করে, কিন্তু আপনাকে এমন টেস্ট দরকার যা বাস্তব ব্যবহারকারী আচরণ—এবং বাস্তব আক্রমণকারীর আচরণ—প্রতিফলিত করে।
শুরু করুন কি টেস্ট করবেন তা আলাদা করে:
অধিকাংশ ফ্রেমওয়ার্ক টেস্ট হেল্পার দিয়ে আসে যাতে আপনি প্রতিবার সেশন বা টোকেন হ্যান্ড-রোল না করতে পারেন। সাধারণ প্যাটার্নগুলো:
প্রায়োগিক নিয়ম: প্রতিটি “হ্যাপি পাথ” টেস্টের জন্য একটি “অস্বীকৃত হওয়া দরকার” টেস্ট যোগ করুন যাতে প্রমাণ হয় অনুমোদন চেকটি আসলে চলছে।
কিছু ভুল হলে দ্রুত ও আত্মবিশ্বাসের সঙ্গে উত্তর পেতে চান।
কী ইভেন্ট লগ বা অডিট করুন:
হালকা ওজনের মেট্রিকও রাখুন: 401/403 রেসপন্সের হার, ব্যর্থ লগইন স্পাইক, এবং অস্বাভাবিক টোকেন রিফ্রেশ প্যাটার্ন।
অথ বাগগুলোকে টেস্টযোগ্য আচরণ হিসেবে দেখুন: যদি এটা regress করতে পারে, তবে এর জন্য একটি টেস্ট থাকা উচিত।
Authentication proves identity (who is making the request). Authorization decides access (what that identity may do) using context like route, resource ownership, tenant, and scopes.
Frameworks separate them so you can change sign-in methods without rewriting permission logic.
Most frameworks enforce auth in a request pipeline, typically with:
user/principalAn identity store is the source of truth for users and credentials (or links to external identities). A user model is how your code represents that identity.
In practice, frameworks need both to answer: “given this identifier/token, who is the current user?”
Common sources include:
When using an IdP/directory, many apps keep a “shadow user” locally to map stable external IDs (like OIDC sub) to app-specific roles and data.
Sessions store identity server-side and use a cookie as a pointer (session ID). They’re great for SSR and make revocation simple.
Tokens (JWT/opaque) are sent on each request (often via Authorization: Bearer ...) and fit APIs, SPAs, mobile, and service-to-service use cases.
Frameworks typically harden session cookies with:
HttpOnly (reduces cookie theft via XSS)Secure (HTTPS only)SameSite (limits cross-site sending; affects CSRF and login flows)You still need to choose values appropriate for your app (e.g., vs for cross-site flows).
Opaque tokens are random strings validated by a server lookup (easy revocation, private contents).
JWTs are signed, self-contained tokens with readable claims (e.g., sub, exp, roles/scopes). They’re convenient for distributed systems, but revocation is harder unless you add short expirations and server-side controls (deny lists, token versioning, etc.).
Keep access tokens short-lived, and use refresh tokens only to mint new access tokens.
Common endpoints:
POST /auth/login → access + refreshPOST /auth/refresh → rotate refresh token + issue new accessPOST /auth/logout → invalidate refresh tokensRotation plus reuse detection limits damage if a refresh token leaks.
OAuth 2.0 is for delegated API access (“let this app call an API for me”).
OpenID Connect (OIDC) is for login/identity (“who is the user?”) and adds ID tokens and standardized identity claims.
“Login with X” is typically OIDC built on OAuth 2.0.
RBAC (roles) is simple for broad gates (e.g., admin vs member). Permissions/policies handle fine-grained rules (e.g., edit only your own document).
A common pattern is:
LaxNone