ໂທເຄັນ 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 ວັນ, ດັ່ງນັ້ນ ການເລີ່ມຕົ້ນດ້ວຍການປັບຈາກຂອບເຂດນີ້ຈຶ່ງເປັນທາງເລືອກທີ່ໃຊ້ໄດ້ຈິງ.