OpenID Connect: ການອະນຸຍາດຂອງແອັບພລິເຄຊັນພາຍໃນຈາກແບບກຳນົດເອງໄປສູ່ມາດຕະຖານ

ສອງສາມເດືອນກ່ອນຫນ້ານີ້, ຂ້ອຍກໍາລັງປະຕິບັດເຄື່ອງແມ່ຂ່າຍ OpenID Connect ເພື່ອຈັດການການເຂົ້າເຖິງຫຼາຍຮ້ອຍຄໍາຮ້ອງສະຫມັກພາຍໃນຂອງພວກເຮົາ. ຈາກການພັດທະນາຂອງພວກເຮົາເອງ, ສະດວກໃນຂະຫນາດຂະຫນາດນ້ອຍ, ພວກເຮົາໄດ້ຍ້າຍໄປສູ່ມາດຕະຖານທີ່ຍອມຮັບໂດຍທົ່ວໄປ. ການເຂົ້າເຖິງໂດຍຜ່ານການບໍລິການສູນກາງຢ່າງຫຼວງຫຼາຍເຮັດໃຫ້ການດໍາເນີນງານ monotonous ງ່າຍດາຍ, ຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍໃນການປະຕິບັດການອະນຸຍາດ, ອະນຸຍາດໃຫ້ທ່ານຊອກຫາວິທີແກ້ໄຂພ້ອມທີ່ຈະເຮັດຫຼາຍແລະບໍ່ rack ສະຫມອງຂອງທ່ານໃນເວລາທີ່ການພັດທະນາໃຫມ່. ໃນ​ບົດ​ຄວາມ​ນີ້, ຂ້າ​ພະ​ເຈົ້າ​ຈະ​ເວົ້າ​ເຖິງ​ການ​ຫັນ​ປ່ຽນ​ນີ້​ແລະ​ຕໍາ​ແຫນ່ງ​ທີ່​ພວກ​ເຮົາ​ໄດ້​ຈັດ​ການ​ເພື່ອ​ຕື່ມ​ຂໍ້​ມູນ​ໃສ່.

ດົນ​ນານ​ມາ​ແລ້ວ... ມັນ​ເລີ່ມ​ຕົ້ນ​ແນວ​ໃດ

ສອງສາມປີກ່ອນ, ເມື່ອມີຄໍາຮ້ອງສະຫມັກພາຍໃນຫຼາຍເກີນໄປສໍາລັບການຄວບຄຸມຄູ່ມື, ພວກເຮົາໄດ້ຂຽນຄໍາຮ້ອງສະຫມັກເພື່ອຄວບຄຸມການເຂົ້າເຖິງພາຍໃນບໍລິສັດ. ມັນເປັນຄໍາຮ້ອງສະຫມັກ Rails ງ່າຍດາຍທີ່ເຊື່ອມຕໍ່ກັບຖານຂໍ້ມູນທີ່ມີຂໍ້ມູນກ່ຽວກັບພະນັກງານ, ບ່ອນທີ່ການເຂົ້າເຖິງການເຮັດວຽກຕ່າງໆໄດ້ຖືກຕັ້ງຄ່າ. ໃນຂະນະດຽວກັນ, ພວກເຮົາໄດ້ຍົກ SSO ທໍາອິດ, ເຊິ່ງອີງໃສ່ການກວດສອບ tokens ຈາກຂ້າງລູກຄ້າແລະເຄື່ອງແມ່ຂ່າຍການອະນຸຍາດ, token ໄດ້ຖືກຖ່າຍທອດໃນຮູບແບບທີ່ຖືກເຂົ້າລະຫັດດ້ວຍຕົວກໍານົດການຫຼາຍແລະກວດສອບໃນເຄື່ອງແມ່ຂ່າຍການອະນຸຍາດ. ນີ້ບໍ່ແມ່ນທາງເລືອກທີ່ສະດວກທີ່ສຸດ, ນັບຕັ້ງແຕ່ແຕ່ລະຄໍາຮ້ອງສະຫມັກພາຍໃນຕ້ອງອະທິບາຍຊັ້ນຂອງເຫດຜົນຢ່າງຫຼວງຫຼາຍ, ແລະຖານຂໍ້ມູນຂອງພະນັກງານໄດ້ຖືກ synchronized ຢ່າງສົມບູນກັບເຄື່ອງແມ່ຂ່າຍການອະນຸຍາດ.

