App သို့ Login ထည့်နည်း- Password၊ Magic Link၊ Google နှင့် Role များ

App သို့ login ထည့်ရန် နည်းလမ်းတစ်ခု ရွေးပါ- email နှင့် password၊ magic link (သင်ပို့သော တစ်ကြိမ်သုံး sign-in လင့်ခ်)၊ သို့မဟုတ် "Sign in with Google"- ထို့နောက် proven auth library သို့မဟုတ် hosted provider ဖြင့် အကောင်အထည်ဖော်ပါ၊ ကိုယ်တိုင် အစမှ မရေးပါနှင့်။ ထို့နောက် အသုံးပြုသူအမျိုးအစားတစ်ခုစီ ဘာလုပ်ခွင့်ရှိသည်ကို ဆုံးဖြတ်ပါ (role များ)၊ ၎င်းကို စာမျက်နှာ နှင့် API request တိုင်းအတွက် server ပေါ်တွင် တင်းကျပ်စွာ ပြဋ္ဌာန်းပါ။ Session များသည် secure cookie သုံးရမည်၊ သက်တမ်းကုန်ရမည်နှင့် logout တွင် မှန်ကန်စွာ ပြီးဆုံးရမည်။

ဤလမ်းညွှန်သည် ရွေးချယ်မှု တစ်ခုစီနှင့် လုပ်ရမည့် အသေးစိတ်များကို ဖော်ပြသည်၊ အလုပ်လုပ်သော login နှင့် လုံခြုံသော login ကို ခွဲခြားပေးသည်။ အယူအဆများအတွက် authentication ဆိုတာ ဘာလဲ ကို ကြည့်ပါ။

အသုံးပြုသူများတွင် ကိုယ်ပိုင် ဒေတာ ရှိသည် (ကိုယ်ပိုင် booking များ၊ စာရွက်စာတမ်းများ၊ ငွေတောင်းခံလွှာများ)
အသုံးပြုသူများက အခြားသူများ မြင်မည့်အရာကို ပြောင်းလဲနိုင်သည်
သင် ဝင်ခွင့်အတွက် ငွေယူသည်
ကွဲပြားသော လူများ ကွဲပြားသော ခွင့်ပြုချက် လိုအပ်သည် (ပိုင်ရှင် vs ဝန်ထမ်း vs customer)

Marketing site၊ public directory သို့မဟုတ် သင့်ကို အီးမေးလ် ပို့ပေးသော form အတွက် မလိုနိုင်ပါ။ Waitlist တွင် account မလို၊ အီးမေးလ် field တစ်ခုလောက်ဆိုလျှင် လုံလောက်သည်။

နည်းလမ်း	ဘယ်လို အလုပ်လုပ်သလဲ	အကောင်း	အားနည်း
Email + password	အသုံးပြုသူက password ဖန်တီးသည်၊ သင်က hash ကို သိမ်းသည်	ရင်းနှီးသည်၊ အီးမေးလ်မရှိလည်း အလုပ်လုပ်သည်	Password reset၊ ပြန်သုံးခြင်း၊ ယိုဖိတ်ခြင်း၊ password ကို လုံခြုံစွာ သိမ်းရမည်
Magic link	အသုံးပြုသူက အီးမေးလ် ရိုက်သည်၊ သင်ပို့သော လင့်ခ်ကို နှိပ်သည်	Password သိမ်းစရာ သို့မဟုတ် မေ့စရာ မရှိ	အီးမေးလ် ပို့ခြင်းအပေါ် မူတည်သည်၊ login ပိုနှေး
တစ်ကြိမ်သုံး code	အသုံးပြုသူက အီးမေးလ် ရိုက်သည်၊ 6-digit code ကို ရိုက်ထည့်သည်	လင့်ခ်များ မှားသော browser တွင် ဖွင့်သည့်အခါ အလုပ်လုပ်သည်	အီးမေးလ် မှီခိုမှု အတူတူ
Social / OAuth (Google၊ Apple၊ GitHub၊ Microsoft)	နောက်ထပ် provider က အသုံးပြုသူ ဘယ်သူလဲ အတည်ပြုသည်	အသုံးပြုသူအတွက် အမြန်ဆုံး၊ သင် password သိမ်းစရာ မရှိ	အသုံးပြုသူမှာ ထို account ရှိရမည်၊ provider တွင် setup လုပ်ရမည်

