আধুনিক ফ্রেমওয়ার্কগুলো কিভাবে প্রমাণীকরণ ও অনুমোদন পরিচালনা করে

প্রমাণীকরণ বনাম অনুমোদন: ফ্রেমওয়ার্কগুলো সাধারণত কীভাবে আলাদা করে

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

প্রমাণীকরণ: পরিচয় প্রতিষ্ঠা করা

প্রমাণীকরণ হলো ব্যবহারকারী (বা সার্ভিস) তাদের দাবিকৃত পরিচয় প্রমাণ করা। ফ্রেমওয়ার্কগুলো সাধারণত একক পদ্ধতি হার্ড-কোড করে না; বরং পাসওয়ার্ড লগইন, সামাজিক লগইন, SSO, API কী, এবং সার্ভিস ক্রিডেনশিয়াল-সহ সাধারণ বিকল্পের জন্য এক্সটেনশন পয়েন্ট দেয়।

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

অনুমোদন: প্রবেশাধিকার নির্ধারণ

অনুমোদন প্রতিষ্ঠিত পরিচয় এবং অনুরোধ প্রসঙ্গ (রুট, রিসোর্স মালিক, টিন্যান্ট, স্কোপ, পরিবেশ ইত্যাদি) ব্যবহার করে সিদ্ধান্ত নেয় যে কোনো কর্ম করা যাবে কি না। এখানে রোল, পারমিশন, পলিসি, এবং রিসোর্স-ভিত্তিক নিয়ম থাকে।

ফ্রেমওয়ার্কগুলো অনুমোদন নিয়মগুলোকে প্রমাণীকরণ থেকে আলাদা রাখে যাতে আপনি করতে পারেন:

• লগইন পদ্ধতি পরিবর্তন করা ছাড়াই অ্যাক্সেস নিয়মগুলো না লিখে পুনরায় ব্যবহার করা
• ওয়েব পেজ, API, এবং ব্যাকগ্রাউন্ড জবগুলোর উপর ধারাবাহিক অনুমতি চেক প্রয়োগ করা
• “আপনি কে” লজিককে “আপনি কী করতে পারেন” লজিক থেকে আলাদা রাখা

কার্যকর করার পয়েন্টগুলো: ফ্রেমওয়ার্ক কোথায় নিয়ম প্রয়োগ করে

বেশিরভাগ ফ্রেমওয়ার্ক অনুরোধ লাইফসাইকেলের কেন্দ্রীভূত পয়েন্টগুলোর মাধ্যমে নিয়ম প্রয়োগ করে:

• Middleware/filters/interceptors যা কন্ট্রোলার/হ্যান্ডলারগুলোর আগে চলে
• Guards যা রুট বা অ্যাকশনে প্রবেশ বন্ধ করে
• Policy checks যা ব্যবসায়িক লজিকের ভিতরে রিসোর্স-নির্দিষ্ট সিদ্ধান্তের জন্য ডাকা হয়

সাধারণ নির্মাণ ব্লক (ফ্রেমওয়ার্ক-অ্যাগনোস্টিক)

নামগুলো আলাদা হলেও, নির্মাণ ব্লকগুলো পরিচিত: একটি identity store (ব্যবহারকারী ও ক্রেডেনশিয়াল), একটি session বা token যা অনুরোধগুলোর মধ্যে পরিচয় বহন করে, এবং middleware/guards যা ধারাবাহিকভাবে প্রমাণীকরণ ও অনুমোদন জারি করে।

এই লেখার উদাহরণগুলো ধারণাগত রাখা হয়েছে যাতে আপনি এগুলোকে আপনার পছন্দের ফ্রেমওয়ার্কে ম্যাপ করতে পারেন।

পরিচয় স্টোর এবং ইউজার মডেল

কোনো ফ্রেমওয়ার্ক কাউকে “লগ ইন” করানোর আগে দুইটি জিনিস লাগে: পরিচয় ডেটা খুঁজে দেখবার জায়গা (identity store) এবং কোডে ঐ পরিচয় উপস্থাপনার ধারাবাহিক উপায় (user model)। অনেক “অথেনটিকেশন ফিচার” আধুনিক ফ্রেমওয়ার্কে এই দুই অংশকে ঘিরে অ্যাবস্ট্রাকশন।

সাধারণ পরিচয় উৎস

ফ্রেমওয়ার্কগুলো সাধারণত একাধিক ব্যাকএন্ড সমর্থন করে, বিল্ট-ইন বা প্লাগইনের মাধ্যমে:

• অ্যাপ্লিকেশন ডেটাবেস ইউজারস: ক্লাসিক “users” টেবিল/কালেকশন যা আপনার অ্যাপ ম্যানেজ করে।
• বাহ্যিক পরিচয় প্রদানকারী (IdPs): Google, Microsoft, GitHub, বা Auth0/Okta-এর মতো ডেডিকেটেড প্রোভাইডার, সাধারণত OAuth 2.0 / OpenID Connect-এর মাধ্যমে।
• এন্টারপ্রাইজ ডিরেক্টরি: LDAP/Active Directory, অভ্যন্তরীণ টুল এবং B2B অ্যাপগুলোর জন্য সাধারণ।

মূল পার্থক্য হলো কে সত্যি সূত্র। ডেটাবেস ইউজারসের ক্ষেত্রে আপনার অ্যাপ ক্রেডেনশিয়াল এবং প্রোফাইল ডেটার মালিক। IdP বা ডিরেক্টরির সাথে, আপনার অ্যাপ প্রায়ই একটি “লোকাল শ্যাডো ইউজার” সংরক্ষণ করে যা বাহ্যিক পরিচয়ের সাথে লিংক করে।

কোর ইউজার মডেলের ফিল্ড

যখন ফ্রেমওয়ার্ক ডিফল্ট ইউজার মডেল জেনারেট করে, বেশিরভাগ দল কয়েকটি ফিল্ড স্ট্যান্ডার্ড করে:

• id: অপরিবর্তনীয় প্রাইমারি কী (ইমেইল হওয়া উচিত নয়)।
• email/username: লগইন শনাক্তকারী; প্রায়শই ইউনিক এবং নরমালাইজ করা।
• password_hash: কেবল তখনই যদি আপনার অ্যাপ পাসওয়ার্ড ম্যানেজ করে (কখনোই কাঁচা পাসওয়ার্ড সংরক্ষণ করবেন না)।
• status flags: উদাহরণ: is_verified, is_active, is_locked, deleted_at.

এই ফ্ল্যাগগুলো গুরুত্বপূর্ণ কারণ প্রমাণীকরণ শুধু “ঠিক পাসওয়ার্ড?” নয়—এর সাথে “এই অ্যাকাউন্ট কি এখন সাইন ইন করার জন্য অনুমোদিত?”-ও জড়িত।

অ্যাকাউন্ট লাইফসাইকেল: শুধু সাইন-আপ নয়

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

ফ্রেমওয়ার্ক কোথায় প্লাগইন করে

অধিকাংশ আধুনিক ফ্রেমওয়ার্ক user providers, adapters, বা repositories-এর মতো এক্সটেনশন পয়েন্ট দেয়। এই কম্পোনেন্টগুলো অনুবাদ করে “কোনো লগইন শনাক্তকারী দেওয়া হলে, ইউজার খুঁজে আনো” এবং “কোন ইউজার আইডি দিলে, বর্তমান ইউজার লোড করো”—সেই স্টোরে যা আপনি বেছে নিয়েছেন, হোক তা SQL কুয়েরি, এক IdP কল, বা এন্টারপ্রাইজ ডিরেক্টরি লুকআপ।

সেশন-ভিত্তিক প্রমাণীকরণ (কুকি ও সার্ভার সেশন)

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

এটি কীভাবে কাজ করে

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

কারণ কুকি শুধুমাত্র একটি শনাক্তকারী (পরিচয় সূচক), সংবেদনশীল তথ্য সার্ভারের উপরেই থাকে।

কুকি ফ্ল্যাগ যা ফ্রেমওয়ার্ক সাধারণত সেট করে

আধুনিক ফ্রেমওয়ার্কগুলো সেশন কুকিগুলো আরও চুরি প্রতিরোধী করতে নিরাপদ ডিফল্ট দেয়:

• HttpOnly: কুকি জাভাস্ক্রিপ্ট থেকে পড়া বন্ধ করে (XSS-এর ক্ষতি হ্রাস করে)।
• Secure: কেবল HTTPS-এ কুকি পাঠায়।
• SameSite (Lax/Strict/None): কুকির ক্রস-সাইট পাঠানোর নিয়ন্ত্রণ করে (CSRF প্রতিরক্ষা ও তৃতীয় পক্ষের অথ ফ্লোয়ের জন্য গুরুত্বপূর্ণ)।

আপনি প্রায়ই এগুলোকে “session cookie settings” বা “security headers”-এর অধীনে কনফিগার করা দেখতে পাবেন।

সেশন কোথায় স্টোর করা হয়

ফ্রেমওয়ার্কগুলো সাধারণত আপনাকে সেশন স্টোর বেছে নিতে দেয়:

• In-memory: দ্রুত ও সহজ, কিন্তু রিস্টার্টে সেশন মুছে যায় এবং বহু সার্ভারের ওপর স্কেল করে না।
• Database-backed: টেকসই এবং অডিটযোগ্য, কিন্তু কুয়েরি ওভারহেড বেড়ে যায়।
• Cache/redis-style store: দ্রুত ও সার্ভারজুড়ে শেয়ারড; স্কেলিংয়ের জন্য ভাল, কিন্তু আপনাকে আরেকটি সার্ভিসে নির্ভর করতে হবে।

উপরে সাধারণত ট্রেড-অফ হলো গতি বনাম টেকসইতা বনাম অপারেশনাল জটিলতা।

লগআউট এবং অবৈধকরণ

লগআউটের মানে দুইভাবে হতে পারে:

• একটি ডিভাইস থেকে লগআউট: বর্তমান সেশন মুছে ফেলা এবং কুকি ক্লিয়ার করা।
• সব জায়গা থেকে লগআউট: ব্যবহারকারীর সমস্ত সেশন বাতিল করা (উদাহরণ: পাসওয়ার্ড পরিবর্তনের পরে)।

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

টোকেন-ভিত্তিক প্রমাণীকরণ (JWT এবং ওপ্যাক টোকেন)

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

বাস্তবে “একটি টোকেন” মানে কী

একটি টোকেন হলো লগইনের পরে ইস্যু করা একটি অ্যাক্সেস ক্রেডেনশিয়াল (বা OAuth ফ্লো পরবর্তী)। ক্লায়েন্ট তা পরবর্তিতে পাঠায় যাতে সার্ভার কলারকে প্রমাণীকৃত মনে করে এবং তারপর অ্যাকশনকে অনুমোদন করে। অধিকাংশ ফ্রেমওয়ার্ক এটিকে এক-প্রকার প্যাটার্ন হিসেবে বিবেচনা করে: একটি “issue token” এন্ডপয়েন্ট, টোকেন যাচাই করা মिडলওয়্যার, এবং পরিচয় প্রতিষ্ঠিত হওয়ার পরে চালু হওয়া গার্ড/পলিসি।

ওপ্যাক টোকেন বনাম JWT

Opaque tokens হল র্যান্ডম স্ট্রিং যেগুলো ক্লায়েন্টের পক্ষে কোনো অর্থ বহন করে না (যেমন tX9...)। সার্ভার সেগুলোকে ডাটাবেস বা কেশ এন্ট্রি দেখে ভ্যালিডেট করে। এভাবে রিভোকেশন সহজ হয় এবং টোকেনের কনটেন্ট গোপন থাকে।

JWTs (JSON Web Tokens) গঠিত এবং সাইনড। একটি JWT সাধারণত ক্লেইমস ধারণ করে যেমন ইউজার আইডেন্টিফায়ার (sub), ইস্যু করা (iss), অডিয়েন্স (aud), ইস্যু/মেয়াদ (iat, exp), এবং কখনো কখনো রোল/স্কোপ। গুরুত্বপূর্ণ: JWTs ডিফল্টভাবে এনক্রিপ্ট করা নয়—তাই টোকেন ধরলে সেটির ক্লেইম পড়তে পারা যায়, যদিও তারা জাল করা না যায়।

স্টোরেজ: Authorization header বনাম কুকি

ফ্রেমওয়ার্কের গাইডলাইন সাধারণত দুইটি নিরাপদ ডিফল্টের দিকে convergence করে:

• API-এর জন্য 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 ফ্রেমওয়ার্ক ইকোসিস্টেমে

OAuth 2.0 এবং OpenID Connect (OIDC) প্রায়ই একসাথে বলা হয়, কিন্তু ফ্রেমওয়ার্কগুলো এগুলোকে আলাদা ভাবে দেখে কারণ এগুলো ভিন্ন সমস্যা সমাধান করে।

OAuth 2.0 বনাম OIDC: কোনটি আপনার প্রয়োজন

OAuth 2.0 ব্যবহার করুন যখন আপনি ডেলিগেটেড অ্যাক্সেস চান: আপনার অ্যাপ ব্যবহারকারীর পক্ষে একটি API কল করার অনুমতি পায় (উদাহরণ: ক্যালেন্ডার পড়া বা রিপোতে পোস্ট করা) চরম হিসেব না নিয়ে।

OpenID Connect ব্যবহার করুন যখন আপনি লগইন/পরিচয় চান: আপনার অ্যাপ জানতে চায় ব্যবহারকারী কে এবং একটি ID টোকেন পেতে চায় পরিচয় ক্লেইমসহ। বাস্তবে, “Login with X” সাধারণত OIDC যা OAuth 2.0-এর ওপরে।

কোর ফ্লো যা ফ্রেমওয়ার্ক সাধারণত সমর্থন করে

অধিকাংশ আধুনিক ফ্রেমওয়ার্ক এবং তাদের অথ লাইব্রেরি দুইটি ফ্লোতে ফোকাস করে:

• Authorization Code flow + PKCE: ব্রাউজার অ্যাপ এবং মোবাইল ক্লায়েন্টদের জন্য ডিফল্ট। PKCE কোড ইন্টারসেপশন প্রতিরোধ করে এবং অধিকাংশ প্রোভাইডার এটি প্রত্যাশা করে।
• Client Credentials flow: সার্ভিস-টু-সার্ভিস কলের জন্য যেখানে কোনো এন্ড-ইউজার নেই (জব, ব্যাক-এন্ড ওয়ার্কার, ইন্টারনাল মাইক্রোসার্ভিস)।

কোলব্যাক হ্যান্ডলিং: যেখানে নিরাপত্তা বিবরণ গুরুত্বপূর্ণ

ফ্রেমওয়ার্ক ইন্টিগ্রেশন সাধারণত একটি কোলব্যাক রুট এবং হেল্পার মিডলওয়্যার দেয়, কিন্তু আপনাকে এখনও সঠিকভাবে কনফিগার করতে হবে:

• redirect URI সঠিকভাবে (scheme/host/path) যাচাই করুন। ওয়াইল্ডকার্ড এড়ান।
• state প্যারামিটার ব্যবহার করুন এবং যাচাই করুন CSRF-শৈলীর লগইন আক্রমণ প্রতিরোধে।
• OIDC-এর জন্য nonce জেনারেট এবং যাচাই করুন টোকেন রেপ্লে ঝুঁকি কমাতে।
• ট্রানজিয়েন্ট মান (state/nonce/verifier) একটি নিরাপদ সেশন বা এনক্রিপ্টেড কুকিতে সংরক্ষিত করুন, লোকাল স্টোরে নয়।

স্কোপ, ক্লেইম এবং লোকাল ইউজারে ম্যাপিং

ফ্রেমওয়ার্কগুলো সাধারণত প্রোভাইডার ডেটা লোকাল ইউজার মডেলে নরমালাইজ করে। মূল ডিজাইন সিদ্ধান্ত হলো কি চলমানভাবে অনুমোদন চালায়:

• Scopes হলো OAuth-এর জন্য API অনুমতিসমূহ (অ্যাক্সেস টোকেন কি করতে পারে)।
• Claims হলো OIDC ID টোকেনে থাকা পরিচয় অ্যাট্রিবিউট (ব্যবহারকারী কে)।

একটি সাধারণ প্যাটার্ন: স্থিতিশীল শনাক্তকারী (যেমন sub) লোকাল ইউজারের সাথে ম্যাপ করা, তারপর প্রোভাইডার রোল/গ্রুপ/ক্লেইমগুলোকে আপনার অ্যাপের লোকাল রোল বা পলিসিতে অনুবাদ করা।

পাসওয়ার্ড, হ্যাশিং, MFA, এবং অ্যাকাউন্ট পুনরুদ্ধার

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

পাসওয়ার্ড হ্যাশিং ডিফল্ট (কেন সাধারণ হ্যাশিং নিরাপদ নয়)

আধুনিক ফ্রেমওয়ার্ক এবং তাদের অথ লাইব্রেরি সাধারণত bcrypt, Argon2, বা scrypt-এর মতো উদ্দেশ্যভিত্তিক পাসওয়ার্ড হ্যাশার ডিফল্ট করে। এই অ্যালগরিদমগুলো ইচ্ছাকৃতভাবে ধীর এবং salting অন্তর্ভুক্ত করে, যা প্রিকম্পিউটেড টেবিল আক্রমণ প্রতিরোধ করে এবং বড়-অস্তরের ক্র্যাকিংকে ব্যয়বহুল করে।

একটি সাধারণ ক্রিপ্টোগ্রাফিক হ্যাশ (যেমন SHA-256) পাসওয়ার্ডের জন্য নিরাপদ নয় কারণ এটি দ্রুত—ডেটাবেস লিক হলে দ্রুত হাজার কোটি পাসওয়ার্ড অনুমান করা যায়। পাসওয়ার্ড হ্যাশাররা ওয়ার্ক ফ্যাক্টর (কস্ট প্যারামিটার) দেয় যাতে হার্ডওয়্যার উন্নতির সাথে আপনি সুরক্ষা টিউন করতে পারেন।

পাসওয়ার্ড নীতি যা আপনি প্রায়ই দেখবেন

ফ্রেমওয়ার্কগুলো সাধারণত হুক (বা মিডলওয়্যার/প্লাগইন) দেয় যে সুনির্দিষ্ট নিয়মগুলো প্রতিটি এন্ডপয়েন্টে হার্ড-কোড না করে প্রয়োগ করতে সাহায্য করে:

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

