Thuta Learning
How the Web Works
IntermediateWeb Developmentbeginner

Authentication နှင့် Authorization

ဒီခန်းပြီးရင် ဘာတတ်သွားမလဲ

  • Authentication နှင့် Authorization concept ကို နားလည်ရှင်းပြနိုင်ရန်
  • Diagram ကို ဖတ်ပြီး request/data/event ဘယ်လိုစီးဆင်းသလဲ ခြေရာခံနိုင်ရန်
  • ဒီ piece က web architecture တစ်ခုလုံးထဲမှာ ဘယ်လို ဆက်စပ်နေသလဲ ရှင်းပြနိုင်ရန်

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

Authentication က 'သင်ဘယ်သူလဲ' ကို ဖြေသည် - password, passkey, OAuth, magic link, token စသည်တို့သည် identity သက်သေပြသည့်နည်းလမ်းများ ဖြစ်သည်။

Authorization က 'ဘာလုပ်ခွင့်ရှိလဲ' ကို ဖြေသည် - login ဝင်ထားခြင်းသည် အရာအားလုံး လုပ်ခွင့်ရှိသည်ဟု မဆိုလိုပါ။ real app များသည် action တိုင်းတွင် သီးခြားစစ်ဆေးသည်။

Login Form

user သည် form တစ်ခုမှတစ်ဆင့် credential များ ထည့်သွင်းသည်။

HTTPS Request

credential များသည် encrypted HTTPS connection မှတစ်ဆင့် backend ဆီ ခရီးသွားသည်။

Backend Verifies

backend သည် credential ကို သိမ်းထားသော (hashed) data နှင့် နှိုင်းယှဉ်စစ်ဆေးသည်။

Session/Token Created

အောင်မြင်လျှင် backend သည် authenticated user ကို ကိုယ်စားပြုသော session (သို့) token ဖန်တီးသည်။

Authenticated Requests

နောင် request များသည် ထို session/token ကို ကိုင်ဆောင်ပြီး backend က တစ်ခါစီ ထပ်စစ်သည်။

password ကို plain text အဖြစ် ဘယ်တော့မှ မသိမ်းသင့်ပါ - hashing (one-way) နှင့် salting (random data ထပ်ထည့်ခြင်း) သည် standard approach ဖြစ်သည်။

ကိုယ်ပိုင် crypto ဘယ်တော့မှ မရေးပါနှင့်

password hashing (သို့) cryptographic code ကို ကိုယ်တိုင် ရေးမည့်အစား established, audited library (သို့) managed authentication service များကို အသုံးပြုပါ။

Authentication
password၊ passkey၊ OAuth login (သို့) valid session/token စသည်တို့မှတစ်ဆင့် user တစ်ဦးသည် မည်သူဖြစ်ကြောင်း အတည်ပြုသည့် လုပ်ငန်းစဉ်
Authorization
authenticate လုပ်ပြီးသား user တစ်ဦးအား မည်သည့်အရာများ ပြုလုပ်ခွင့်ပေးမည်ဆိုသည်ကို ဆုံးဖြတ်သည့် လုပ်ငန်းစဉ်
text
LOGIN FLOW
----------
LOGIN FLOW
-----------

  Login Form -> HTTPS Request -> Backend Verifies Credentials
       -> Session/Token Created -> Authenticated Requests

AUTHENTICATION VS AUTHORIZATION
---------------------------------

  Authentication: "Who are you?"
    -> checked once per login (session/token proves identity)

  Authorization: "What can you do?"
    -> checked on every sensitive action (role/permission check)

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

function သည် ဦးစွာ authenticated session ရှိမရှိ စစ်ပြီး ၎င်းအောင်မြင်မှသာ action-specific authorization ကို သီးခြားစစ်ဆေးသည်။

  • မေးခွန်း 1: ဒါဘယ်သူလဲ (authentication)
  • မေးခွန်း 2: ၎င်းက အခုဘာလုပ်ခွင့်ရှိလဲ (authorization)

ကိုယ်ပိုင် password hashing/crypto ဘယ်တော့မှ မရေးပါနှင့်