App အများအပြားက နှစ်ခုကို ပေါင်းသည်- Google sign-in နှင့် email magic link ပေါင်းခြင်းသည် password တစ်ခုမှ မသိမ်းဘဲ လူအများစုကို လွှမ်းခြုံသော လူကြိုက်များ တွဲစပ်မှု ဖြစ်သည်။

Email နှင့် password

Password ပေးပါက အောက်ပါတို့သည် မဖြစ်မနေ-

Password ကို နှေးသော password-hashing algorithm ဖြင့် hash လုပ်ပါ။ OWASP ၏ password သိမ်းဆည်းမှု လမ်းညွှန်ချက်က Argon2id ကို အကြံပြုပြီး scrypt၊ bcrypt သို့မဟုတ် PBKDF2 ကို အစားထိုးရွေးချယ်စရာအဖြစ် ဖော်ပြသည်။ Password ကို plain text သို့မဟုတ် မြန်သော general hash ဖြင့် ဘယ်တော့မှ မသိမ်းပါနှင့်။
Password reset သည် ကျပန်း၊ တစ်ကြိမ်သုံးသော၊ သက်တမ်းကုန်သော လင့်ခ်ကို အတည်ပြုထားသော အီးမေးလ်သို့ ပို့ရမည်။
မည်သည့် အီးမေးလ်တွင် account ရှိသည်ကို မပြပါနှင့်။ "ထိုအီးမေးလ် မှတ်ပုံတင်ထားပါက reset လင့်ခ် ပို့ပြီးပါပြီ" သည် "account မတွေ့ပါ" ထက် ပိုကောင်းသည်။
Login နှင့် reset ကြိုးစားမှုများကို rate-limit လုပ်ပါ password ခန့်မှန်းခြင်းကို နှေးစေရန်။
Password ရှည်ခွင့်ပြုပြီး password manager ကို ခွင့်ပြုပါ၊ ထူးခြားသော character ရောစပ်မှု ခိုင်းသော စည်းမျဉ်းများကို ရှောင်ပါ။

Magic link နှင့် တစ်ကြိမ်သုံး code

Magic link သည် အသုံးပြုသူထံ ပို့သော sign-in လင့်ခ် ဖြစ်သည်။ နှိပ်လိုက်လျှင် အသုံးပြုသူ login ဝင်သည်။ တစ်ကြိမ်သုံး code သည် တူညီသော စိတ်ကူးဖြစ်သော်လည်း နှိပ်ခြင်းအစား ရိုက်ထည့်ရသည်။

လင့်ခ်နှင့် code များသည် လျင်မြန်စွာ သက်တမ်းကုန်ပြီး တစ်ကြိမ်သာ အလုပ်လုပ်ရမည်။
လင့်ခ်သည် နှိပ်သော စက်ပေါ်တွင် အသုံးပြုသူကို login ဝင်စေရမည်၊ token သည် log နှင့် analytics tool များတွင် မကျန်ရစ်ရပါ။
ယုံကြည်ရသော အီးမေးလ် ပို့ခြင်း လိုအပ်သည်- app မှ အီးမေးလ် ပို့နည်း ကို ကြည့်ပါ။ Gmail နှင့် Outlook တွင် စမ်းပြီး spam folder ကို စစ်ပါ။

