Authentication ဆိုတာ ဘာလဲ? Login၊ Session နှင့် OAuth ရှင်းပြချက်

Authentication ဆိုသည်မှာ အက်ပ်က အသုံးပြုသူ ဘယ်သူလဲ အတည်ပြုသော နည်းလမ်းဖြစ်သည် — ပုံမှန်အားဖြင့် သူသိသောအရာ (password)၊ သူ ရှိသောအရာ (ဖုန်း သို့မဟုတ် email သို့ ပို့သော code) သို့မဟုတ် အခြားယုံကြည်ရသော ဝန်ဆောင်မှုမှ identity (ဥပမာ "Google ဖြင့် sign in") တို့ကို စစ်ဆေးခြင်းဖြင့် ဖြစ်သည်။ အသုံးပြုသူကို authenticate လုပ်ပြီးသည်နှင့် အက်ပ်က session သို့မဟုတ် token ဖြင့် သူ့ကို မှတ်ထားသဖြင့် စာမျက်နှာတိုင်းတွင် ထပ်မံ login ဝင်ရန် မလိုပါ။ ထို သိပြီးသော အသုံးပြုသူ ဘာလုပ်ခွင့်ရှိသလဲ ဆုံးဖြတ်ခြင်းမှာ authorization ဟု ခေါ်သော သီးခြား အဆင့် ဖြစ်သည်။

AI ဖြင့် တည်ဆောက်သည့်အခါ ဘာကြောင့် အရေးကြီးသလဲ

login ထည့်ရန် တောင်းဆိုမှုသည် AI builder သို့ လူများ တောင်းဆိုသော အဖြစ်အများဆုံး အရာများထဲမှ တစ်ခုဖြစ်ပြီး အသေးအဖွဲ အမှားဖြစ်ရလွယ်ဆုံး အရာလည်း ဖြစ်သည်။ login စာမျက်နှာကို ဖန်တီးရန် ရိုးရှင်းသည်။ ခက်သည်မှာ ၎င်းပတ်လည်ရှိ အရာအားလုံး ဖြစ်သည်–

• Password များကို ဘေးကင်းစွာ သိမ်းထားပါသလား။
• private စာမျက်နှာ နှင့် API endpoint တိုင်းက ဘယ်သူ မေးနေသလဲ စစ်ဆေးပါသလား။
• login ဝင်ထားသော customer တစ်ဦးသည် URL ရှိ နံပါတ်ကို ပြောင်းခြင်းဖြင့် အခြား customer ၏ ဒေတာကို မြင်နိုင်ပါသလား။
• မည်သူမဆို password မေ့သွားလျှင် ဘာဖြစ်မလဲ။

အက်ပ်တစ်ခုသည် ထိုအရာများအားလုံး မအောင်မြင်ဘဲ လုံခြုံပုံပေါ်နိုင်သည်။ အစိတ်အပိုင်းများ ဘယ်လို အလုပ်လုပ်သလဲ နားလည်ထားခြင်းက မှန်ကန်သော မေးခွန်းများ မေးနိုင်ပြီး မှန်ကန်သော အရာများကို စမ်းသပ်နိုင်စေသည်။

နေ့စဉ်ဘဝ ဥပမာ

ဟိုတယ်တစ်ခုတွင် check-in လုပ်သည်ကို စဉ်းစားကြည့်ပါ။

ရှေ့စားပွဲတွင် ID ပြသည်။ ၎င်းသည် authentication ဖြစ်သည်– သင် ဘယ်သူလဲ သက်သေပြခြင်း။ ဝန်ထမ်းက key card တစ်ခု ပေးသည်။ ထို card သည် သင်၏ session ဖြစ်သည်– ကျန်ရှိသော တည်းခိုမှုအတွင်း ID ထပ်ပြရန် မလိုတော့ပါ၊ card ကို ပြရုံသာ။