MFA অপশন এবং ট্রেড-অফ

অধিকাংশ ইকোসিস্টেম পাসওয়ার্ড যাচাইকরণের পরে এমএফএ যোগ করার অপশন দেয়:

• TOTP authenticator apps: ব্যাপকভাবে সমর্থিত এবং অফলাইন-বন্ধুবর; ব্যবহারকারী যদি কোড প্রবেশ করাতে ফিশ করা হয় তবে তা এখনও ফিশেবল।
• WebAuthn / passkeys: ফিশিং এবং রেপ্লে বিরুদ্ধে শক্তিশালী সুরক্ষা; একবার সেটআপ হলে সাধারণত সেরা UX।
• SMS codes: সহজে রোলআউটযোগ্য, কিন্তু SIM-swap এবং ইন্টারসেপ্ট ঝুঁকি বেশি—উচ্চ ঝুঁকির অ্যাকাউন্টের জন্য আদর্শ নয়, তবে কিছুটা ভাল।

নিরাপদভাবে অ্যাকাউন্ট পুনরুদ্ধার

পাসওয়ার্ড রিসেট একটি সাধারণ আক্রমণ পথ, তাই ফ্রেমওয়ার্কগুলো সাধারণত এই ধরণের প্যাটার্নগুলো উৎসাহ দেয়:

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

একটি ভাল নিয়ম: বৈধ ব্যবহারকারীর জন্য পুনরুদ্ধার সহজ করুন, কিন্তু আক্রমণকারীর জন্য স্বয়ংক্রিয়ভাবে ব্যয়বহুল করুন।

মিডলওয়্যার, গার্ড, এবং অনুরোধ লাইফসাইকেল

অধিকাংশ আধুনিক ফ্রেমওয়ার্ক নিরাপত্তাকে অনুরোধ পাইপলাইনের অংশ হিসেবে বিবেচনা করে: ধাপে ধাপে কিছু স্টেপ যা আপনার কন্ট্রোলারের আগে (এবং কখনো কখনো পরে) চলে। নামগুলো ভিন্ন হতে পারে—middleware, filters, guards, interceptors—কিন্তু ধারণা একই: প্রতিটি ধাপ অনুরোধ পড়তে পারে, প্রাসঙ্গিক কনটেক্সট যোগ করতে পারে, বা প্রসেসিং বন্ধ করে দিতে পারে।

একটি ব্যবহারিক পাইপলাইন মানসিক মডেল

একটি সাধারণ ফ্লো দেখতে এমনায়:

1. Routing এন্ডপয়েন্ট নির্বাচন করে (যেমন /account/settings)।
2. Pre-processing components চলে (middleware/filters/interceptors)।
3. Authentication কলারকে শনাক্ত করার চেষ্টা করে।
4. Authorization সিদ্ধান্ত নেয় যে শনাক্তকৃত কলার এই এন্ডপয়েন্ট অ্যাক্সেস করতে পারবে কি না।
5. Handler/controller ব্যবসায়িক লজিক কার্যকর করে।
6. Post-processing রেসপন্স রূপান্তর বা লগিং করতে পারে।

ফ্রেমওয়ার্কগুলো উৎসাহ দেয় আপনি সিকিউরিটি চেকগুলোকে ব্যবসায়িক লজিকের বাইরে রাখুন, যাতে কন্ট্রোলারগুলি “কি করতে হবে” নিয়ে ফোকাসেড থাকে, “কে করতে পারে” নিয়ে নয়।

কোথায় প্রমাণীকরণ হয় (প্রথম পরিচয়)

প্রমাণীকরণ হল সেই ধাপ যেখানে ফ্রেমওয়ার্ক কুকি, সেশন আইডি, API কী, অথবা বিয়ারার টোকেন থেকে ইউজার কনটেক্সট প্রতিষ্ঠা করে। সফল হলে এটি একটি অনুরোধ-স্কোপড পরিচয় তৈরি করে—প্রায়শই user, principal, বা context.auth নামে এক অবজেক্ট হিসেবে এক্সপোজ করা হয়।

এই সংযুক্তি গুরুত্বপূর্ণ কারণ পরবর্তী ধাপগুলো (এবং আপনার অ্যাপ কোড) হেডার পুনরায় পার্স করা বা টোকেন পুনরায় যাচাই করা উচিত নয়। তারা ইতিমধ্যে পূরণকৃত user অবজেক্ট পড়া উচিৎ, যা সাধারণত অন্তর্ভুক্ত করে:

• একটি স্থিতিশীল ইউজার আইডি
• রোল/ক্লেইম (কখনো কখনো)
• অথেনটিকেশন পদ্ধতি বা সেশন আয়ু সংক্রান্ত মেটাডেটা

কোথায় অনুমোদন হয় (পারমিশন চেক)