"Sign in with Google" သည် OAuth နှင့် OpenID Connect ကို သုံးသည်- Google က အသုံးပြုသူ ဘယ်သူလဲ အတည်ပြုပြီး သင့် app သို့ အီးမေးလ်နှင့် အမည်ကို ပြောပြသည်။ ၂၀၂၆ စက်တင်ဘာလအထိ setup သည် Google Cloud Console ရှိ Google Auth Platform အပိုင်းတွင် ဖြစ်သည်-

Project ဖန်တီးပါ သို့မဟုတ် ရွေးပါ၊ Branding စာမျက်နှာကို ဖြည့်ပါ- consent screen တွင် အသုံးပြုသူများ မြင်ရမည့်အရာ (app အမည်၊ support အီးမေးလ်၊ logo)။
Clients စာမျက်နှာတွင် "Web application" အမျိုးအစား client ဖန်တီးပါ။
Authorized JavaScript origins နှင့် redirect URI များ ထည့်ပါ- သင့် app ရှိ တိကျသော လိပ်စာများနှင့် sign-in ပြီးနောက် Google က အသုံးပြုသူများ ပြန်ပို့မည့် လိပ်စာများ။
Client ID နှင့် client secret ကို app ၏ secret များတွင် သိမ်းပါ။

Google ၏ OAuth documentation အရ အဖြစ်များသော ပြဿနာများ-

redirect_uri_mismatch- redirect လိပ်စာသည် အတိအကျ ကိုက်ညီရမည်၊ http နှင့် https၊ စာလုံးအကြီးအသေး နှင့် trailing slash အပါအဝင်။ Preview လိပ်စာတစ်ခုနှင့် live domain တစ်ခုအတွက် ထည့်ပါ။
HTTPS လိုအပ်သည်- redirect URI များသည် HTTPS သုံးရမည်၊ development အတွက် localhost မှလွဲ၍။
state parameter ကို ပြန်ရောက်သောအခါ စစ်ရမည်၊ cross-site request forgery မှ ကာကွယ်ရန်။ ကောင်းသော library များက ၎င်းကို သင့်အတွက် လုပ်ပေးသည်။

အခြေခံ sign-in အချက်အလက် (အမည်၊ အီးမေးလ်၊ profile) ကိုသာ တောင်းပါက Google က app verification မမဖြစ်မနေ ဟု ပြောသည်။ အသုံးပြုသူများ၏ Gmail၊ Drive သို့မဟုတ် Calendar ကို ဝင်ရောက်ခွင့် တောင်းခြင်းမှာ ကွဲပြားပြီး verification လိုအပ်သည်။

ကိုယ်တိုင်တည်ဆောက်မလား၊ provider သုံးမလား?

ချဉ်းကပ်ပုံ	ဥပမာများ	ဘယ်အခါ သင့်တော်သလဲ
Hosted auth provider	Sign-in၊ အသုံးပြုသူ စီမံခန့်ခွဲမှုနှင့် session များကို သင့်အတွက် host လုပ်ပေးသော ဝန်ဆောင်မှုများ	Login ကို လျင်မြန်စွာ အလုပ်လုပ်စေချင်ပြီး လုံခြုံရေး တာဝန် နည်းချင်သောအခါ
App ထဲရှိ auth library	Framework အတွက် open-source library များ	အသုံးပြုသူများကို ကိုယ်ပိုင် database တွင် ထားချင်ပြီး per-user ကြေးမရှိစေချင်သောအခါ
ကိုယ်တိုင် ရေးခြင်း	—	တော်တော်ရှားသည်။ သေးငယ်သော အသေးစိတ်များ အများအပြား

ပထမနှစ်ခုလုံး သင့်တော်သည်။ Hosted provider များက ပိုများများ ကိုင်တွယ်ပေးသော်လည်း dependency တစ်ခု ထည့်ပြီး အသက်ဝင်သော အသုံးပြုသူ တစ်ဦးလျှင် ကုန်ကျစရိတ် ရှိနိုင်သည်၊ လက်ရှိ စျေးနှုန်းကို ၎င်းတို့ site တွင် စစ်ပါ။ Library များက ဒေတာကို ကိုယ်ပိုင် database တွင် ထားပေးသော်လည်း မှန်ကန်စွာ configure လုပ်ရန် ပိုများများ ကျန်သည်။ မည်သည်ကို ရွေးသည်ပါစေ၊ password သို့မဟုတ် session logic ကို ကိုယ်တိုင် မရေးဘဲ AI ကို ၎င်းကို သုံးစေပါ။