ຫຼັງຈາກເວລາໃດຫນຶ່ງ, ພວກເຮົາໄດ້ຕັດສິນໃຈເຮັດໃຫ້ວຽກງານຂອງການອະນຸຍາດສູນກາງງ່າຍຂຶ້ນ. SSO ຖືກໂອນໄປຫາຜູ້ດຸ່ນດ່ຽງ. ດ້ວຍການຊ່ວຍເຫຼືອຂອງ OpenResty, ແມ່ແບບໄດ້ຖືກເພີ່ມໃສ່ Lua ທີ່ກວດເບິ່ງ tokens, ຮູ້ວ່າແອັບພລິເຄຊັນໃດທີ່ຮ້ອງຂໍໄປ, ແລະສາມາດກວດເບິ່ງວ່າມີການເຂົ້າເຖິງບ່ອນນັ້ນຫຼືບໍ່. ວິທີການນີ້ເຮັດໃຫ້ວຽກງານຄວບຄຸມການເຂົ້າເຖິງຄໍາຮ້ອງສະຫມັກພາຍໃນງ່າຍດາຍຫຼາຍ - ໃນລະຫັດຂອງແຕ່ລະແອັບພລິເຄຊັນ, ມັນບໍ່ຈໍາເປັນຕ້ອງອະທິບາຍເຫດຜົນເພີ່ມເຕີມ. ດັ່ງນັ້ນ, ພວກເຮົາປິດການຈະລາຈອນພາຍນອກ, ແລະແອັບພລິເຄຊັນເອງກໍ່ບໍ່ຮູ້ຫຍັງກ່ຽວກັບການອະນຸຍາດ.

ຢ່າງໃດກໍຕາມ, ບັນຫາຫນຶ່ງຍັງບໍ່ໄດ້ຮັບການແກ້ໄຂ. ຈະເປັນແນວໃດກ່ຽວກັບຄໍາຮ້ອງສະຫມັກທີ່ຕ້ອງການຂໍ້ມູນກ່ຽວກັບພະນັກງານ? ມັນເປັນໄປໄດ້ທີ່ຈະຂຽນ API ສໍາລັບການບໍລິການການອະນຸຍາດ, ແຕ່ຫຼັງຈາກນັ້ນທ່ານຈະຕ້ອງເພີ່ມເຫດຜົນເພີ່ມເຕີມສໍາລັບແຕ່ລະຄໍາຮ້ອງສະຫມັກດັ່ງກ່າວ. ນອກຈາກນັ້ນ, ພວກເຮົາຕ້ອງການກໍາຈັດການເພິ່ງພາອາໄສຫນຶ່ງໃນຄໍາຮ້ອງສະຫມັກທີ່ຂຽນດ້ວຍຕົນເອງ, ເຊິ່ງຕໍ່ມາຈະຖືກແປເປັນ OpenSource, ໃນເຄື່ອງແມ່ຂ່າຍການອະນຸຍາດພາຍໃນຂອງພວກເຮົາ. ພວກເຮົາຈະເວົ້າກ່ຽວກັບມັນບາງເວລາ. ການແກ້ໄຂທັງສອງບັນຫາແມ່ນ OAuth.

ກັບມາດຕະຖານທົ່ວໄປ

OAuth ແມ່ນມາດຕະຖານການອະນຸຍາດທີ່ເຂົ້າໃຈໄດ້, ຍອມຮັບໂດຍທົ່ວໄປ, ແຕ່ເນື່ອງຈາກພຽງແຕ່ການທໍາງານຂອງມັນບໍ່ພຽງພໍ, ເຂົາເຈົ້າຈຶ່ງເລີ່ມພິຈາລະນາ OpenID Connect (ODC). ODC ຕົວຂອງມັນເອງແມ່ນການປະຕິບັດທີສາມຂອງມາດຕະຖານການພິສູດຢືນຢັນແບບເປີດ, ເຊິ່ງໄດ້ເຂົ້າໄປໃນສ່ວນເສີມຜ່ານໂປຣໂຕຄໍ OAuth 2.0 (ໂປໂຕຄອນການອະນຸຍາດແບບເປີດ). ການແກ້ໄຂນີ້ປິດບັນຫາຂອງການຂາດຂໍ້ມູນກ່ຽວກັບຜູ້ໃຊ້ສຸດທ້າຍ, ແລະຍັງເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະປ່ຽນຜູ້ໃຫ້ບໍລິການການອະນຸຍາດ.

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

