user
Web Development မှာ Authentication, Authorization ဆိုတာ ဘယ်လိုမျိုးလဲ
သေချာ ရှင်းလင်းစွာ ပြောပြပေးပါ


assistant
𝐀𝐜𝐜𝐞𝐬𝐬 𝐂𝐨𝐧𝐭𝐫𝐨𝐥
အင်တာနက်ပေါ်မှာ မီလီယံနဲ့ချီတဲ့ device တွေ ရှိနေတယ်။ အဲဒီ device တွေပေါ်မှာ သိမ်းထားတဲ့ ဖိုင်၊ ဓာတ်ပုံ၊ ဗီဒီယို စသဖြင့် resource တွေ၊ နောက်ပြီး run ထားတဲ့ program တွေရှိပါမယ်။ ဒါပေမယ့် အဲဒီထဲက ကြိုက်တဲ့ device ကို တံခါးသွားခေါက်ပြီး information တောင်းလို့ရတာမျိုးတော့ မဟုတ်ပါဘူး။
တကယ်လို့ ကိုယ်က public နဲ့ information မျှဝေချင်တယ်ဆိုရင် နည်းလမ်းတခုက ကိုယ့် device ကို လာရောက် ဆက်သွယ်ပြီး resource တွေရယူနိုင်ကြောင်း world wide web (www) ပေါ်ကတဆင့် ကြေညာထားဖို့ပါပဲ။ ဒါပေမယ့် အင်တာနက်ပေါ်မှာ ဘယ်ဟာမှ မလုံခြုံဘူး ဆိုတဲ့အတိုင်း Infrastructure, Network, Application layer အဆင့်ဆင့်မှာ secuirty mechanism တွေ ထားကြရပါတယ်။

𝐀𝐩𝐩𝐥𝐢𝐜𝐚𝐭𝐢𝐨𝐧 𝐬𝐞𝐜𝐮𝐫𝐢𝐭𝐲
Application layer security မှာ အဓိကကျတဲ့အရာ နှစ်ခုရှိပါတယ်။ ငါတို့ချင်း သိကြလား (Authentication) နဲ့ လုပ်ခွင့်ရှိလား (Authorization) တို့ပါပဲ။
ကိုယ့် Application ကို www ပေါ်မှာ ကြေညာပြီး public access ပေးထားလိုက်တဲ့အခါ url ကိုသိတဲ့ ဘယ်သူမဆို စက်ထဲက resource တွေကို အသုံးပြုခွင့်ရှိတဲ့သဘော ဖြစ်သွားပါတယ်။ ဒါကို ကာကွယ်ဖို့အတွက် Application တွေဟာ user management (access control) ကိုစီမံထားရပါတယ်။ 

𝐀𝐮𝐭𝐡𝐞𝐧𝐭𝐢𝐜𝐚𝐭𝐢𝐨𝐧
Application ကောင်းတခုမှာ Access control ဆိုတာ မပါမဖြစ်လို့တောင် ပြောနိုင်တယ်။ User တွေကို registration လုပ်ခွင့်ပေးတယ်။ username နဲ့ password ကို database ထဲသိမ်းတယ်။ log in ဝင်ခွင့်ပေးတယ်။ sign out လုပ်ခွင့်ပေးတယ်။ လိုအပ်ရင် password change/reset လုပ်ခွင့်ပေးတယ်။ ဒီတော့ ကျွန်တော်တို့ program အနေနဲ့ ဆက်သွယ်လာတဲ့ သူတွေကို username နဲ့ password မှန်အောင်ပြော၊ မပြောရင် resource တွေသုံးခွင့်မပေးဘူးလို့ ယတိပြတ် ငြင်းလိုက်နိုင်တယ်။ ငါတို့ချင်း သိကြလား (Authentication) ဆိုတာ အဲဒါပါပဲ။
ဥပမာအနေနဲ့ Facebook, ChatGPT နဲ့ တခြား www ပေါ်က platform တွေကို ကြည့်မယ်ဆိုရင် အများစုက ခိုင်ခံ့တဲ့၊ မလှိမ့်တပတ် လုပ်ဖို့ မလွယ်ကူတဲ့ Authentication စနစ်တွေ ထည့်ဆောက်ထားတာ မြင်ရမှာပါ။