Role နှင့် ခွင့်ပြုချက်များ

Role	ပုံမှန် ခွင့်ပြုချက်များ
ဧည့်သည်	Public စာမျက်နှာများကို ကြည့်ခြင်း
အဖွဲ့ဝင် / customer	ကိုယ်ပိုင် record များကို ကြည့်ခြင်းနှင့် ပြင်ခြင်း
ဝန်ထမ်း	၎င်းတို့ team သို့မဟုတ် စီးပွားရေးအတွင်း record အားလုံးကို ကြည့်နိုင်သည်၊ settings သို့မဟုတ် billing ကို မပြင်နိုင်
ပိုင်ရှင် / admin	အားလုံး၊ အသုံးပြုသူများနှင့် billing အပါအဝင်

Role အမည်ထက် အရေးကြီးသော စည်းမျဉ်းများ-

Server ပေါ်တွင်၊ အမြဲတမ်း စစ်ပါ။ Page ပေါ်တွင် ခလုတ်ကို ဖျောက်ခြင်းသည် တိုက်ရိုက် API ခေါ်ခြင်းကို မတားပါ။
ပိုင်ရှင်အလိုက် ကန့်သတ်ပါ။ "booking 123" ကို ရယူသော အဖွဲ့ဝင်သည် ၎င်း၏ကိုယ်ပိုင်ဖြစ်မှသာ ရရှိသင့်သည်။
အသုံးပြုသူများက ကိုယ်တိုင် ရာထူးမြှင့်မရပါစေနှင့်။ Profile update တွင် browser မှ ပို့သော role field များကို လျစ်လျူရှုပါ။
Default အနေဖြင့် ဝင်ခွင့် မပေးပါနှင့်။ Route အသစ်များသည် သင် ဆုံးဖြတ်မှ မဟုတ်လျှင် login လိုအပ်စေပါ။

Account နှစ်ခုဖြင့် စမ်းပါ- တစ်ခုဖြင့် ဝင်ပြီး record ID ကို မှတ်ပါ၊ ထို့နောက် အခြားတစ်ခုဖြင့် ဝင်ပြီး ထို record ကို ဖွင့်ကြည့်ပါ။ လုံခြုံရေး checklist တွင် စမ်းသပ်မှု အပြည့်အစုံ ရှိသည်။

Session လုံခြုံရေး

Login ပြီးနောက် app သည် session ဖြင့် အသုံးပြုသူကို မှတ်ထားသည်- များသောအားဖြင့် cookie။ OWASP ၏ session management လမ်းညွှန်ချက်အရ အကြံပြုချက်များ-

Session cookie များကို Secure (HTTPS သာ)၊ HttpOnly (page script မှ ဖတ်မရ) နှင့် SameSite ဖြင့် သတ်မှတ်ပါ
Login တွင် session ID အသစ် ထုတ်ပါ၊ အခွင့်အရေး ပြောင်းသောအခါ ထပ်ထုတ်ပါ
Idle timeout နှင့် အကြီးဆုံး သက်တမ်း၊ server ပေါ်တွင် ကျင့်သုံးပါ
Logout သည် cookie ကို ဖျက်ရုံမက session ကို server ပေါ်တွင် အပြီးသတ်စေပါ
အသုံးပြုသူ password ပြောင်းသောအခါ session များ ပျက်ပါစေ