ວິທີການຂອງພວກເຮົາໃນການປະຕິບັດເຄື່ອງແມ່ຂ່າຍ ODC ຂອງພວກເຮົາເອງ

1) ໄດ້ນໍາເອົາຂໍ້ມູນເຂົ້າໄປໃນແບບຟອມທີ່ຕ້ອງການ

ເພື່ອປະສົມປະສານ ODDC, ມັນຈໍາເປັນຕ້ອງນໍາເອົາຂໍ້ມູນຜູ້ໃຊ້ໃນປະຈຸບັນເຂົ້າໄປໃນຮູບແບບທີ່ເຂົ້າໃຈໄດ້ໂດຍມາດຕະຖານ. ໃນ OIDC ນີ້ເອີ້ນວ່າການຮຽກຮ້ອງ. ການຮຽກຮ້ອງແມ່ນຂົງເຂດສຸດທ້າຍໃນຖານຂໍ້ມູນຜູ້ໃຊ້ (ຊື່, ອີເມວ, ໂທລະສັບ, ແລະອື່ນໆ). ມີຢູ່ ບັນຊີລາຍຊື່ມາດຕະຖານຂອງສະແຕມ, ແລະທຸກສິ່ງທຸກຢ່າງທີ່ບໍ່ໄດ້ລວມຢູ່ໃນບັນຊີລາຍຊື່ນີ້ແມ່ນຖືວ່າເປັນປະເພນີ. ດັ່ງນັ້ນ, ຈຸດທໍາອິດທີ່ທ່ານຈໍາເປັນຕ້ອງເອົາໃຈໃສ່ຖ້າທ່ານຕ້ອງການເລືອກຜູ້ໃຫ້ບໍລິການ ODC ທີ່ມີຢູ່ແລ້ວແມ່ນຄວາມເປັນໄປໄດ້ຂອງການປັບແຕ່ງຍີ່ຫໍ້ໃຫມ່ທີ່ສະດວກສະບາຍ.

ກຸ່ມຂອງເຄື່ອງຫມາຍຖືກລວມເຂົ້າເປັນຊຸດຍ່ອຍຕໍ່ໄປນີ້ - ຂອບເຂດ. ໃນລະຫວ່າງການອະນຸຍາດ, ການເຂົ້າເຖິງແມ່ນຮ້ອງຂໍບໍ່ໃຫ້ຍີ່ຫໍ້ສະເພາະ, ແຕ່ຂອບເຂດ, ເຖິງແມ່ນວ່າບາງຍີ່ຫໍ້ຈາກຂອບເຂດແມ່ນບໍ່ຈໍາເປັນ.

2) ປະຕິບັດການຊ່ວຍເຫລືອທີ່ຈໍາເປັນ

ສ່ວນຕໍ່ໄປຂອງການເຊື່ອມໂຍງ ODC ແມ່ນການຄັດເລືອກແລະການປະຕິບັດປະເພດການອະນຸຍາດ, ອັນທີ່ເອີ້ນວ່າການຊ່ວຍເຫຼືອລ້າ. ສະຖານະການເພີ່ມເຕີມຂອງການໂຕ້ຕອບລະຫວ່າງຄໍາຮ້ອງສະຫມັກທີ່ເລືອກແລະເຄື່ອງແມ່ຂ່າຍການອະນຸຍາດຈະຂຶ້ນກັບການຊ່ວຍເຫຼືອທີ່ເລືອກ. ໂຄງການທີ່ເປັນຕົວຢ່າງສໍາລັບການເລືອກທຶນທີ່ເຫມາະສົມແມ່ນສະແດງຢູ່ໃນຮູບຂ້າງລຸ່ມນີ້.

