ໂທເຄັນ OIDC (OIDC Token)

OpenID Connect（OIDC）ແມ່ນຂໍ້ກຳນົດທີ່ເພີ່ມຊັ້ນການພິສູດຕົວຕົນ "ຄົນນີ້ແມ່ນໃຜ" ໄວ້ເທິງ OAuth 2.0. OAuth 2.0 ຢ່າງດຽວນັ້ນຈັດການໄດ້ພຽງແຕ່ການອະນຸຍາດ (authorization) ວ່າ "ສາມາດອະນຸຍາດໃຫ້ຜູ້ຖືໂທເຄັນນີ້ເຂົ້າເຖິງຊັບພະຍາກອນໄດ້" ເທົ່ານັ້ນ, ແລະ ບໍ່ມີວິທີມາດຕະຖານສຳລັບຝ່າຍແອັບພລິເຄຊັນໃນການຮູ້ວ່າຜູ້ໃຊ້ທີ່ລ໋ອກອິນເຂົ້າມານັ້ນແມ່ນໃຜ. OIDC ຕື່ມຊ່ອງຫວ່າງດັ່ງກ່າວດ້ວຍໂທເຄັນ 3 ປະເພດ. ### ບົດບາດຂອງໂທເຄັນທັງ 3 **ID ໂທເຄັນ** ແມ່ນຫົວໃຈຫຼັກຂອງ OIDC. ມັນຖືກອອກໃຫ້ໃນຮູບແບບ JWT（JSON Web Token）, ແລະ payload ປະກອບດ້ວຍ claim ຕ່າງໆ ເຊັ່ນ: ຕົວລະບຸຜູ້ໃຊ້ (`sub`), ຜູ້ອອກໂທເຄັນ (`iss`), ວັນໝົດອາຍຸ (`exp`) ແລະ ອື່ນໆ. ການກວດສອບລາຍເຊັນຊ່ວຍໃຫ້ສາມາດຕັດສິນໄດ້ທັນທີວ່າມີການດັດແປງຫຼືບໍ່, ໂດຍບໍ່ຈຳເປັນຕ້ອງສອບຖາມ IdP（Identity Provider）. ຄຸນສົມບັດ "ໃບຢັ້ງຢືນຕົວຕົນທີ່ຄົບຖ້ວນໃນຕົວເອງ" ນີ້ ແມ່ນກຸນແຈສຳຄັນໃນການຫຼຸດຕົ້ນທຶນການພິສູດຕົວຕົນລະຫວ່າງ microservice. **Access ໂທເຄັນ** ມາຈາກ OAuth 2.0, ໃຊ້ສະແດງສິດທິ໌ໃນການເຂົ້າເຖິງ API ຫຼື resource server. ຂອບເຂດສິດທິ໌ຖືກຈຳກັດດ້ວຍ scope (ເຊັ່ນ: `openid profile email`) ແລະ ໂດຍທົ່ວໄປວັນໝົດອາຍຸຈະຖືກຕັ້ງໄວ້ສັ້ນ ປະມານສອງສາມນາທີ ຫາ 1 ຊົ່ວໂມງ. **Refresh ໂທເຄັນ** ໃຊ້ສຳລັບຮັບໂທເຄັນຊຸດໃໝ່ໂດຍບໍ່ຕ້ອງໃຫ້ຜູ້ໃຊ້ລ໋ອກອິນໃໝ່ ເມື່ອ access ໂທເຄັນໝົດອາຍຸ. ເນື່ອງຈາກມີອາຍຸການໃຊ້ງານຍາວນານ, ຄວາມສ່ຽງຕໍ່ການຮົ່ວໄຫຼຈຶ່ງສູງ, ດັ່ງນັ້ນ ການປະຕິບັດທີ່ດີທີ່ສຸດໃນທາງປະຕິບັດຄືການເກັບຮັກສາໄວ້ຝ່າຍ server-side ເທົ່ານັ້ນ ແລະ ເປີດໃຊ້ rotation (ປ່ຽນ refresh ໂທເຄັນໃໝ່ທຸກຄັ້ງທີ່ໃຊ້). ### ພາບລວມຂອງ Flow ໃນ Authorization Code Flow ທົ່ວໄປ, ເມື່ອຜູ້ໃຊ້ລ໋ອກອິນທີ່ IdP, authorization code ຈະຖືກສົ່ງຄືນໃຫ້ client. Client ຈະສົ່ງ code ນີ້ໄປຍັງ token endpoint ຂອງ IdP ແລ້ວຮັບ ID ໂທເຄັນ, access ໂທເຄັນ ແລະ refresh ໂທເຄັນທັງ 3 ຢ່າງພ້ອມກັນ. ເນື່ອງຈາກ authorization code ໃຊ້ໄດ້ພຽງຄັ້ງດຽວ ແລະ ມີໄລຍະເວລາໃຊ້ງານສັ້ນຫຼາຍ, ຈຶ່ງສາມາດຫຼຸດຕົ້ນທຶນຈຳນວນຄັ້ງທີ່ໂທເຄັນຕົວຈິງຖືກສົ່ງຜ່ານເຄືອຂ່າຍໃຫ້ຢູ່ໃນລະດັບຕ່ຳສຸດໄດ້. ### ຂໍ້ຄວນລະວັງໃນການ Implement ສິ່ງທີ່ຜູ້ຂຽນຮູ້ສຶກວ່າມັກຖືກມອງຂ້າມຄືສະຖານທີ່ເກັບຮັກສາໂທເຄັນ. ສຳລັບ SPA（Single Page Application）, ບາງຄັ້ງຈະມີການແນະນຳຮູບແບບການເກັບ access ໂທເຄັນໄວ້ໃນ `localStorage` ຂອງ browser, ແຕ່ວ່ານີ້ສາມາດຖືກລັກໄດ້ງ່າຍດ້ວຍການໂຈມຕີ XSS. ການເກັບໄວ້ໃນ HttpOnly Cookie ດ້ວຍ BFF（Backend for Frontend）pattern ຫຼື ການເກັບໄວ້ໃນ session store ຝ່າຍ server-side ນັ້ນມີຄວາມປອດໄພສູງກວ່າ. ຕ້ອງລະວັງໃນການອອກແບບວັນໝົດອາຍຸຂອງໂທເຄັນດ້ວຍ. ຖ້າ `exp` ຂອງ ID ໂທເຄັນຍາວເກີນໄປ, ການປ່ຽນແປງສິດທິ໌ຂອງຜູ້ໃຊ້ ຫຼື ການລະງັບບັນຊີຈະບໍ່ຖືກສະທ້ອນທັນທີ. ຖ້າຕັ້ງສັ້ນເກີນໄປ, ຄວາມຖີ່ໃນການ refresh ຈະເພີ່ມຂຶ້ນ ແລະ ພາລະຂອງ IdP ກໍ່ຈະເພີ່ມຕາມ. IdP ສ່ວນໃຫຍ່ຕັ້ງຄ່າ default ໄວ້ທີ່ ID ໂທເຄັນ 5〜15 ນາທີ, access ໂທເຄັນ 1 ຊົ່ວໂມງ, refresh ໂທເຄັນ 30〜90 ວັນ, ດັ່ງນັ້ນ ການເລີ່ມຕົ້ນດ້ວຍການປັບຈາກຂອບເຂດນີ້ຈຶ່ງເປັນທາງເລືອກທີ່ໃຊ້ໄດ້ຈິງ.