অনুমোদন সাধারণত হিসেবে বাস্তবায়িত হয়:

• রুট-লেভেল গার্ড (যেমন “সাইন ইন থাকা আবশ্যক”)।
• পলিসি চেক (যেমন “এই ডকুমেন্টটি এডিট করা যাবে?”) যা রিসোর্স লোডের পরে মূল্যায়িত হয়।

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

401 বনাম 403: ব্যর্থতাগুলো সুশৃঙ্খলভাবে হ্যান্ডেল করা

ফ্রেমওয়ার্কগুলো সাধারণত দুটি সাধারণ ব্যর্থতা মোড আলাদা করে:

• 401 Unauthorized (unauthenticated): বৈধ পরিচয় স্থাপন করা হয়নি। ব্রাউজার অ্যাপের জন্য এটি প্রায়ই সাইন-ইনে রিডাইরেক্ট ট্রিগার করে, অথবা API-এর জন্য JSON এরর রিটার্ন করে।
• 403 Forbidden (unauthorized): পরিচয় জানা আছে, কিন্তু অনুমতি নেই।

ভাল-ডিজাইন করা সিস্টেমগুলো 403 রেসপন্সে বিস্তারিত তথ্য প্রকাশ করা এড়ায়; তারা যেই নিয়ম ব্যর্থ হয়েছে তা ব্যাখ্যা না করে অ্যাক্সেস অস্বীকার করে।

অনুমোদন মডেল: রোল, পারমিশন, এবং পলিসি

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

রোল-ভিত্তিক অ্যাক্সেস কন্ট্রোল (RBAC)

RBAC ব্যবহারকারীকে এক বা একাধিক রোল (যেমন admin, support, member) দেয় এবং ঐ রোলের উপর ভিত্তি করে ফিচার গেট করে।

এটি বোঝা সহজ এবং দ্রুত ইমপ্লিমেন্ট করা যায়, বিশেষত যখন ফ্রেমওয়ার্ক requireRole('admin')-এর মতো হেল্পার দেয়। রোল হায়ারার্কি (“admin implies manager implies member”) ডুপ্লিকেশন কমাতে পারে, কিন্তু সুবিধা লুকিয়ে রাখতে পারে: একটি প্যারেন্ট রোলের ছোট পরিবর্তন সাইলেন্টলি অ্যাপ জুড়ে প্রবেশাধিকার বাড়িয়ে দিতে পারে।

RBAC বড়, স্থিতিশীল বিভাজনের জন্য সেরা।

পারমিশন-ভিত্তিক অ্যাক্সেস (বালী-গ্রানুলার)

পারমিশন-ভিত্তিক অনুমোদন কোনো অ্যাকশনের বিরুদ্ধে রিসোর্স চেক করে, প্রায়শই প্রকাশ করা হয়:

• Action: read, create, update, delete, invite
• Resource: invoice, project, user, কখনো কখনো আইডি বা মালিকানা সহ

এই মডেলটি RBAC-এর তুলনায় আরও নির্ভুল। উদাহরণ: “প্রজেক্ট সম্পাদনা করতে পারে” এবং “শুধু তাদের নিজের প্রজেক্ট সম্পাদনা করতে পারে” আলাদা—যার জন্য পারমিশন এবং ডাটা শর্ত দুটোই চেক করতে হয়।

ফ্রেমওয়ার্কগুলো প্রায়ই একটি কেন্দ্রীয় “can?” ফাংশন (বা সার্ভিস) বাস্তবায়ন করে যা কন্ট্রোলার, রিজলভার, ওয়ার্কার, বা টেমপ্লেট থেকে ডাকা হয়।

পলিসি-ভিত্তিক অনুমোদন (শর্তসহ নিয়ম)

পলিসি পুনরায় ব্যবহারযোগ্য ইভ্যালুয়েটর হিসেবে অনুমোদন লজিক প্যাক করে: “একজন ব্যবহারকারী মন্তব্য মুছতে পারে যদি তিনি সেটি লিখেছেন বা তিনি একজন মডারেটর।” পলিসি কনটেক্সট (ব্যবহারকারী, রিসোর্স, অনুরোধ) নেয় এবং তাই তারা উপযুক্ত:

• মালিকানা চেক
• সাবস্ক্রিপশন টিয়ার নিয়ম
• সময়-ভিত্তিক বা অর্গানাইজেশন-ভিত্তিক সীমাবদ্ধতা

যখন ফ্রেমওয়ার্ক পলিসিগুলো রাউটিং ও মিডলওয়্যারে ইন্টিগ্রেট করে, আপনি নিয়মগুলো ধারাবাহিকভাবে সব এন্ডপয়েন্টে বলবৎ করতে পারেন।

