နားလည်ထားရမယ့် အချက်
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 တစ်ဦးအား မည်သည့်အရာများ ပြုလုပ်ခွင့်ပေးမည်ဆိုသည်ကို ဆုံးဖြတ်သည့် လုပ်ငန်းစဉ်
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 သည် ပေါက်ကြားမှု အန္တရာယ်များစွာကို ဖန်တီးတတ်သည်။
အတူတူ စမ်းရေးကြည့်မယ်
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"));ပုံမှန် 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?
MDN Web Docs - HTTP authentication — How the Web Works