Login token များကို browser ၏ local storage တွင် သိမ်းခြင်းသည် သင်ခန်းစာများတွင် အများအပြား ဖြစ်သော်လည်း page ပေါ်ရှိ script မည်သည့်အရာမဆို ဝင်ရောက်နိုင်ပြီး၊ web app များအတွက် secure cookie သည် ပုံမှန်အားဖြင့် ပိုကောင်းသော default ဖြစ်သည်။

လိုအပ်ချက်အားလုံး ပါဝင်သော prompt

ဤ app တွင် အသုံးပြုသူ account များ ထည့်ပါ။ အသုံးပြုသူများ email နှင့် password ဖြင့် သို့မဟုတ် Google ဖြင့် sign up လုပ်ပြီး login ဝင်နိုင်စေပါ။ စိတ်ကြိုက် auth code မရေးဘဲ [library or provider] ကို သုံးပါ။ Password များကို Argon2id သို့မဟုတ် bcrypt ဖြင့် hash လုပ်ပါ။ Email ဖြင့် password reset ထည့်ပါ၊ တစ်နာရီအတွင်း သက်တမ်းကုန်သော တစ်ကြိမ်သုံး လင့်ခ်။ Session များကို လုံခြုံသော HttpOnly cookie များတွင် ထားပါ။ /dashboard နှင့် /api route အားလုံးကို logged-in အသုံးပြုသူများသာ သုံးနိုင်အောင် ကာကွယ်ပါ၊ အသုံးပြုသူတစ်ယောက်စီက ကိုယ်ပိုင် project များကိုသာ မြင်စေပါ။ "admin" role ထည့်ပါ၊ အသုံးပြုသူအားလုံးကို မြင်နိုင်စေရန်။ /admin ကို admin များသာ ရောက်နိုင်ပြီး server ပေါ်တွင် စစ်ပါ။

ထို့နောက် စမ်းပါ- sign up၊ log out၊ log in၊ password reset၊ logged-out အခြေအနေတွင် private URL ကို ကြိုးစား၊ အခြားအသုံးပြုသူ၏ record ကို ကြိုးစား။

ကာကွယ်မှုကို page တွင်သာ ထားခြင်း။ Page က logged-out အသုံးပြုသူများကို redirect လုပ်သော်လည်း API က ဒေတာကို မည်သူ့ကိုမဆို ပြန်ပေးသည်။
လျှို့ဝှက်ချက်များ browser တွင်။ OAuth client secret နှင့် auth provider admin key များသည် server ပေါ်တွင်သာ ရှိရမည်။
Preview နှင့် live URL ရောထွေးခြင်း။ Google ၏ redirect URI သို့မဟုတ် reset အီးမေးလ်ရှိ လင့်ခ်သည် preview ကို ညွှန်ပြနေပြီး publish ပြီးနောက် login ပျက်သည်။
အီးမေးလ် အတည်ပြုခြင်း မရှိခြင်း။ မည်သူမဆို anyone@company.com အဖြစ် sign up လုပ်နိုင်သည်။ ထိုအီးမေးလ်နှင့် ချိတ်ဆက်သော မည်သည့်အရာကိုမဆို ပေးခြင်းမပြုမီ အီးမေးလ်ကို အတည်ပြုပါ။
Happy path ကိုသာ စမ်းခြင်း။ Password မှား၊ သက်တမ်းကုန်သော လင့်ခ်နှင့် ဒုတိယ account ကို ကြိုးစားပါ။

Mythex တွင် သင့် app ၏ အသုံးပြုသူများ အတွက် login သည် သင့် app ထဲ ထည့်သော အရာဖြစ်ပြီး သင့်ကိုယ်ပိုင် Mythex account နှင့် သီးခြား ဖြစ်သည်။ Mythex တွင် built-in auth ထုတ်ကုန် မပါဝင်ပါ၊ ထို့ကြောင့် သင်သည် auth library သို့မဟုတ် provider နှင့် ၎င်းတို့၏ key များကို ယူဆောင်ရမည်-