ສໍາລັບຄໍາຮ້ອງສະຫມັກຄັ້ງທໍາອິດຂອງພວກເຮົາ, ພວກເຮົາໄດ້ນໍາໃຊ້ການຊ່ວຍເຫຼືອລ້າທົ່ວໄປທີ່ສຸດ, ລະຫັດການອະນຸຍາດ. ຄວາມແຕກຕ່າງຂອງມັນຈາກຄົນອື່ນແມ່ນວ່າມັນເປັນສາມຂັ້ນຕອນ, i.e. ກໍາລັງດໍາເນີນການທົດສອບເພີ່ມເຕີມ. ຫນ້າທໍາອິດ, ຜູ້ໃຊ້ເຮັດການຮ້ອງຂໍການອະນຸຍາດ, ໄດ້ຮັບ token - ລະຫັດການອະນຸຍາດ, ຫຼັງຈາກນັ້ນກັບ token ນີ້, ຄືກັບວ່າມີປີ້ສໍາລັບການເດີນທາງ, ຮ້ອງຂໍໃຫ້ມີ token ການເຂົ້າເຖິງ. ການໂຕ້ຕອບຕົ້ນຕໍຂອງສະຄິບການອະນຸຍາດນີ້ແມ່ນອີງໃສ່ການປ່ຽນເສັ້ນທາງລະຫວ່າງແອັບພລິເຄຊັນແລະເຄື່ອງແມ່ຂ່າຍການອະນຸຍາດ. ທ່ານສາມາດອ່ານເພີ່ມເຕີມກ່ຽວກັບການຊ່ວຍເຫຼືອລ້ານີ້ ທີ່ນີ້.

OAuth ປະຕິບັດຕາມແນວຄວາມຄິດທີ່ໂທເຄັນການເຂົ້າເຖິງທີ່ໄດ້ຮັບຫຼັງຈາກການອະນຸຍາດຄວນຈະເປັນການຊົ່ວຄາວ ແລະຄວນຈະມີການປ່ຽນແປງ, ໂດຍສະເລ່ຍທຸກໆ 10 ນາທີ. ການໃຫ້ລະຫັດການອະນຸຍາດແມ່ນການກວດສອບສາມຂັ້ນຕອນໂດຍຜ່ານການປ່ຽນເສັ້ນທາງ, ທຸກໆ 10 ນາທີເພື່ອຫັນຂັ້ນຕອນດັ່ງກ່າວ, ກົງໄປກົງມາ, ບໍ່ແມ່ນວຽກທີ່ຫນ້າພໍໃຈທີ່ສຸດສໍາລັບຕາ. ເພື່ອແກ້ໄຂບັນຫານີ້, ມີການຊ່ວຍເຫຼືອລ້າອີກ - Refresh Token, ເຊິ່ງພວກເຮົາຍັງໃຊ້ໃນປະເທດຂອງພວກເຮົາ. ທຸກສິ່ງທຸກຢ່າງແມ່ນງ່າຍຂຶ້ນຢູ່ທີ່ນີ້. ໃນລະຫວ່າງການຢັ້ງຢືນຈາກການຊ່ວຍເຫຼືອລ້າອື່ນ, ນອກເຫນືອຈາກ token ການເຂົ້າເຖິງຕົ້ນຕໍ, ອີກອັນຫນຶ່ງແມ່ນອອກ - Refresh Token, ເຊິ່ງສາມາດໃຊ້ໄດ້ພຽງແຕ່ຄັ້ງດຽວແລະຕະຫຼອດຊີວິດຂອງມັນແມ່ນປົກກະຕິຫຼາຍຕໍ່ໄປອີກແລ້ວ. ດ້ວຍ Refresh Token ນີ້, ເມື່ອ TTL (Time to Live) ຂອງໂທເຄັນການເຂົ້າເຖິງຫຼັກສິ້ນສຸດລົງ, ການຮ້ອງຂໍໃຫ້ໂທເຄັນການເຂົ້າເຖິງໃໝ່ຈະມາຮອດຈຸດສິ້ນສຸດຂອງການຊ່ວຍເຫຼືອອື່ນ. Token Refresh ທີ່ນຳໃຊ້ແລ້ວຈະຖືກຣີເຊັດເປັນສູນໃນທັນທີ. ການກວດສອບນີ້ແມ່ນສອງຂັ້ນຕອນແລະສາມາດປະຕິບັດໄດ້ໃນພື້ນຫລັງ, imperceptibly ກັບຜູ້ໃຊ້.

3) ຕັ້ງຄ່າຮູບແບບຜົນຜະລິດຂໍ້ມູນແບບກຳນົດເອງ

