Authentication ও Authorization: পরিচয় বনাম অনুমতি

এই পাঠে যা শিখবেন

• Authentication ও authorization আলাদা করা
• Laravel middleware এবং policy সঠিক স্থানে ব্যবহার
• অন্যের resource access ঠেকানো

সমস্যা দিয়ে শুরু

রহিম login করে নিজের invoice দেখেন। URL-এর invoice ID বদলে করিমের invoice-ও দেখতে পান। Login কাজ করছে, কিন্তু authorization নেই। System Design-এ identity জানা এবং একটি নির্দিষ্ট কাজের অনুমতি যাচাই দুটি আলাদা সিদ্ধান্ত। Application যত service-এ ভাগ হোক, resource-এর ownership boundary প্রতিটি entry point-এ বজায় থাকতে হবে। Frontend button লুকানো server-side permission নয়।

সহজ করে বুঝি

Authentication প্রমাণ করে request কোন পরিচয়ের অধীনে এসেছে। Authorization নির্ধারণ করে সেই পরিচয় কোন resource-এ কোন action করতে পারবে। Session, token বা federation identity বহন করতে পারে; policy ownership, role ও business state দেখবে। Laravel auth middleware guest আটকায়, policy authenticated user-এর specific permission দেখে। Default deny রাখলে নতুন endpoint অনিচ্ছায় উন্মুক্ত হওয়ার ঝুঁকি কমে।

পরিচিত একটি উপমা

হাসপাতালের পরিচয়পত্র দেখিয়ে কর্মী ভেতরে ঢুকতে পারেন। কিন্তু সবাই operation theatre বা pharmacy locker খুলতে পারেন না। Gate-এর পরিচয় যাচাই authentication, নির্দিষ্ট ঘরের প্রবেশাধিকার authorization। পরিচয়পত্র থাকলেই সব দরজা খোলা উচিত নয়।

নকশাটি দেখুন

flowchart LR
 R[Request] --> A[Authentication middleware]
 A --> P[Invoice policy]
 P -->|Allowed| D[Load permitted invoice]
 P -->|Denied| F[Forbidden response]

Request আগে identity middleware পেরোয়। Policy invoice-এর owner এবং প্রয়োজনীয় business rule দেখে। Allowed হলে data ফেরে; denied হলে private content বের হয় না। Route model binding data খুঁজে দেয়, permission প্রমাণ করে না। সব read, update, export ও download path একই boundary মানছে কি না পরীক্ষা করুন।

PHP ও Laravel-এ প্রয়োগ

app/Policies/InvoicePolicy.php-র method fragment। User ও Invoice Eloquent model আছে; user_id integer ownership field। Policy discovery বা registration configured ধরে নেওয়া হয়েছে। Controller-এ Gate::authorize('view', $invoice) চালাতে হবে; শুধু policy class লিখলে enforcement হয় না।

use App\Models\Invoice;
use App\Models\User;
public function view(User $user, Invoice $invoice): bool
{
    return $invoice->user_id === $user->id;
}

সুবিধা, সীমাবদ্ধতা ও trade-off

Central policy duplication কমায় ও review সহজ করে। কিন্তু অতিরিক্ত generic permission engine business meaning লুকাতে পারে। Resource lookup আগে permission check করলে অস্তিত্বের তথ্য ফাঁস হতে পারে; API semantics অনুযায়ী 403 বা 404 বেছে consistent করুন। Authorization result cache করলে role change বা tenant membership revoke হওয়ার পরে stale access risk থাকে।

সাধারণ ভুল

• auth middleware থাকলেই সব invoice নিরাপদ ধরা।
• Request-এর user_id বিশ্বাস করে ownership ঠিক করা।
• Admin UI লুকিয়ে API permission বাদ দেওয়া।

আরও একটু গভীরে

Background jobs-এ request session থাকে না। Job-এর authority ও actor context স্পষ্টভাবে রাখুন, sensitive action execution-এর সময়ও প্রযোজ্য permission/business state পুনরায় যাচাই করুন। Service-to-service credential end user-এর সব ক্ষমতার সমান নয়। Audit log-এ actor, action ও resource identifier রাখুন; password বা access token লিখবেন না। Permission test-এ allowed ও denied দুই দিকই জরুরি।

মনে রাখুন

পরিচয় জানা অনুমতি নয়; প্রতিটি resource action server-side policy দিয়ে যাচাই করতে হয়।

নিজে চেষ্টা করুন

Pest test-এ owner invoice দেখতে পারছেন এবং অন্য authenticated user forbidden পাচ্ছেন পরীক্ষা করুন। Download, list এবং update endpoint-ও একইভাবে cover করুন। Soft-deleted বা transferred invoice-এর rule লিখে নিন।

নিজের বোঝা যাচাই করুন

1. Login হলেই invoice দেখা যাবে?

না। Login identity জানায়; invoice policy ownership এবং action permission যাচাই করবে।

2. Model binding কি authorization?

না। এটি route parameter থেকে model খুঁজে দেয়। Resource পাওয়া এবং access অনুমোদন আলাদা।

3. Frontend button লুকানো যথেষ্ট?

না। Client বদলে সরাসরি HTTP request করা যায়। Server-এ permission enforce করুন।

4. কোন test জরুরি?

Owner allowed এবং অন্য user denied test দুটো। শুধু happy path থাকলে cross-user exposure ধরা পড়ে না।

5. Job actor কোথায় পাবে?

Explicit durable actor/context দিন এবং execution boundary-র rules নির্ধারণ করুন। Request session worker-এ আছে ধরে নেওয়া যাবে না।

আরও পড়ুন

• Laravel authorization
• Laravel authentication