ချဉ်းကပ်ပုံ ရွေးပါ- ဥပမာ email နှင့် password ကို ကိုယ်ပိုင် database တွင် သိမ်းခြင်း သို့မဟုတ် hosted provider ၏ SDK။
အသုံးပြုသူများကို ကိုယ်တိုင် သိမ်းမည်ဆိုလျှင် app ကို database လိုအပ်သည်၊ chat တွင် တောင်းဆိုပါ သို့မဟုတ် /database သုံးပါ။
Provider key များကို project secret များတွင် ထည့်ပါ (/secrets သို့မဟုတ် project settings)။
အထက်ပါ ကဲ့သို့ prompt ကို သုံးပြီး Preview တွင် စမ်းပါ။ Google sign-in အတွက် preview နှင့် published လိပ်စာနှစ်ခုလုံး၏ redirect URI များ ထည့်ပါ။

Docs ရှိ Add login to your app ကို ကြည့်ပါ။ ငွေပေးချေရသော ထုတ်ကုန် တည်ဆောက်နေပါက SaaS MVP တည်ဆောက်နည်း တွင် account များနှင့် billing ကို အတူ ဖော်ပြထားသည်။

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

App အတွက် ထည့်ရလွယ်ဆုံး login ဘာလဲ?

Hosted authentication provider သို့မဟုတ် ကောင်းစွာ ထိန်းသိမ်းထားသော auth library ကို သုံးခြင်းသည် ပုံမှန်အားဖြင့် အလွယ်ဆုံးနှင့် အလုံခြုံဆုံး ဖြစ်သည်၊ session၊ password သိမ်းဆည်းမှုနှင့် reset များကို ကိုင်တွယ်ပြီးသားဖြစ်သောကြောင့်။ Google ဖြင့် sign in သည် Google account ရှိသော အသုံးပြုသူများအတွက် အဟန့်အတားနည်းဆုံး ရွေးချယ်စရာ ဖြစ်သည်။

Magic link သည် password ထက် ပိုလုံခြုံပါသလား?

Password ပြန်သုံးခြင်းနှင့် အားနည်းသော password များကို ဖယ်ရှားပေးသော်လည်း အန္တရာယ်ကို အသုံးပြုသူ၏ အီးမေးလ် account သို့ ရွှေ့သည်။ လင့်ခ်များ လျင်မြန်စွာ သက်တမ်းကုန်ပြီး တစ်ကြိမ်သာ အလုပ်လုပ်သင့်သည်။ သေးငယ်သော app အများစုအတွက် သင့်တော်သော ရွေးချယ်မှု ဖြစ်ပြီး Google sign-in နှင့်အတူ ပေးလေ့ရှိသည်။

Sign in with Google ထည့်ရန် Google ၏ အတည်ပြုချက် လိုအပ်ပါသလား?

အခြေခံ sign-in အချက်အလက် (အမည်၊ အီးမေးလ်နှင့် profile) ကိုသာ တောင်းပါက Google က အတည်ပြုချက် မဖြစ်မနေ မလိုဟု ပြောသော်လည်း consent screen နှင့် OAuth client ကို configure လုပ်ရမည်။ Gmail သို့မဟုတ် Drive ကဲ့သို့ အထိခိုက်မခံသော ဒေတာ ဝင်ရောက်ခွင့် တောင်းပါက Google ၏ app verification လိုအပ်သည်။

Login နှင့် permission ကွာခြားချက် ဘာလဲ?

Login (authentication) က အသုံးပြုသူ ဘယ်သူလဲ အတည်ပြုသည်။ Permission (authorization) က ထိုအသုံးပြုသူ ဘာကြည့်နိုင်သလဲ၊ ဘာလုပ်နိုင်သလဲ ဆုံးဖြတ်သည်။ App တွင် နှစ်ခုလုံး လိုအပ်ပြီး permission ကို request တိုင်းအတွက် server ပေါ်တွင် စစ်ရမည်။