card က သင့်အခန်း၊ ဂျင်မ်နှင့် သင့်ထပ်သို့ lift ကို ဖွင့်ပေးသည် – သို့သော် အခြားဧည့်သည်များ၏ အခန်းများ သို့မဟုတ် ဝန်ထမ်းရုံးကို မဖွင့်ပေးပါ။ ၎င်းသည် authorization ဖြစ်သည်– သင့် identity ဝင်ရောက်ခွင့်ရှိသော အရာများ။ card ပျောက်လျှင် ဟိုတယ်က စားပွဲတွင် ပိတ်နိုင်သည် (session ကို ပယ်ဖျက်ခြင်း)။ ထွက်သည့်အခါ အလုပ်မလုပ်တော့ပါ (logout သို့မဟုတ် သက်တမ်းကုန်ခြင်း)။

"Google ဖြင့် sign in" ဆိုသည်မှာ ဟိုတယ်က သင့် ID ကို ကိုယ်တိုင် မစစ်ဘဲ ယုံကြည်ရသော မိတ်ဖက်မှ "ဤသူသည် ဤသူဖြစ်သည်" ဟူသော စာကို လက်ခံသည်နှင့် တူသည်။

အဓိက login နည်းလမ်းများ

Password များကို ဘယ်လို သိမ်းသင့်သလဲ

လုံခြုံသော အက်ပ်သည် သင့် password အစစ်ကို ဘယ်တော့မှ မသိမ်းပါ။ ၎င်းအစား hash ကို သိမ်းသည်– password ကို ပုံသေ string အဖြစ် ပြောင်းသည့် one-way function ၏ ရလဒ်။ login ဝင်သောအခါ အက်ပ်က သင်ရိုက်ထည့်သည့်အရာကို hash လုပ်ပြီး သိမ်းထားသော hash နှင့် နှိုင်းယှဉ်သည်။

ဤနည်းကို ဘေးကင်းစေသော အသေးစိတ် နှစ်ခု–

• Salt — hash မလုပ်မီ password တစ်ခုစီတွင် ထည့်သော ကျပန်းတန်ဖိုး၊ ထို့ကြောင့် password တူသော လူနှစ်ဦးက မတူသော hash ရရှိပြီး ကြိုတင်တွက်ထားသော lookup table များ အသုံးမဝင်တော့ပါ။
• Password အတွက် ရည်ရွယ်ထားသော နှေးသော algorithm — ဥပမာ Argon2၊ bcrypt သို့မဟုတ် scrypt။ MD5 သို့မဟုတ် SHA-256 ကဲ့သို့ ယေဘုယျ hash များသည် တစ်ခုတည်းဖြင့် အလွန်မြန်လွန်းသည်; တိုက်ခိုက်သူများက ခန့်မှန်းချက် ဘီလီယံ ကြိုးစားနိုင်သည်။

Hashing သည် encryption နှင့် တူသည် မဟုတ်ပါ။ encrypt လုပ်ထားသော ဒေတာကို key ဖြင့် decrypt လုပ်နိုင်သည်; password hash ကို ပြန်လှန်၍ မရအောင် ဒီဇိုင်းထုတ်ထားသည်။

Session နှင့် token များ

login ပြီးနောက် အက်ပ်သည် request တိုင်းတွင် သင့်ကို မှတ်မိရန် လိုသည်။ နည်းလမ်းနှစ်မျိုး အများဆုံး ရှိသည်။

cookie များအတွက် ဆက်တင် သုံးခုက အရေးကြီးသည် – HttpOnly (စာမျက်နှာရှိ JavaScript က cookie ကို ဖတ်၍ မရ)၊ Secure (HTTPS ဖြင့်သာ ပို့သည်) နှင့် SameSite (အခြား site များမှ request များတွင် ပို့ခြင်းကို ကန့်သတ်သည်)။ browser ၏ localStorage တွင် token သိမ်းခြင်းသည် အလွန်သာမန် ဖြစ်သော်လည်း စာမျက်နှာပေါ်တွင် run သော script မှန်သမျှ ၎င်းတို့ကို ဖော်ထုတ်နိုင်သည်။