established, audited library (သို့) managed authentication service များကိုသာ အသုံးပြုပါ - ကိုယ်ပိုင် cryptographic implementation သည် ပေါက်ကြားမှု အန္တရာယ်များစွာကို ဖန်တီးတတ်သည်။

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

javascript
function checkAccess(user, action) {
  const authenticated = Boolean(user && user.sessionValid);
  if (!authenticated) {
    return { authenticated: false, authorized: false, result: "denied: not logged in" };
  }

  const permissions = {
    user: ["view own account", "edit own account"],
    admin: ["view own account", "edit own account", "manage all users", "delete any account"],
  };

  const authorized = (permissions[user.role] || []).includes(action);
  return {
    authenticated: true,
    authorized,
    result: authorized ? "allowed" : "denied: not authorized for this action",
  };
}

const regularUser = { sessionValid: true, role: "user" };
console.log("Regular user deletes another account:", checkAccess(regularUser, "delete any account"));
console.log("Regular user edits own account:", checkAccess(regularUser, "edit own account"));
You should see
ပုံမှန် user ၏ delete ကြိုးစားမှုကို authenticated: true, authorized: false အဖြစ်နှင့် ကိုယ်ပိုင် account edit ကို authenticated: true, authorized: true အဖြစ် log ထုတ်သည်။

၅ မိနစ် စမ်းကြည့်

code ထဲသို့ admin user object တစ်ခု ထပ်ထည့်ပြီး admin ၏ 'delete any account' အတွက် checkAccess call သည် authorized: true ဖြစ်ကြောင်း အတည်ပြုပါ။

သတိလေးတစ်ချက်

login ဝင်ထားခြင်း (authenticated) သည် မည်သည့်လုပ်ဆောင်ချက်ကိုမဆို ပြုလုပ်ခွင့် (authorized) ရှိသည်ဟု အလိုအလျောက် ယူဆခြင်း - authorization ကို action တစ်ခုချင်းစီအတွက် စစ်ဆေးရမည်။

audited library (သို့) managed authentication provider ကို မမှီခိုဘဲ ကိုယ်ပိုင် password hashing scheme ရေးခြင်း။

Authentication (သို့) Authorization?

login ဝင်ထားသော ပုံမှန် user တစ်ဦးသည် အခြား user တစ်ဦး၏ account ကို ဖျက်ရန် ကြိုးစားပြီး system က ပိတ်ဆို့ထားသည်။ ဤသည်မှာ မည်သည့် concept ကို အကောင်အထည်ဖော်နေခြင်း ဖြစ်သနည်း?

MDN Web Docs - HTTP authenticationHow the Web Works

ဒီနေရာမှာ လူအများမှားတတ်တယ်

  • login ဝင်ထားခြင်း (authenticated) သည် မည်သည့်လုပ်ဆောင်ချက်ကိုမဆို ပြုလုပ်ခွင့် (authorized) ရှိသည်ဟု အလိုအလျောက် ယူဆခြင်း - authorization ကို action တစ်ခုချင်းစီအတွက် စစ်ဆေးရမည်။
  • audited library (သို့) managed authentication provider ကို မမှီခိုဘဲ ကိုယ်ပိုင် password hashing scheme ရေးခြင်း။
  • ဒီ course က system map တစ်ခုပါ — REST/DNS/Database/Security ကို နက်နက်ရှိုင်းရှိုင်း လေ့လာချင်ရင် API Tutorial, Cloud & Deployment, SQL, Cybersecurity tutorial တွေဆီ ဆက်သွားပါ။

လေ့ကျင့်ခန်း

code ထဲသို့ admin user object တစ်ခု ထပ်ထည့်ပြီး admin ၏ 'delete any account' အတွက် checkAccess call သည် authorized: true ဖြစ်ကြောင်း အတည်ပြုပါ။

You'll know it worked when: ပုံမှန် user ၏ delete ကြိုးစားမှုကို authenticated: true, authorized: false အဖြစ်နှင့် ကိုယ်ပိုင် account edit ကို authenticated: true, authorized: true အဖြစ် log ထုတ်သည်။

Authentication နှင့် Authorization | Thuta Learning