ຫຼັງຈາກການຊ່ວຍເຫຼືອລ້າທີ່ເລືອກໄດ້ຖືກປະຕິບັດ, ການອະນຸຍາດເຮັດວຽກ, ມັນເປັນມູນຄ່າການກ່າວເຖິງການໄດ້ຮັບຂໍ້ມູນກ່ຽວກັບຜູ້ໃຊ້ສຸດທ້າຍ. ODC ມີຈຸດສິ້ນສຸດແຍກຕ່າງຫາກສໍາລັບການນີ້, ບ່ອນທີ່ທ່ານສາມາດຮ້ອງຂໍຂໍ້ມູນຜູ້ໃຊ້ກັບ token ການເຂົ້າເຖິງປະຈຸບັນຂອງທ່ານແລະຖ້າຫາກວ່າມັນເຖິງວັນທີ. ແລະຖ້າຂໍ້ມູນຂອງຜູ້ໃຊ້ບໍ່ປ່ຽນແປງເລື້ອຍໆ, ແລະທ່ານຈໍາເປັນຕ້ອງຕິດຕາມຂໍ້ມູນໃນປະຈຸບັນຫຼາຍຄັ້ງ, ທ່ານສາມາດເຂົ້າມາໃນການແກ້ໄຂເຊັ່ນ JWT tokens. tokens ເຫຼົ່ານີ້ຍັງໄດ້ຮັບການສະຫນັບສະຫນູນໂດຍມາດຕະຖານ. JWT token ຕົວຂອງມັນເອງປະກອບດ້ວຍສາມສ່ວນ: header (ຂໍ້ມູນກ່ຽວກັບ token), payload (ຂໍ້ມູນທີ່ຈໍາເປັນໃດໆ) ແລະລາຍເຊັນ (ລາຍເຊັນ, token ແມ່ນເຊັນໂດຍເຄື່ອງແມ່ຂ່າຍແລະຕໍ່ມາທ່ານສາມາດກວດເບິ່ງແຫຼ່ງຂອງລາຍເຊັນຂອງມັນ).

ໃນການຈັດຕັ້ງປະຕິບັດ ODC, JWT token ເອີ້ນວ່າ id_token. ມັນສາມາດໄດ້ຮັບການຮ້ອງຂໍພ້ອມກັບ token ການເຂົ້າເຖິງປົກກະຕິແລະທັງຫມົດທີ່ເຫຼືອແມ່ນການກວດສອບລາຍເຊັນ. ເຊີບເວີການອະນຸຍາດມີຈຸດສິ້ນສຸດແຍກຕ່າງຫາກສໍາລັບການນີ້ດ້ວຍກະແຈສາທາລະນະຫຼາຍຮູບແບບ J.W.K.. ແລະການເວົ້າເລື່ອງນີ້, ມັນເປັນມູນຄ່າທີ່ກ່າວເຖິງວ່າມີຈຸດສຸດທ້າຍອີກ, ເຊິ່ງອີງໃສ່ມາດຕະຖານ RFC5785 ສະທ້ອນເຖິງການຕັ້ງຄ່າປັດຈຸບັນຂອງເຊີບເວີ ODC. ມັນມີທີ່ຢູ່ປາຍທາງທັງໝົດ (ຮວມທັງທີ່ຢູ່ຂອງກະແຈສາທາລະນະທີ່ໃຊ້ສຳລັບການເຊັນ), ຍີ່ຫໍ້ ແລະຂອບເຂດທີ່ຮອງຮັບ, ຂັ້ນຕອນການເຂົ້າລະຫັດທີ່ໃຊ້ແລ້ວ, ການຊ່ວຍເຫຼືອລ້າ, ແລະອື່ນໆ.

ຕົວຢ່າງໃນ Google:

{
 "issuer": "https://accounts.google.com",
 "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
 "device_authorization_endpoint": "https://oauth2.googleapis.com/device/code",
 "token_endpoint": "https://oauth2.googleapis.com/token",
 "userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
 "revocation_endpoint": "https://oauth2.googleapis.com/revoke",
 "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
 "response_types_supported": [
  "code",
  "token",
  "id_token",
  "code token",
  "code id_token",
  "token id_token",
  "code token id_token",
  "none"
 ],
 "subject_types_supported": [
  "public"
 ],
 "id_token_signing_alg_values_supported": [
  "RS256"
 ],
 "scopes_supported": [
  "openid",
  "email",
  "profile"
 ],
 "token_endpoint_auth_methods_supported": [
  "client_secret_post",
  "client_secret_basic"
 ],
 "claims_supported": [
  "aud",
  "email",
  "email_verified",
  "exp",
  "family_name",
  "given_name",
  "iat",
  "iss",
  "locale",
  "name",
  "picture",
  "sub"
 ],
 "code_challenge_methods_supported": [
  "plain",
  "S256"
 ],
 "grant_types_supported": [
  "authorization_code",
  "refresh_token",
  "urn:ietf:params:oauth:grant-type:device_code",
  "urn:ietf:params:oauth:grant-type:jwt-bearer"
 ]
}