𝐀𝐮𝐭𝐡𝐨𝐫𝐢𝐳𝐚𝐭𝐢𝐨𝐧
ဒါပေမယ့် ငါတို့ချင်း သိကြတယ်ဆိုတာနဲ့ပဲ user ကို ကိုယ့် resource တွေအကုန် ပေးသုံးလို့ဖြစ်ရဲ့လား။ ဒီမေးခွန်းရဲ့ အဖြေက ကိုယ်ဆောက်မယ့် platform အပေါ် မူတည်နိုင်ပေမယ့် ၉၉ ရာနှုန်းနီးပါးက ဟင့်အင်းပါ။ တကယ်လို့ Apple iCloud လိုမျိုး Storage platform မှာ log in ဝင်နိုင်တဲ့ user တိုင်းက တခြား user တွေသိမ်းထားတဲ့ ဓာတ်ပုံတွေပါ ကြည့်လို့ရနေမယ်ဆိုရင် အကုန်ဂွမ်းကုန်ပါလိမ့်မယ်။
ဒါကြောင့် လုပ်ခွင့်ရှိလား (Authorization) ကလည်း Application တွေမှာ မဖြစ်မနေ လိုအပ်တဲ့ အရာတခုဖြစ်တယ်။ Authorization ရဲ့သဘောကတော့ user တွေကို ပိုင်ရှင်၊ Admin၊ Auditor စသဖြင့် အထူးအခွင့်အရေးတွေ ပေးလိုက်တာဖြစ်ပြီး ကိုယ်နဲ့မဆိုင်တဲ့ resource တွေကို အသုံးပြုခွင့် ကန့်သတ်လိုက်တာပါပဲ။
ဥပမာ facebook မှာဆိုရင် ကိုယ်ရေးထားတဲ့ post တွေကိုပဲ edit လုပ်ခွင့်ရှိပါတယ်။ သူများ post ဆိုရင် edit လုပ်လို့မရ၊ ဖျက်လို့မရနိုင်ပဲ ဖတ်လို့သာ ရတာကို တွေ့ရပါလိမ့်မယ်။ ဒါပေမယ့် Group Admin တွေဆိုရင် member တွေရဲ့ post ကိုပြင်လို့မရသည့်တိုင် ဖျက်လို့တော့ ရတာကို တွေ့ရပါလိမ့်မယ်။ ဒါက လုပ်ခွင့်ရှိလား (Authorization) ဆိုတဲ့ mechanism ရဲ့ ဥပမာတခုပါ။

