OIDC token ແມ່ນຊື່ເອີ້ນລວມຂອງ ID token, access token, ແລະ refresh token ທີ່ອອກໃຫ້ພາຍໃຕ້ OpenID Connect protocol, ເຊິ່ງເປັນຂໍ້ມູນທີ່ມີລາຍເຊັນສຳລັບການແລກປ່ຽນຂໍ້ມູນການພິສູດຕົວຕົນ (authentication) ແລະການອະນຸຍາດ (authorization) ຂອງຜູ້ໃຊ້ຢ່າງປອດໄພ.
OpenID Connect(OIDC)ແມ່ນຂໍ້ກຳນົດທີ່ເພີ່ມຊັ້ນການພິສູດຕົວຕົນ "ຄົນນີ້ແມ່ນໃຜ" ໄວ້ເທິງ OAuth 2.0. OAuth 2.0 ຢ່າງດຽວນັ້ນຈັດການໄດ້ພຽງແຕ່ການອະນຸຍາດ (authorization) ວ່າ "ສາມາດອະນຸຍາດໃຫ້ຜູ້ຖືໂທເຄັນນີ້ເຂົ້າເຖິງຊັບພະຍາກອນໄດ້" ເທົ່ານັ້ນ, ແລະ ບໍ່ມີວິທີມາດຕະຖານສຳລັບຝ່າຍແອັບພລິເຄຊັນໃນການຮູ້ວ່າຜູ້ໃຊ້ທີ່ລ໋ອກອິນເຂົ້າມານັ້ນແມ່ນໃຜ. OIDC ຕື່ມຊ່ອງຫວ່າງດັ່ງກ່າວດ້ວຍໂທເຄັນ 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 ໂທເຄັນໃໝ່ທຸກຄັ້ງທີ່ໃຊ້).
ໃນ Authorization Code Flow ທົ່ວໄປ, ເມື່ອຜູ້ໃຊ້ລ໋ອກອິນທີ່ IdP, authorization code ຈະຖືກສົ່ງຄືນໃຫ້ client. Client ຈະສົ່ງ code ນີ້ໄປຍັງ token endpoint ຂອງ IdP ແລ້ວຮັບ ID ໂທເຄັນ, access ໂທເຄັນ ແລະ refresh ໂທເຄັນທັງ 3 ຢ່າງພ້ອມກັນ. ເນື່ອງຈາກ authorization code ໃຊ້ໄດ້ພຽງຄັ້ງດຽວ ແລະ ມີໄລຍະເວລາໃຊ້ງານສັ້ນຫຼາຍ, ຈຶ່ງສາມາດຫຼຸດຕົ້ນທຶນຈຳນວນຄັ້ງທີ່ໂທເຄັນຕົວຈິງຖືກສົ່ງຜ່ານເຄືອຂ່າຍໃຫ້ຢູ່ໃນລະດັບຕ່ຳສຸດໄດ້.
ສິ່ງທີ່ຜູ້ຂຽນຮູ້ສຶກວ່າມັກຖືກມອງຂ້າມຄືສະຖານທີ່ເກັບຮັກສາໂທເຄັນ. ສຳລັບ 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 ວັນ, ດັ່ງນັ້ນ ການເລີ່ມຕົ້ນດ້ວຍການປັບຈາກຂອບເຂດນີ້ຈຶ່ງເປັນທາງເລືອກທີ່ໃຊ້ໄດ້ຈິງ.



Token ແມ່ນໜ່ວຍທີ່ນ້ອຍທີ່ສຸດທີ່ LLM ໃຊ້ໃນການປະມວນຜົນຂໍ້ຄວາມ. Token ບໍ່ແມ່ນຄຳສັບທັງໝົດ ແຕ່ໝາຍເຖິງສ່ວນຍ່ອຍຂອງຄຳສັບ, ສັນຍາລັກ, ຫຼືຊ່ອງຫວ່າງກໍໄດ້, ໂດຍເປັນຜົນຈາກການຕັດແບ່ງຂໍ້ຄວາມຕາມ vocabulary ຂອງໂມເດນ.

ສູດການຄິດໄລ່ທີ່ລວມຂໍ້ຄວາມດ້ວຍຮູບແບບທີ່ປາກົດເລື້ອຍໆ ແລະ ແບ່ງອອກເປັນໜ່ວຍ subword. ມັນສົ່ງຜົນໂດຍກົງຕໍ່ຕົ້ນທຶນການນຳເຂົ້າ-ສົ່ງອອກ ແລະ ຄວາມໄວໃນການປະມວນຜົນຂອງ LLM, ແລະ ສຳລັບພາສາທີ່ມີຊັບພະຍາກອນໜ້ອຍ, ການຂາດແຄນຄຳສັບສະເພາະໃນ vocabulary ຈະເຮັດໃຫ້ເກີດການແຍກລະດັບ byte.

ວິທີການອອກແບບທີ່ກຳຈັດຄວາມສ່ຽງຂອງການຮົ່ວໄຫຼຂໍ້ມູນສ່ວນຕົວຢ່າງເປັນໂຄງສ້າງ ໂດຍການແຍກລະບົບ AI ແລະໂຄງສ້າງພື້ນຖານການປະມວນຜົນຂໍ້ມູນອອກຈາກກັນທາງດ້ານກາຍຍະພາບ ແລະທາງດ້ານຕາມເຫດຜົນ (Logical). ຕົວຢ່າງທີ່ເປັນຕົວແທນຂອງວິທີນີ້ ໄດ້ແກ່ການແຍກ Tenant ແລະການດຳເນີນງານແບບ On-premises.

ກົນໄກຄວາມປອດໄພທີ່ກວດສອບການນຳເຂົ້າແລະຜົນອອກຂອງ LLM ເພື່ອກວດຈັບແລະສະກັດກັ້ນເນື້ອຫາທີ່ເປັນອັນຕະລາຍ, ການຮົ່ວໄຫລຂອງຂໍ້ມູນລັບ, ແລະການລະເມີດນະໂຍບາຍໂດຍອັດຕະໂນມັດ.

PoC (Proof of Concept, ການພິສູດແນວຄິດ) ແມ່ນຂະບວນການກວດສອບຄວາມເປັນໄປໄດ້ຂອງເຕັກໂນໂລຊີ ຫຼື ແນວຄິດໃໝ່ໃນຂະໜາດນ້ອຍ. ມັນຖືກດຳເນີນການເພື່ອເຮັດໃຫ້ຄວາມສ່ຽງເປັນທີ່ເຫັນໄດ້ຊັດເຈນກ່ອນທີ່ຈະລົງທຶນໃນການພັດທະນາຢ່າງເຕັມຮູບແບບ ແລະ ເພື່ອຕັດສິນວ່າ "ວິທີການນີ້ສາມາດບັນລຸເປົ້າໝາຍໄດ້ຫຼືບໍ່".