OAuth နှင့် "Google ဖြင့် sign in"

OAuth 2.0 သည် ကိုယ်စားပြု authorization အတွက် စံနှုန်းဖြစ်သည်– အက်ပ်တစ်ခုက အခြားဝန်ဆောင်မှုရှိ သင့် account သို့ ကန့်သတ်ထားသော ဝင်ရောက်ခွင့် ရယူနိုင်စေသည် – ဥပမာ သင့် Google Calendar ကို ဖတ်ခွင့် – Google password ကို ဘယ်တော့မှ မမြင်ဘဲ။ သင့်ကို Google သို့ ပို့ပြီး scope ဟု ခေါ်သော သတ်မှတ်ထားသည့် ခွင့်ပြုချက်များကို အတည်ပြုသည်၊ ထို့နောက် Google က ထိုခွင့်ပြုချက်များအတွက်သာ token ကို အက်ပ်သို့ ပေးသည်။

OAuth ကိုယ်တိုင်သည် ဝင်ရောက်ခွင့် ပေးရန် ဒီဇိုင်းထုတ်ထားပြီး သင် ဘယ်သူလဲ ပြောရန် မဟုတ်ပါ။ OpenID Connect (OIDC) သည် OAuth 2.0 ၏ အပေါ်တွင် identity ထည့်သော အလွှာ ဖြစ်ပြီး "Google ဖြင့် sign in" သို့မဟုတ် "Apple ဖြင့် sign in" က အသုံးပြုသည်။ setup လုပ်ရန် provider တွင် အက်ပ်ကို မှတ်ပုံတင်ပြီး client ID နှင့် client secret ရယူသည်; secret ကို သင့် server တွင်သာ ထားသည်။

အလုပ်လုပ်ပုံ ဥပမာ – client portal အတွက် login

ဒီဇိုင်း agency ၏ client များက သူတို့၏ ပရောဂျက်များနှင့် invoice များ မြင်ရသော portal တစ်ခု တည်ဆောက်နေသည်ဆိုပါစို့။

• Authentication: client များသည် email နှင့် magic link ဖြင့် login ဝင်သဖြင့် စီမံရန် password မရှိ။ agency ဝန်ထမ်းများက Google Workspace account ဖြင့် login ဝင်သည်။
• Role များ: အသုံးပြုသူတစ်ဦးစီတွင် role တစ်ခု ရှိသည် – client သို့မဟုတ် staff။
• Authorization စည်းမျဉ်းများ:

• ဘယ်မှာ ပြဋ္ဌာန်းသလဲ: request တိုင်းအတွက် server ပေါ်တွင်။ server က login ဝင်ထားသော အသုံးပြုသူကို ရှာပြီး project.company_id သည် အသုံးပြုသူ၏ ကုမ္ပဏီနှင့် ကိုက်ညီသော ပရောဂျက်များကိုသာ ပြန်ပေးသည်။ "Mark paid" ခလုတ်ကို ဝှက်ထားခြင်းသည် မလုံလောက်ပါ – endpoint ကိုယ်တိုင် ငြင်းပယ်ရမည်။

ဝေါဟာရ ရှင်းလင်းချက်များ

အမှားများနှင့် အထင်အမြင်မှားများ

