Authentication နှင့် Authorization ကို အသေးစိတ်လေ့လာခြင်း

နားလည်ထားရမယ့် အချက်

Authentication နဲ့ authorization ဆိုတာ အသံထွက်တူသလို ခံစားရပေမယ့် လုံးဝကွဲပြားတဲ့ မေးခွန်းနှစ်ခုကို ဖြေဆိုနေတာပါ။

Authentication က "သင်ဘယ်သူလဲ" ဆိုတဲ့ မေးခွန်းကို ဖြေတယ်—password၊ passkey၊ (သို့) valid session token ဖြင့် identity ကို သက်သေပြတာပါ။

Authorization ကတော့ ဒီ identity က ဒီ resource အပေါ် အခုချိန်မှာ ဘာလုပ်ခွင့်ရှိလဲဆိုတာကို ဖြေတယ်။ တစ်ခုကျော်တာနဲ့ တခြားတစ်ခုကို အလိုလို မရရှိဘူး။

GET /users/123 ကို စဉ်းစားကြည့်ပါ။ login ဝင်ထားတယ်ဆိုတာနဲ့ user တိုင်းရဲ့ data ကို ကြည့်ခွင့်ရတာ မဟုတ်ဘူး။

ဒီနှစ်ခုကို အစဉ်လိုက် သီးခြားစစ်ဆေးရမည့် gate နှစ်ခုအဖြစ် သဘောထားပါ။ Authentication က identity ကို တစ်ကြိမ်တည်း အတည်ပြုပြီး authorization ကတော့ resource၊ action တစ်ခုချင်းစီအတွက် ပြန်လည်အကဲဖြတ်ရမယ်။

Authentication

user ဘယ်သူဖြစ်တယ်ဆိုတာ password၊ passkey၊ (သို့) valid session token လို credential ကို စစ်ဆေးခြင်းဖြင့် အတည်ပြုသည့် လုပ်ငန်းစဉ်။

Authorization

identity အတည်ပြုပြီးသား user တစ်ဦးက ဘာလုပ်ခွင့်ရှိသည်ကို resource၊ action တစ်ခုချင်းစီအလိုက် ဆုံးဖြတ်သည့် လုပ်ငန်းစဉ်။

AUTHENTICATION VS AUTHORIZATION
-------------------------------
REQUEST
   |
   v
[AUTHENTICATION]   <- who are you?
   |
   | pass (identity confirmed)
   v
[AUTHORIZATION]    <- allowed to do THIS, on THIS resource?
   |
   +-- pass --> ALLOW (proceed)
   |
   +-- fail --> DENY (403, even though logged in)

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

အောက်က function က နှစ်ခုသီးခြား gate flow ကို ပကတိ runnable code အဖြစ် တင်ပြထားတယ်—boolean တစ်ခုတည်းအဖြစ် ပေါင်းမစဉ်းစားဘဲ gate တစ်ခုစီကို သီးခြားစစ်ဆေးတယ်။

Authentication fail ရင် function ချက်ချင်းရပ်ပြီး authorization ကို ကြည့်တောင် မကြည့်ဘဲ DENY ကို ပြန်ပေးတယ်။

check နှစ်ခုကို structurally သီးခြားထား၊ output ထဲမှာလည်း result သီးခြားစီပြထားခြင်းက ဒီ bug ကို production မရောက်ခင် ဖမ်းမိစေတယ်။

• Authentication က identity ကို သက်သေပြပြီး authorization က ဒီ identity ဘာလုပ်ခွင့်ရှိလဲ၊ ဘယ် resource ပေါ်လဲဆိုတာ ဆုံးဖြတ်တယ်။
• Authentication ကျော်တာနဲ့ action (သို့) resource တစ်ခုချင်းစီအတွက် authorization အလိုလို မရရှိဘူး။
• sensitive request တိုင်းအတွက် gate နှစ်ခုကို သီးခြား၊ အစဉ်လိုက် စစ်ဆေးပါ—"login ဝင်ထားလား" ဆိုတဲ့ တစ်ခုတည်းသော check မဟုတ်ဘူး။

အတူတူ စမ်းရေးကြည့်မယ်

function checkAccess(request) {
  const authResult = request.isAuthenticated
    ? { gate: "authentication", passed: true }
    : { gate: "authentication", passed: false, reason: "not logged in" };

  if (!authResult.passed) {
    return { authentication: authResult, authorization: null, decision: "DENY" };
  }

  const isOwner = request.requestedResourceOwnerId === request.actualUserId;
  const authzResult = isOwner
    ? { gate: "authorization", passed: true }
    : {
        gate: "authorization",
        passed: false,
        reason: `user ${request.actualUserId} does not own resource owned by ${request.requestedResourceOwnerId}`,
      };

  return {
    authentication: authResult,
    authorization: authzResult,
    decision: authzResult.passed ? "ALLOW" : "DENY",
  };
}

const authenticatedButNotOwner = checkAccess({
  isAuthenticated: true,
  requestedResourceOwnerId: 123,
  actualUserId: 456,
});

const fullyAuthorized = checkAccess({
  isAuthenticated: true,
  requestedResourceOwnerId: 123,
  actualUserId: 123,
});

console.log("Case 1 - authenticated but not the owner:");
console.log(JSON.stringify(authenticatedButNotOwner, null, 2));
console.log("\nCase 2 - authenticated and owns the resource:");
console.log(JSON.stringify(fullyAuthorized, null, 2));

Case 1 - authenticated but not the owner:
{
  "authentication": {
    "gate": "authentication",
    "passed": true
  },
  "authorization": {
    "gate": "authorization",
    "passed": false,
    "reason": "user 456 does not own resource owned by 123"
  },
  "decision": "DENY"
}

Case 2 - authenticated and owns the resource:
{
  "authentication": {
    "gate": "authentication",
    "passed": true
  },
  "authorization": {
    "gate": "authorization",
    "passed": true
  },
  "decision": "ALLOW"
}

OWASP Authorization Cheat Sheet — Digital Privacy & Modern Security