Authentication vs Authorization
- ●Authentication প্রমাণ করে তুমি কে, আর Authorization ঠিক করে তুমি কী করতে পারবে।
- ●Password, OTP, biometric ইত্যাদি হলো authentication factor; দুই বা ততোধিক একসাথে ব্যবহার করলে সেটা 2FA/MFA।
- ●অ্যাক্সেস নিয়ন্ত্রণের দুই জনপ্রিয় মডেল হলো RBAC (role-ভিত্তিক) ও ABAC (attribute-ভিত্তিক)।
সমস্যাটা কী?
ধরো তুমি একটা অফিস বিল্ডিংয়ে ঢুকতে চাও। গেটে দারোয়ান প্রথমে তোমার ID কার্ড দেখে নিশ্চিত হয় তুমি আসলেই সেই ব্যক্তি যিনি ভেতরে কাজ করেন। এরপর তুমি যখন তিনতলার সার্ভার রুমে ঢুকতে যাও, তখন আবার আলাদা একটা চেক হয়— তোমার কি ওই রুমে ঢোকার অনুমতি আছে?
এই দুটো আলাদা ব্যাপার। প্রথমটা হলো তুমি কে তা প্রমাণ করা, দ্বিতীয়টা হলো তুমি কী করতে পারবে তা নির্ধারণ করা। সফটওয়্যারেও ঠিক একই দুই ধাপ আছে, কিন্তু নতুন ডেভেলপাররা প্রায়ই এ দুটো গুলিয়ে ফেলে। ফলে এমন bug হয় যেখানে লগইন করা একজন সাধারণ ইউজার অন্য কারো ডেটা দেখে ফেলে, কারণ কোডে শুধু "লগইন হয়েছে কিনা" চেক করা হয়েছে, "এই ডেটা দেখার অনুমতি আছে কিনা" চেক করা হয়নি।
মূল ধারণা
Authentication (AuthN) হলো পরিচয় যাচাইয়ের প্রক্রিয়া— "তুমি কে?"। Authorization (AuthZ) হলো অনুমতি যাচাইয়ের প্রক্রিয়া— "তুমি কী করতে পারবে?"।
Authentication সবসময় আগে ঘটে। সিস্টেম প্রথমে নিশ্চিত হয় তুমি যে নিজেকে দাবি করছ তুমি আসলেই সে। এরপর Authorization ঘটে— সিস্টেম তোমার পরিচয় জানার পর সিদ্ধান্ত নেয় তুমি কোন রিসোর্সে হাত দিতে পারবে।
একটা সহজ সূত্র মনে রাখো: AuthN ছাড়া AuthZ অর্থহীন। কারণ আগে না জানলে তুমি কে, তোমাকে কী অনুমতি দেব তা ঠিক করা যায় না। উল্টোটাও সত্য— শুধু লগইন করালেই সব কাজ করতে দেওয়া যাবে না, প্রতিটি সংবেদনশীল কাজে authorization চেক লাগবে।
কীভাবে কাজ করে
ধাপ ১: Authentication
ইউজার তার পরিচয়ের প্রমাণ (credential) জমা দেয়— সাধারণত username ও password। সার্ভার সেটা যাচাই করে। সঠিক হলে সার্ভার একটা পরিচয়পত্র ইস্যু করে— হয় একটা Session অথবা একটা Token।
ধাপ ২: Authorization
পরের প্রতিটি request-এ ইউজার ওই session বা token পাঠায়। সার্ভার সেটা দেখে চিনে নেয় ইউজার কে, তারপর চেক করে এই ইউজারের কাছে এই কাজের অনুমতি আছে কিনা।
দুটোর তুলনা
| বিষয় | Authentication | Authorization |
|---|---|---|
| প্রশ্ন | তুমি কে? | তুমি কী করতে পারবে? |
| কখন ঘটে | প্রথমে | AuthN-এর পরে |
| উদাহরণ | লগইন স্ক্রিন | "Admin only" পেজ |
| ডেটা | credentials | permissions/roles |
| ইউজার বদলাতে পারে? | হ্যাঁ (password) | না (নিজের permission নিজে দিতে পারে না) |
ব্যাপারটা সিনেমা হলের মতো। টিকিট কাউন্টারে তোমার নাম বা টিকিট দেখানো হলো authentication— তুমি বৈধ দর্শক। কিন্তু তোমার টিকিট যদি সাধারণ সিটের হয়, তুমি VIP বক্সে বসতে পারবে না— এটাই authorization। হলে ঢুকতে পারা আর VIP বক্সে বসতে পারা এক জিনিস নয়।
প্রকারভেদ
Authentication factor
পরিচয় প্রমাণের উপাদানগুলোকে তিন ভাগে ভাগ করা যায়:
- যা তুমি জানো (knowledge): password, PIN, security question-এর উত্তর।
- যা তোমার কাছে আছে (possession): ফোনে আসা OTP, hardware key, authenticator app-এর কোড।
- যা তুমি নিজে (inherence): fingerprint, face recognition, voice— অর্থাৎ Biometric।
যখন একটার বেশি ভিন্ন category থেকে factor চাওয়া হয়, তখন তাকে বলে MFA (Multi-Factor Authentication)। ঠিক দুটো হলে 2FA। মনে রাখো— password আর security question দুটোই "যা জানো" category, তাই এটা আসল MFA নয়।
Authorization model
RBAC (Role-Based Access Control): পারমিশন গুলো role-এর সাথে বাঁধা থাকে। যেমন "admin", "editor", "viewer"। ইউজারকে role দিলেই সে ওই role-এর সব পারমিশন পেয়ে যায়। সহজ ও স্কেলযোগ্য, তাই বেশিরভাগ সিস্টেমে এটাই ব্যবহার হয়।
ABAC (Attribute-Based Access Control): সিদ্ধান্ত নেওয়া হয় বিভিন্ন attribute-এর ভিত্তিতে— ইউজারের department, রিসোর্সের owner, দিনের সময়, এমনকি location। যেমন "শুধু একই ব্রাঞ্চের ম্যানেজার অফিস-আওয়ারে এই ফাইল দেখতে পারবে"। RBAC-এর চেয়ে নমনীয় কিন্তু জটিল।
| মডেল | ভিত্তি | উপযুক্ত যখন |
|---|---|---|
| RBAC | role | role সংখ্যা সীমিত, নিয়ম সরল |
| ABAC | attribute | সূক্ষ্ম ও context-নির্ভর নিয়ম দরকার |
Session vs Token
লগইনের পর পরিচয় ধরে রাখার দুটো উপায়:
- Session: সার্ভার একটা session তৈরি করে নিজের memory বা database-এ রাখে, আর ইউজারকে একটা session ID (সাধারণত cookie-তে) দেয়। প্রতি request-এ সার্ভার ওই ID দেখে নিজের store-এ খুঁজে বের করে ইউজার কে। এটা stateful।
- Token: সার্ভার একটা স্বয়ংসম্পূর্ণ token (যেমন JWT) দেয় যার মধ্যেই ইউজারের তথ্য সাইন করা থাকে। সার্ভারকে কিছু মনে রাখতে হয় না, শুধু signature যাচাই করলেই চলে। এটা stateless।
কখন ব্যবহার করবে / করবে না
ছোট, একক-সার্ভার অ্যাপে session সহজ ও নিরাপদ। অনেক service-ওয়ালা বড় সিস্টেমে (microservice) token সুবিধাজনক, কারণ প্রতিটি service আলাদাভাবে token যাচাই করতে পারে।
Authorization-এর ক্ষেত্রে শুরুতে RBAC দিয়ে শুরু করো; প্রয়োজন হলে পরে ABAC যোগ করো।
সবচেয়ে বিপজ্জনক ভুল— শুধু authentication চেক করে authorization ভুলে যাওয়া। যেমন /orders/123 URL-এ ইউজার লগইন করা আছে কিনা দেখলে, কিন্তু order 123 আসলে এই ইউজারেরই কিনা না দেখলে— তখন যে কেউ ID বদলে অন্যের অর্ডার দেখে ফেলবে। একে বলে Broken Access Control, যা OWASP-এর শীর্ষ ঝুঁকি।
বাস্তব উদাহরণ
Google-এর কথা ভাবো। যখন তুমি Gmail-এ লগইন করো, password ও (চালু থাকলে) ফোনের prompt দিয়ে authentication হয়— এটাই 2FA। লগইনের পর তুমি Google Workspace-এর admin console খুলতে গেলে Google আবার চেক করে তোমার অ্যাকাউন্টে admin role আছে কিনা— এটাই authorization (RBAC)। একজন সাধারণ ইউজার লগইন করা সত্ত্বেও admin console-এ ঢুকতে পারবে না, কারণ তার role তা অনুমতি দেয় না।
Bangladesh-এর bKash-এও একই প্যাটার্ন: PIN দিয়ে authentication, আর "send money limit" বা "merchant payment" করার অনুমতি তোমার অ্যাকাউন্ট টাইপের (authorization) উপর নির্ভর করে।
ইন্টারভিউতে যদি জিজ্ঞেস করে "AuthN আর AuthZ-এর পার্থক্য কী?", এক বাক্যে বলো: "AuthN হলো 'তুমি কে' প্রমাণ করা, AuthZ হলো 'তুমি কী করতে পারবে' নির্ধারণ করা— এবং AuthN সবসময় আগে ঘটে।" তারপর Broken Access Control-এর উদাহরণ দিয়ে দেখাও তুমি বাস্তব ঝুঁকি বোঝো।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. Authentication আসলে কোন প্রশ্নের উত্তর দেয়?
2. নিচের কোনটি 2FA-এর সঠিক উদাহরণ?
3. RBAC-এ অ্যাক্সেস মূলত কীসের উপর নির্ভর করে?