user
backend မှာ JWT token ကို invalidate လုပ်ချင်တယ်။ ဘယ်လိုလုပ်ရင် ကောင်းမလဲ။ Beginners တွေ နားလည်အောင် ပြောပြပေးနိုင်မလား
assistant
JWT နဲ့ မရင်းနှီးတဲ့သူတွေအတွက် အကြမ်းဖျင်းပြောရရင် Jwt ဆိုတာက OAuth token တစ်မျိုးပါပဲ။ token ရဲ့ပိုင်ရှင် ဘယ်သူဖြစ်တယ်၊ token ကို ဘယ်အချိန်က တည်ဆောက်ခဲ့တယ်၊ ဘယ်အချိန်မှာ expire ဖြစ်မယ် စတဲ့ claim တွေပါဝင်တဲ့ payload ကို server ကပဲ သိနိုင်တဲ့ signature နဲ့ ဆက်တယ်။ token ကို ဘယ်သူမဆို decode လို့ရပြီး token ထဲ ဘာတွေပါလဲ ဖွင့်ကြည့်နိုင်တယ်။
JWT ရဲ့ အားသာချက်က federated trust ပါ။ token ထဲမှာ လိုအပ်တဲ့ အချက်အလက်တွေ အကုန်ပါပြီးတဲ့အတွက် backend service တွေအနေနဲ့ တောင်းဆိုလာတဲ့ request ကို လိုက်လျော၊ မလျော ဆုံးဖြတ်ဖို့ token က ကောင်းသေးရဲ့လားလို့ စစ်ဆေးရုံပါပဲ။ ဥပမာ ရုံးထဲဝင်ဖို့ ဝန်ထမ်းကဒ်လိုပေါ့။ တာဝန်ကျ လုံခြုံရေး အနေနဲ့ ဝန်ထမ်းကဒ်ကို ကြည့်ပြီး ပေးဝင်မဝင် ဆုံးဖြတ်နိုင်တယ်။
JWT token ကို invalidate လုပ်လို့ရလားဆိုရင် ရပါတယ်။ ဘယ် user ဒါမှမဟုတ် ဘယ် audience ရဲ့ token ကို invalidate လုပ်လိုက်တယ်ဆိုတဲ့ မှတ်တမ်းကို db ထဲထည့်သိမ်းထားလို့ ရပါတယ်။
ဒီအတွက် redis လို in-memory db ကိုသုံးကြပေမယ့် ခြွင်းချက်တစ်ခုက Auth service ခွဲတွေ အများကြီး ရှိလာတဲ့အခါ consistency ထိနိုင်ပါတယ်။ ဒီပြဿနာကို ဖြေရှင်းဖို့ Lua instruction တိုက်ရိုက်ပေးပြီး အလုပ်လုပ်စေနိုင်ပေမယ့် ဒါကလည်း durable ဖြစ်လှတဲ့ အဖြေတော့ မဟုတ်ဘူး။
လစဥ်ကြေးပေးပြီး သုံးရတဲ့ subscription-oriented platform တွေမှာဆိုရင် ဒီအချက်က အရေးကြီးတဲ့အတွက် disk နဲ့တွဲပြီး eventual consistent model ကို အသုံးပြုသင့်တယ်။ ဥပမာ DynamoDb။

ဒါပေမယ့် JWT token တွေကို invalidate လုပ်တာ လုံးဝ အားမပေးပါဘူး။ အဲ့ဒီအစား JWT မသုံးပဲ နေသင့်ပါတယ်။ ဘာလို့လဲဆိုတော့ JWT ရဲ့သဘာဝက token ဘယ်အချိန်မှာ expire ဖြစ်မလဲလို့ ပါပြီးသား ဖြစ်တဲ့အတွက် server က အဲ့အချိန်အတိုင်ခင် ကြိုပြီး invalidate လုပ်ဖို့ ရှိလာပြီဆိုရင် အနှစ်သာရဖြစ်တဲ့ federated trust ကျိုးပေါက် သွားပါလိမ့်မယ်။
app တခုရဲ့ Identity flow အကြမ်းဖျင်းက ဒီလိုရှိနိုင်တယ်။ token service အနေနဲ့ user credential ကို တိုက်ရိုက် ဒါမှမဟုတ် လိုအပ်ရင် 3rd party (ဥပမာ Facebook, Google) နဲ့ ပြန်စစ်ပြီး user identity ကိုအတည်ပြုမယ်။ မှန်ကန်ရင် Authorizer service ကိုဆက်သွယ်ပြီး token တည်ဆောက်မယ်။ ဒီနေရာမှာ AWS စတိုင်ဆိုရင် Authorizer က faas (lambda function) ပေါ့။
ရလာတဲ့ token က client အတွက် ဝန်ထမ်းကဒ်ပါပဲ။ ဝန်ထမ်းကဒ်ပြပြီး သတ်မှတ်အခန်းတွေကို ဝင်လို့ရပါတယ်။ gateway အနေနဲ့ ပို့လာတဲ့ token မကျိုးပေါက်သရွေ့၊ expire မဖြစ်သေးသရွေ့ request ကိုလိုက်လျောဖို့ တာဝန်ရှိတယ်။
ဒါပေမယ့် token ကို invalidate လုပ်ဖို့ ဆုံးဖြတ်ခဲ့ရင် gateway အနေနဲ့ Token service ဆီ စုံစမ်းရပါတော့မယ်။ အခုတော့ လုံခြုံရေးအရာရှိက ကဒ်ကို ကြည့်ရုံတင်မကဘူး။ ဝန်ထမ်းဌာနကို ဖုန်းဆက်ပြီး ဒီကဒ်က တရားဝင်သေးလားလို့ အကြိမ်တိုင်းမှာ လှမ်းမေးရတော့မှာပါ။
ဒီ overhead ကိုလျှော့ချဖို့အတွက် identity service တွေကို gateway ဆီ ပို့ပစ်ထားသင့်ပါတယ်။ တခါ token ကို ထပ်အတည်ပြုရဦးမှာဖြစ်လို့ token encryption နဲ့ encode/decode အတွက် CPU cycle တွေ မသုံးတော့ပဲ jwt လောက် overhead မများမယ့် token မျိုး သုံးသင့်တယ်။ အရေးကြီးဆုံးအချက်က jwt ကို session လိုမသုံးဖို့ပါပဲ။ ဒါပေမယ့် အခု ပြောသွားသမျှက principle တွေမဟုတ်ပဲ ကျွန်တော့်အမြင်သက်သက်ပဲမို့ လိုအပ်သလို adapt လုပ်သင့်ပါတယ်ခင်ဗျာ။

မှတ်ချက်။   ။ CodeHub with Harry မှ Harry Yan ရဲ့ ၂၀၂၃ သြဂုတ်လမှ ဆောင်းပါးတပုဒ်ဆီက ကောက်နှုတ်ထားပါတယ်