ດັ່ງນັ້ນ, ການນໍາໃຊ້ id_token, ທ່ານສາມາດໂອນເຄື່ອງຫມາຍທີ່ຈໍາເປັນທັງຫມົດໃຫ້ກັບ payload ຂອງ token ແລະບໍ່ຕິດຕໍ່ກັບເຄື່ອງແມ່ຂ່າຍການອະນຸຍາດໃນແຕ່ລະຄັ້ງເພື່ອຮ້ອງຂໍຂໍ້ມູນຜູ້ໃຊ້. ຂໍ້ເສຍຂອງວິທີການນີ້ແມ່ນວ່າການປ່ຽນແປງຂໍ້ມູນຜູ້ໃຊ້ຈາກເຄື່ອງແມ່ຂ່າຍບໍ່ໄດ້ມາທັນທີ, ແຕ່ພ້ອມກັບ token ການເຂົ້າເຖິງໃຫມ່.

ຜົນການຈັດຕັ້ງປະຕິບັດ

ດັ່ງນັ້ນ, ຫຼັງຈາກການປະຕິບັດເຄື່ອງແມ່ຂ່າຍ ODC ຂອງພວກເຮົາເອງແລະການຕັ້ງຄ່າການເຊື່ອມຕໍ່ກັບມັນໃນດ້ານຄໍາຮ້ອງສະຫມັກ, ພວກເຮົາໄດ້ແກ້ໄຂບັນຫາການໂອນຂໍ້ມູນກ່ຽວກັບຜູ້ໃຊ້.
ເນື່ອງຈາກ OIDC ເປັນມາດຕະຖານເປີດ, ພວກເຮົາມີທາງເລືອກທີ່ຈະເລືອກເອົາຜູ້ໃຫ້ບໍລິການທີ່ມີຢູ່ແລ້ວຫຼືການປະຕິບັດເຄື່ອງແມ່ຂ່າຍ. ພວກເຮົາໄດ້ພະຍາຍາມ Keycloak, ເຊິ່ງໄດ້ກາຍເປັນສະດວກຫຼາຍໃນການຕັ້ງຄ່າ, ຫຼັງຈາກການຕັ້ງຄ່າແລະປ່ຽນການຕັ້ງຄ່າການເຊື່ອມຕໍ່ໃນດ້ານຂອງແອັບພລິເຄຊັນ, ມັນພ້ອມທີ່ຈະໄປ. ໃນດ້ານຄໍາຮ້ອງສະຫມັກ, ທັງຫມົດທີ່ຍັງເຫຼືອແມ່ນການປ່ຽນແປງການຕັ້ງຄ່າການເຊື່ອມຕໍ່.

ເວົ້າກ່ຽວກັບການແກ້ໄຂທີ່ມີຢູ່ແລ້ວ

ພາຍໃນອົງການຂອງພວກເຮົາ, ເປັນເຄື່ອງແມ່ຂ່າຍຂອງ ODC ທໍາອິດ, ພວກເຮົາປະກອບການຈັດຕັ້ງປະຕິບັດຂອງພວກເຮົາເອງ, ເຊິ່ງໄດ້ຖືກເສີມຕາມຄວາມຈໍາເປັນ. ຫຼັງຈາກການທົບທວນຄືນຢ່າງລະອຽດຂອງວິທີແກ້ໄຂທີ່ກຽມພ້ອມອື່ນໆ, ພວກເຮົາສາມາດເວົ້າໄດ້ວ່ານີ້ແມ່ນຈຸດທີ່ຫນ້າພໍໃຈ. ໃນຄວາມໂປດປານຂອງການຕັດສິນໃຈທີ່ຈະປະຕິບັດເຄື່ອງແມ່ຂ່າຍຂອງຕົນເອງ, ມີຄວາມກັງວົນຢູ່ໃນພາກສ່ວນຂອງຜູ້ໃຫ້ບໍລິການໃນການຂາດການເຮັດວຽກທີ່ຈໍາເປັນ, ເຊັ່ນດຽວກັນກັບການປະກົດຕົວຂອງລະບົບເກົ່າທີ່ມີການອະນຸຍາດທີ່ແຕກຕ່າງກັນສໍາລັບບາງບໍລິການແລະຂ້ອນຂ້າງຫຼາຍ. ຂໍ້ມູນຂອງພະນັກງານໄດ້ຖືກເກັບໄວ້ແລ້ວ. ຢ່າງໃດກໍ່ຕາມ, ໃນການປະຕິບັດທີ່ກຽມພ້ອມ, ມີຄວາມສະດວກໃນການເຊື່ອມໂຍງ. ຕົວຢ່າງ, Keycloak ມີລະບົບການຄຸ້ມຄອງຜູ້ໃຊ້ຂອງຕົນເອງແລະຂໍ້ມູນຖືກເກັບໄວ້ໂດຍກົງໃນມັນ, ແລະມັນຈະບໍ່ຍາກທີ່ຈະ overtake ຜູ້ໃຊ້ຂອງທ່ານຢູ່ທີ່ນັ້ນ. ເພື່ອເຮັດສິ່ງນີ້, Keycloak ມີ API ທີ່ຈະຊ່ວຍໃຫ້ທ່ານສາມາດປະຕິບັດການໂອນຍ້າຍທີ່ຈໍາເປັນທັງຫມົດ.