လက်တွေ့ 𝐀𝐮𝐭𝐡𝐞𝐧𝐭𝐢𝐜𝐚𝐭𝐢𝐨𝐧/𝐀𝐮𝐭𝐡𝐨𝐫𝐢𝐳𝐚𝐭𝐢𝐨𝐧
ဒီတော့ ​Authentication နဲ့ Authorization ကို ကျွန်တော်တို့ application တွေမှာ လက်တွေ့ ဘယ်လိုလုပ်ကြမလဲ။ အခုပြောသွားတာတွေက သီအိုရီပဲ ရှိသေးတာ မဟုတ်လား။
Authentication နဲ့ပတ်သက်လာရင် "ငါတို့ချင်း သိကြတယ်" လို့ အတည်ပြုနိုင်ဖို့အတွက် သိထားရမယ့် အခြေခံအကျဆုံး ၃ နည်းရှိပါတယ်။
1. 𝐄𝐧𝐜𝐨𝐝𝐞𝐝 𝐄𝐱𝐜𝐡𝐚𝐧𝐠𝐞
ပထမနည်းလမ်းကတော့ resource တွေ လှမ်းယူတိုင်းမှာ username နဲ့ password ကို encoding လုပ်ပြီး ထည့်ပေးလိုက်တာပါပဲ။ server program အနေနဲ့ database မှာသိမ်းထားတဲ့ user စာရင်းထဲမှာ ကိုယ့် credential ကိုတွေ့တယ်ဆိုရင် ငါတို့ချင်း သိကြတယ်လို့ အတည်ပြုပြီး တောင်းဆိုလာတဲ့ resource တွေကို ပြန်ပေးလိုက်မှာဖြစ်တယ်။
ဒီနည်းရဲ့ အားသာချက်က အသုံးပြုဖို့ အရမ်းကို ရိုးရှင်းလွန်းတာပါပဲ။ အားနည်းချက်ကတော့ အခေါက်တိုင်းလိုလို ကိုယ့် username နဲ့ password ကို အင်တာနက်ပေါ်ကတဆင့် ပို့ပေးနေရတာက security ယိုပေါက်ကြီးဆိုတာ ပြောဖို့ မလိုပါဘူး။ ဒီနေရာကို နားမလည်ဘူးဆိုရင် ရှေ့တခန်းမှာ ပြောခဲ့တဲ့ အင်တာနက်အကြောင်းကို ပြန်နားထောင်ကြည့်သင့်ပါတယ်။ နောက်တချက်က အခေါက်တိုင်းလိုလို server အနေနဲ့ database ကိုဖတ်ပြီး အတည်ပြုရတဲ့အတွက် မလိုအပ်ပဲ ဖြုန်းတီးမှုတွေ ဖြစ်စေပါတယ်။ လက်တွေ့ဘဝမှာ database နဲ့ server ကို စက်တခုတည်းပေါ် ထားလေ့မရှိပဲ နောက်စက်တခုကို သွားမေးရတဲ့ ကြာချိန်တွေက ဒီနည်းလမ်းက ၃ ခုထဲမှာ လူသုံးအနည်းဆုံး ဖြစ်နေစေတယ်။
2. 𝐒𝐞𝐬𝐬𝐢𝐨𝐧 𝐚𝐧𝐝 𝐜𝐨𝐨𝐤𝐢𝐞
ဒုတိယနည်းလမ်းကတော့ ငါတို့ချင်း သိကြတယ်လို့ တကြိမ် အတည်ပြုလိုက်ပြီးတဲ့အခါ user အတွက် id တခုထုတ်ပြီး server ပေါ်မှာ သိမ်းထားလိုက်ပြီး ဒါကို session လို့ခေါ်ပါတယ်။ user ကိုလည်း နောက်အခေါက်တွေမှာ username နဲ့ password အစား id ယူခဲ့ရင် ရပါပြီလို့ id ကို သိမ်းထားဖို့ ပြန်ပေးလိုက်တယ်။ id ကို browser ပေါ် cookie အဖြစ်သိမ်းထားမှာဖြစ်ပြီး id က,တရားဝင်နေသေးသရွေ့ နောက်အခေါက်တွေမှာ credential ပို့ဖို့ မလိုတော့ပဲ security ပြဿနာကို အတန်အသင့် ဖြေရှင်းလိုက်နိုင်ပါတယ်။ server အတွက်ဆိုရင်လည်း အတည်ပြုစာရင်းမှာ id ပါမပါ စစ်ကြည့်ရုံဖြစ်တဲ့အတွက် performance ပြဿနာ မရှိတော့ပါဘူး။
ဒါဆို ဘာပြဿနာရှိတာလဲ။ ပထမတချက်က user တွေက ရာနှုန်းပြည့် ယုံလို့ရတယ်ဆိုတာမျိုး မရှိတာပါပဲ။ cookie တွေက 4kb လောက်ပဲ သိမ်းထားနိုင်တဲ့ အားနည်းချက် ရှိသလို user ဖက်က အမှားလုပ်မိရင်ဖြစ်ဖြစ်၊ ရည်ရွယ်ချက်ရှိရှိ တိုက်ခိုက်ချင်ရင်ဖြစ်ဖြစ် cookie ကို ပြောင်းလိုက်ဖို့က သိပ်ခက်တဲ့ကိစ္စ မဟုတ်လို့ပါဘူး။
နောက်တချက်က လက်တွေ့မှာ server ဆိုတာ တခုတည်း ရှိတာ မဟုတ်ပါဘူး။ ဒီ server program ကိုပဲ ရာထောင်ချီအောင် run ထားကြပြီး request တွေကို ဖြန့်ဝေ လက်ခံကြတာပါ။ ဘယ်လိုဖြန့်ဝေမယ်ဆိုတာကို အထူး server တမျိုး (Load Balancer) ကတာဝန်ယူထားပြီး user တွေအနေနဲ့ ရွေးချယ်ခွင့် မရှိပါဘူး။ ဒါကြောင့် server တခုမှာ အတည်ပြုပြီး ဖြစ်ရင်တောင် နောက် server ဆီကို ရောက်သွားရင် id က အသုံးမဝင်တော့ပါဘူး။ ဥပမာ Netflix ဆိုရင် ရုပ်ရှင်ကြည့်လို့ရတဲ့ streaming program ချည်းကိုပဲ သန်းနဲ့ချီအောင် run ထားတာပါ။
ဒီပြဿနာကို ဖြေရှင်းဖို့အတွက် အတည်ပြုစာရင်းကို server တခုတည်းပေါ်မှာပဲ file အနေနဲ့ သိမ်းတတ်ကြတဲ့ ပုံစံကနေ ရှိသမျှ server အကုန်လုံးက ဝင်ကြည့်နိုင်တဲ့ in-memory cache တွေကို ပြောင်းသုံးလာကြပါတယ်။ သုံးမယ်ဆို သုံးလို့ရတဲ့ နည်းလမ်းဖြစ်ပေမယ့် သန်းနဲ့ချီတဲ့ user တွေကို မှတ်ရမယ်ဆိုရင် တတိယ နည်းလမ်း ရှိပါသေးတယ်။
3. 𝐓𝐨𝐤𝐞𝐧