Attributes/annotations বনাম কোড-ভিত্তিক চেক

অ্যানোটেশন (যেমন @RequireRole('admin')) হ্যান্ডলারকে কাছাকাছি রাখতে উদ্দেশ্য রাখে, কিন্তু নিয়ম জটিল হলে ফ্র্যাগমেন্টেড হয়ে উঠতে পারে।

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

সাধারণ বিল্ট-ইন প্রতিরক্ষা: CSRF, CORS, এবং সিকিউরিটি হেডার

আধুনিক ফ্রেমওয়ার্কগুলো কেবল ইউজার লগইন করাতেই সাহায্য করে না—তারা অথেন্টিকেশনের চারপাশে ঘটা সবচেয়ে সাধারণ "ওয়েব গ্লু" আক্রমণের বিরুদ্ধে প্রতিরোধও দেয়।

CSRF: কুকি-ভিত্তিক ব্রাউজার অ্যাপের সুরক্ষা

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

সাধারণ প্যাটার্নগুলো:

• Synchronizer token: সার্ভার ফর্মে একটি টোকেন রেন্ডার করে এবং POST/PUT/PATCH/DELETE-এ তা যাচাই করে।
• Double-submit cookie: CSRF টোকেন কুকিতে রাখা হয় এবং হেডার/বডিতে পাঠানো হয়; সার্ভার মিল যাচাই করে।

CSRF টোকেনকে SameSite কুকির (প্রায়শই Lax ডিফল্ট) সঙ্গে জোড়া করুন ঝুঁকি কমাতে, এবং নিশ্চিত করুন আপনার সেশন কুকি যেখানে উপযুক্ত সেখানে HttpOnly ও Secure।

CORS: API-গুলো স্পষ্ট নিয়ম প্রয়োজন

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, SPA, মোবাইল, এবং মাইক্রোসার্ভিস

“সঠিক” অথ প্যাটার্ন কড়ানোভাবে নির্ভর করে কোড কোথায় রান করে এবং অনুরোধ কিভাবে আপনার ব্যাকএন্ড পৌঁছে। ফ্রেমওয়ার্কগুলো অনেক বিকল্প সমর্থন করতে পারে, কিন্তু এক অ্যাপ টাইপের ডিফল্ট অন্যটিতে অদ্ভুত বা ঝুঁকিপূর্ণ হতে পারে।

সার্ভার-রেন্ডার্ড অ্যাপ (SSR)

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

প্রায়োগিক নিয়ম: সেশন কুকি HttpOnly, Secure, এবং উপযুক্ত SameSite দিয়ে রাখুন, এবং ব্যক্তিগত ডেটা রেন্ডার করার প্রতিটি অনুরোধে সার্ভার-সাইড অনুমোদন চেক করুন।

সিঙ্গেল-পেজ অ্যাপ (SPA)

SPA-গুলো প্রায়শই জাভাস্ক্রিপ্ট থেকে API কল করে, যা টোকেন পছন্দগুলো স্পষ্ট করে তোলে। অনেক দল ছোট-মেয়াদী অ্যাক্সেস টোকেন সহ OAuth/OIDC ফ্লো পছন্দ করে।

যদি সম্ভব দীর্ঘমেয়াদি টোকেন localStorage-এ রাখা এড়ান; এটি XSS-এর বিস্তার বাড়ায়। একটি সাধারণ বিকল্প হলো BFF (backend-for-frontend) প্যাটার্ন: SPA আপনার সার্ভারের সাথে সেশন কুকি দিয়ে কথা বলে, এবং সার্ভার upstream APIs-এর জন্য টোকেন এক্সচেঞ্জ/ধারণ করে।

মোবাইল ক্লায়েন্ট

মোবাইল অ্যাপ ব্রাউজারের কুকি নিয়মের উপর নির্ভর করতে পারে না। তারা সাধারণত PKCE সহ OAuth/OIDC ব্যবহার করে, এবং রিফ্রেশ টোকেন প্ল্যাটফর্মের নিরাপদ স্টোরেজে রাখে (Keychain/Keystore)।

"হারিয়ে যাওয়া ডিভাইস" পুনরুদ্ধারের পরিকল্পনা করুন: রিফ্রেশ টোকেন রিভোক করুন, ক্রেডেনশিয়াল রোটেট করুন, এবং এমএফএ সক্রিয় থাকলে পুনরায় অথেন্টিকেশন সহজ করুন।

মাইক্রোসার্ভিস এবং API গেটওয়ে

বহু সার্ভিস থাকলে, আপনি কেন্দ্রীভূত পরিচয় বনাম সার্ভিস-লেভেল বহুল প্রয়োগের মধ্যে নির্বাচন করবেন:

• Gateway-centric: গেটওয়ে টোকেন যাচাই করে এবং পরিচয় কনটেক্সট ফরওয়ার্ড করে।
• Defense in depth: প্রতিটি সার্ভিসও টোকেন যাচাই করে এবং নিজস্ব রিসোর্সের জন্য অনুমোদন প্রয়োগ করে।

সার্ভিস-টু-সার্ভিস অথের জন্য, ফ্রেমওয়ার্কগুলো সাধারণত mTLS (চ্যানেল আইডেন্টিটি) বা OAuth client credentials (সার্ভিস অ্যাকাউন্ট)-এর সঙ্গে ইন্টিগ্রেট করে। লক্ষ্য হলো কলারকে প্রমাণীকৃত করা এবং এটি কি করতে পারে তা অনুমোদন করা।

ইম্পার্সনেশন এবং অ্যাডমিন অ্যাক্সেস

অ্যাডমিন "ইম্পার্সনেট ইউজার" ফিচার শক্তিশালী কিন্তু বিপজ্জনক। স্পষ্ট ইম্পার্সনেশন সেশন পছন্দ করুন, অ্যাডমিনদের জন্য পুনঃঅথেনটিকেশন/এমএফএ বাধ্যতামূলক রাখুন, এবং সবসময় অডিট লগ লিখুন (কে কাকে ইম্পার্সনেট করল, কখন, এবং কি অ্যাকশন নেয়া হলো)।

টেস্টিং, অবজারভেবিলিটি, এবং এড়িয়ে চলার পরামর্শ

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

ভাঙা সেটআপ ছাড়া অথ ফ্লো টেস্ট করা

শুরু করুন কি টেস্ট করবেন তা আলাদা করে:

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

অধিকাংশ ফ্রেমওয়ার্ক টেস্ট হেল্পার দিয়ে আসে যাতে আপনি প্রতিবার সেশন বা টোকেন হ্যান্ড-রোল না করতে পারেন। সাধারণ প্যাটার্নগুলো:

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

প্রায়োগিক নিয়ম: প্রতিটি “হ্যাপি পাথ” টেস্টের জন্য একটি “অস্বীকৃত হওয়া দরকার” টেস্ট যোগ করুন যাতে প্রমাণ হয় অনুমোদন চেকটি আসলে চলছে।

অবজারভেবিলিটি: যা হয়েছে তা প্রমাণ করুন, আশায় নয়

কিছু ভুল হলে দ্রুত ও আত্মবিশ্বাসের সঙ্গে উত্তর পেতে চান।

কী ইভেন্ট লগ বা অডিট করুন:

• Authentication events: সাইন-ইন সাফল্য/ব্যর্থতা, MFA চ্যালেঞ্জ, পাসওয়ার্ড রিসেট, টোকেন রিফ্রেশ।
• Authorization denials: কোন পলিসি ব্যর্থ, কোন রিসোর্সে, কোন ইউজারের জন্য (সিক্রেট লগ করবেন না)।
• Correlation IDs: একটি রিকুয়েস্ট আইডি যা লগ ও ট্রেস জুড়ে প্রসারিত হয় যাতে লগইন প্রচেষ্টা সার্ভিস জুড়ে ট্র্যাক করা যায়।

হালকা ওজনের মেট্রিকও রাখুন: 401/403 রেসপন্সের হার, ব্যর্থ লগইন স্পাইক, এবং অস্বাভাবিক টোকেন রিফ্রেশ প্যাটার্ন।

ফ্রেমওয়ার্ক আপনাকে পুরোপুরি বাঁচাবে না এমন সাধারণ ফাঁক

• Client claims-এ ভরসা করা: UI ফ্ল্যাগ বা ক্লায়েন্ট-সাইড রোল কখনো বিশ্বাস করবেন না। সবসময় সার্ভারে প্রয়োগ করুন।
• দ্বিতীয় পর্যায়ের এন্ডপয়েন্টে চেক না থাকা: এক্সপোর্ট, ব্যাকগ্রাউন্ড জব, অ্যাডমিন টুল, এবং “অভ্যন্তরীণ” API-গুলোও অনুমোদন প্রয়োজন।
• অতিপ্রচারিত স্কোপ/রোল: "এখনকার জন্য ঠিক আছে" ধরনের পারমিশন প্রায়ই স্থায়ী হয়ে যায়।
• টোকেন লিকেজ: টোকেন সহজে কপি করা যায় এমন জায়গায় রাখা (লগ, URL, localStorage) বা তৃতীয় পক্ষকে পাঠানো।

অথ বাগগুলোকে টেস্টযোগ্য আচরণ হিসেবে দেখুন: যদি এটা regress করতে পারে, তবে এর জন্য একটি টেস্ট থাকা উচিত।