• စာမျက်နှာတွင်သာ ခွင့်ပြုချက် စစ်ခြင်း။ browser က ခလုတ်ကို ဝှက်ထားသော်လည်း API က မစစ်လျှင် မည်သူမဆို API ကို တိုက်ရိုက် ခေါ်နိုင်သည်။
• URL မှ ID များကို ယုံခြင်း။ /invoices/1042 သည် invoice 1042 သည် login ဝင်ထားသော အသုံးပြုသူ၏ ဖြစ်ကြောင်း စစ်ရမည်။
• Crypto ကိုယ်တိုင် ရေးခြင်း။ လူသိများသော library သို့မဟုတ် provider များကို သုံးပါ; AI က hashing scheme ကို ဖန်တီးခွင့် မပေးပါနှင့်။
• အားနည်းသော password reset။ reset link များသည် တစ်ကြိမ်သာ သုံးနိုင်ပြီး လျင်မြန်စွာ သက်တမ်းကုန်ရမည်၊ email တွင် account ရှိမရှိ မပြသင့်ပါ။
• သင့် login နှင့် builder ၏ login ကို ရောထွေးခြင်း။ အက်ပ်၏ အသုံးပြုသူများသည် သင် တည်ဆောက်သော tool ပေါ်ရှိ သင့် account နှင့် သီးခြားဖြစ်သည်။
• Login တွင် rate limit မရှိခြင်း။ မရှိလျှင် တိုက်ခိုက်သူများက password များကို အဆုံးမဲ့ ကြိုးစားနိုင်သည်။

AI builder ကို ဘာတောင်းဆိုရမလဲ

• "[လူသိများသော library သို့မဟုတ် provider တစ်ခု] ဖြင့် sign-up နှင့် login ထည့်ပါ။ password hashing ကို ကိုယ်ပိုင် မရေးပါနှင့်။"
• "password များကို bcrypt သို့မဟုတ် Argon2 ဖြင့် hash လုပ်ပြီး သိမ်းပါ။"
• "session အတွက် HttpOnly၊ Secure cookie များကို သုံးပါ။"
• "role နှစ်ခု ထည့်ပါ: admin နှင့် member။ endpoint တိုင်းနှင့် ခေါ်ခွင့်ရှိသော role များကို စာရင်းပြုစုပါ။"
• "အသုံးပြုသူများသည် ကိုယ့် record များကိုသာ ဖတ်နိုင်ပြီး တည်းဖြတ်နိုင်ကြောင်း server ပေါ်တွင် ပြဋ္ဌာန်းပါ။ ထို့နောက် မည်သို့ စစ်ဆေးခဲ့သလဲ ပြပါ။"
• "တစ်နာရီအတွင်း သက်တမ်းကုန်သော တစ်ကြိမ်သုံး link များဖြင့် password reset ထည့်ပါ။"
• "login ကြိုးစားမှုများကို rate-limit လုပ်ပါ။"

ထို့နောက် ကိုယ်တိုင် စမ်းကြည့်ပါ: account နှစ်ခု ဖန်တီးပြီး တစ်ခု၏ အချက်အလက်ကို အခြားတစ်ခု login ဝင်ထားစဉ် ဝင်ကြည့်ရန် ကြိုးစားပါ။ login ထည့်ခြင်း လမ်းညွှန် နှင့် လုံခြုံရေး checklist တို့က ပိုအသေးစိတ် ပေးသည်။

Mythex တွင် Authentication

Mythex သည် သင့်အက်ပ်၏ အသုံးပြုသူများအတွက် built-in auth product မပေးပါ; သင်က နည်းလမ်းကို ရွေးသည် – သင့်ပရောဂျက်၏ ဒေတာဘေ့စ် တွင် သိမ်းသော email နှင့် password၊ သို့မဟုတ် hosted provider ၏ SDK – ထို့နောက် agent ကို ထည့်ရန် တောင်းဆိုသည်။ provider key များကို chat တွင် မဟုတ်ဘဲ ပရောဂျက် secret များတွင် ထည့်ပါ။ ၎င်းသည် Mythex ကိုယ်တိုင်သို့ သင် sign in လုပ်ပုံနှင့် သီးခြားဖြစ်သည်။ အက်ပ်သို့ login ထည့်ခြင်း docs recipe တွင် သင်ပြင်သုံးနိုင်သော starter prompt ရှိသည်၊ ထို server-side စစ်ဆေးမှုများ ဘယ်မှာ နေသလဲကို API ဆိုတာ ဘာလဲ က ရှင်းပြသည်။

မေးခွန်းများ