ຕົວຢ່າງອີກອັນຫນຶ່ງຂອງການຮັບຮອງ, ຫນ້າສົນໃຈ, ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ, ການປະຕິບັດແມ່ນ Ory Hydra. ມັນຫນ້າສົນໃຈເນື່ອງຈາກວ່າມັນປະກອບດ້ວຍອົງປະກອບທີ່ແຕກຕ່າງກັນ. ເພື່ອປະສົມປະສານ, ທ່ານຈະຕ້ອງເຊື່ອມຕໍ່ການບໍລິການຄຸ້ມຄອງຜູ້ໃຊ້ຂອງທ່ານກັບການບໍລິການການອະນຸຍາດຂອງພວກເຂົາແລະຂະຫຍາຍຕາມຄວາມຕ້ອງການ.

Keycloak ແລະ Ory Hydra ບໍ່ແມ່ນການແກ້ໄຂນອກຊັ້ນວາງເທົ່ານັ້ນ. ມັນເປັນສິ່ງທີ່ດີທີ່ສຸດທີ່ຈະເລືອກເອົາການປະຕິບັດທີ່ໄດ້ຮັບການຮັບຮອງໂດຍ OpenID Foundation. ວິທີແກ້ໄຂເຫຼົ່ານີ້ປົກກະຕິແລ້ວມີປ້າຍການຢັ້ງຢືນ OpenID.

ນອກຈາກນັ້ນ, ຢ່າລືມກ່ຽວກັບຜູ້ໃຫ້ບໍລິການຈ່າຍທີ່ມີຢູ່ຖ້າທ່ານບໍ່ຕ້ອງການຮັກສາເຄື່ອງແມ່ຂ່າຍ ODC ຂອງທ່ານ. ມື້ນີ້ມີຫຼາຍທາງເລືອກທີ່ດີ.

ມີຫຍັງຕໍ່ໄປ

ໃນອະນາຄົດອັນໃກ້ນີ້, ພວກເຮົາຈະປິດການຈະລາຈອນກັບການບໍລິການພາຍໃນດ້ວຍວິທີທີ່ແຕກຕ່າງກັນ. ພວກເຮົາວາງແຜນທີ່ຈະໂອນ SSO ໃນປັດຈຸບັນຂອງພວກເຮົາຢູ່ໃນຕົວດຸ່ນດ່ຽງໂດຍໃຊ້ OpenResty ໄປຫາຕົວແທນໂດຍອີງໃສ່ OAuth. ມີຫຼາຍວິທີແກ້ໄຂທີ່ກຽມພ້ອມແລ້ວຢູ່ທີ່ນີ້, ຕົວຢ່າງ:
github.com/bitly/oauth2_proxy
github.com/ory/oathkeeper
github.com/keycloak/keycloak-gatekeeper

ອຸປະກອນເພີ່ມເຕີມ

jwt.io - ການບໍລິການທີ່ດີສໍາລັບການກວດສອບ JWT tokens
openid.net/developers/certified - ບັນ​ຊີ​ລາຍ​ຊື່​ຂອງ​ການ​ປະ​ຕິ​ບັດ OIDC ຮັບ​ຮອງ​

ແຫຼ່ງຂໍ້ມູນ: www.habr.com