ຄູ່ມືຮູບແຕ້ມເພື່ອ OAuth ແລະ OpenID Connect

ຫມາຍ​ເຫດ​. ແປ.: ຂໍ້ຄວາມທີ່ດີນີ້ຈາກ Okta ອະທິບາຍວິທີການ OAuth ແລະ OIDC (OpenID Connect) ເຮັດວຽກແບບງ່າຍດາຍ ແລະຊັດເຈນ. ຄວາມຮູ້ນີ້ຈະເປັນປະໂຫຍດຕໍ່ນັກພັດທະນາ, ຜູ້ບໍລິຫານລະບົບ, ແລະແມ່ນແຕ່ "ຜູ້ໃຊ້ປົກກະຕິ" ຂອງແອັບພລິເຄຊັນເວັບທີ່ນິຍົມ, ຜູ້ທີ່ມັກຈະແລກປ່ຽນຂໍ້ມູນລັບກັບບໍລິການອື່ນໆ.

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

"ກະລຸນາໃຫ້ບັນຊີທະນາຄານຂອງເຈົ້າ." "ພວກເຮົາສັນຍາວ່າທຸກສິ່ງທຸກຢ່າງຈະດີກັບລະຫັດຜ່ານແລະເງິນ. ມັນຊື່ສັດແທ້ໆ!” *ເຮີ້ຍ*

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

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

ໂດຍວິທີທາງການ, ຄູ່ມືນີ້ຍັງມີຢູ່ໃນຮູບແບບວິດີໂອ:

ທ່ານຍິງ ແລະທ່ານຊາຍ, ຍິນດີຕ້ອນຮັບ: OAuth 2.0

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

ຕົວຢ່າງ, ໃຫ້ເວົ້າວ່າເຈົ້າພົບເວັບໄຊທີ່ເອີ້ນວ່າ "Bad Pun of the Day" [Pun ຂີ້ຮ້າຍຂອງມື້] ແລະຕັດສິນໃຈລົງທະບຽນສໍາລັບມັນເພື່ອຮັບ puns ປະຈໍາວັນຜ່ານຂໍ້ຄວາມໄປຫາໂທລະສັບຂອງທ່ານ. ເຈົ້າມັກເວັບໄຊດັ່ງກ່າວແທ້ໆ ແລະຕັດສິນໃຈແບ່ງປັນມັນກັບທຸກຄົນທີ່ທ່ານຮູ້ຈັກ. ຫຼັງຈາກທີ່ທັງຫມົດ, ທຸກຄົນມັກ puns ຂີ້ຮ້າຍ, ແມ່ນບໍ?

“ຄຳເວົ້າທີ່ບໍ່ດີຂອງມື້: ເຈົ້າໄດ້ຍິນກ່ຽວກັບຜູ້ຊາຍທີ່ສູນເສຍຮ່າງກາຍເບື້ອງຊ້າຍຂອງລາວບໍ? ດຽວນີ້ລາວຖືກຕ້ອງສະ ເໝີ ໄປ!" (ການ​ແປ​ພາ​ສາ​ໂດຍ​ປະ​ມານ​, ເນື່ອງ​ຈາກ​ວ່າ​ຕົ້ນ​ສະ​ບັບ​ມີ​ການ​ຫຼິ້ນ​ຂອງ​ຕົນ​ເອງ​ກ່ຽວ​ກັບ​ຄໍາ​ສັບ​ຕ່າງໆ - ປະ​ມານ​. transl​.)

ມັນເປັນທີ່ຊັດເຈນວ່າການຂຽນໄປຫາທຸກໆຄົນໃນບັນຊີລາຍຊື່ຕິດຕໍ່ບໍ່ແມ່ນທາງເລືອກ. ແລະ, ຖ້າເຈົ້າເປັນອັນໃດອັນໜຶ່ງຄືກັບຂ້ອຍ, ເຈົ້າຈະໄປຫຼາຍຈຸດເພື່ອຫຼີກລ່ຽງວຽກທີ່ບໍ່ຈຳເປັນ. ໂຊກດີ, Terrible Pun of the Day ສາມາດເຊີນໝູ່ຂອງເຈົ້າທັງໝົດໄດ້! ເພື່ອເຮັດສິ່ງນີ້, ທ່ານພຽງແຕ່ຕ້ອງການໃຫ້ລາວເຂົ້າເຖິງອີເມວຂອງຜູ້ຕິດຕໍ່ຂອງທ່ານ - ເວັບໄຊທ໌ເອງຈະສົ່ງຄໍາເຊີນໃຫ້ພວກເຂົາ (ກົດລະບຽບ OAuth)!

“ທຸກ​ຄົນ​ມັກ puns! - ເຂົ້າສູ່ລະບົບແລ້ວບໍ? — ເຈົ້າຕ້ອງການໃຫ້ເວັບໄຊທ໌ Terrible Pun of the Day ເຂົ້າເຖິງລາຍຊື່ຜູ້ຕິດຕໍ່ຂອງເຈົ້າບໍ? - ຂອບ​ໃຈ! ຈາກ​ນີ້​ໄປ, ພວກ​ເຮົາ​ຈະ​ສົ່ງ​ການ​ເຕືອນ​ທຸກໆ​ມື້​ໃຫ້​ທຸກ​ຄົນ​ທີ່​ທ່ານ​ຮູ້​ຈັກ​ຈົນ​ກ​່​ວາ​ຫມົດ​ເວ​ລາ​! ເຈົ້າເປັນຫມູ່ທີ່ດີທີ່ສຸດ!”

1. ເລືອກການບໍລິການອີເມລ໌ຂອງທ່ານ.
2. ຖ້າຈໍາເປັນ, ໄປທີ່ເວັບໄຊທ໌ທາງໄປສະນີແລະເຂົ້າສູ່ລະບົບບັນຊີຂອງທ່ານ.
3. ອະນຸຍາດໃຫ້ Terrible Pun of the Day ເຂົ້າເຖິງລາຍຊື່ຜູ້ຕິດຕໍ່ຂອງທ່ານ.
4. ກັບຄືນໄປຫາເວັບໄຊທ໌ Terrible Pun of the Day.

ໃນ​ກໍ​ລະ​ນີ​ທີ່​ທ່ານ​ປ່ຽນ​ໃຈ​ຂອງ​ທ່ານ​, ກິດ​ທີ່​ນໍາ​ໃຊ້ OAuth ຍັງ​ໃຫ້​ວິ​ທີ​ການ​ຖອນ​ຄືນ​ການ​ເຂົ້າ​ເຖິງ​. ເມື່ອທ່ານຕັດສິນໃຈວ່າທ່ານບໍ່ຕ້ອງການແບ່ງປັນການຕິດຕໍ່ກັບ Terrible Pun of the Day ອີກຕໍ່ໄປ, ທ່ານສາມາດເຂົ້າໄປທີ່ mail site ແລະເອົາເວັບໄຊທ໌ pun ອອກຈາກບັນຊີລາຍຊື່ຂອງຄໍາຮ້ອງສະຫມັກທີ່ໄດ້ຮັບອະນຸຍາດຂອງທ່ານ.

ກະແສ OAuth

ພວກເຮົາພຽງແຕ່ໄດ້ຜ່ານສິ່ງທີ່ເອີ້ນວ່າທົ່ວໄປ ໄຫຼ [ໄຫຼ] OAuth. ໃນຕົວຢ່າງຂອງພວກເຮົາ, ການໄຫຼເຂົ້ານີ້ປະກອບດ້ວຍຂັ້ນຕອນທີ່ເຫັນໄດ້, ເຊັ່ນດຽວກັນກັບຂັ້ນຕອນທີ່ເບິ່ງບໍ່ເຫັນ, ເຊິ່ງສອງບໍລິການຕົກລົງເຫັນດີກັບການແລກປ່ຽນຂໍ້ມູນຢ່າງປອດໄພ. ຕົວຢ່າງ Pun of the Terrible ທີ່ຜ່ານມາໃຊ້ກະແສ OAuth 2.0 ທົ່ວໄປທີ່ສຸດ, ເຊິ່ງເອີ້ນກັນວ່າກະແສ "ລະຫັດການອະນຸຍາດ". ["ລະຫັດການອະນຸຍາດ" flow].

ກ່ອນທີ່ພວກເຮົາຈະເຂົ້າໄປໃນລາຍລະອຽດຂອງວິທີການເຮັດວຽກຂອງ OAuth, ໃຫ້ເວົ້າກ່ຽວກັບຄວາມຫມາຍຂອງບາງຄໍາສັບ:

• ເຈົ້າຂອງຊັບພະຍາກອນ:

  
  
  ມັນແມ່ນເຈົ້າ! ທ່ານເປັນເຈົ້າຂອງຂໍ້ມູນປະຈໍາຕົວ, ຂໍ້ມູນຂອງທ່ານ, ແລະຄວບຄຸມການດໍາເນີນການທັງຫມົດທີ່ສາມາດປະຕິບັດໃນບັນຊີຂອງທ່ານ.

• ລູກ​ຄ້າ:

  
  
  ແອັບພລິເຄຊັນ (ເຊັ່ນ: ບໍລິການ Terrible Pun of the Day) ທີ່ຕ້ອງການເຂົ້າເຖິງ ຫຼືດຳເນີນການບາງຢ່າງໃນນາມຂອງ ເຈົ້າຂອງຊັບພະຍາກອນ'ກ.

• ເຊີບເວີການອະນຸຍາດ:

  
  
  ຄໍາຮ້ອງສະຫມັກທີ່ຮູ້ ເຈົ້າຂອງຊັບພະຍາກອນ'a ແລະໃນທີ່ y ເຈົ້າຂອງຊັບພະຍາກອນ'ແລະມີບັນຊີຢູ່ແລ້ວ.

• ເຊີບເວີຊັບພະຍາກອນ:

  
  
  ການໂຕ້ຕອບການຂຽນໂປລແກລມແອັບພລິເຄຊັນ (API) ຫຼືບໍລິການທີ່ ລູກ​ຄ້າ ຕ້ອງການໃຊ້ໃນນາມ ເຈົ້າຂອງຊັບພະຍາກອນ'ກ.

• ປ່ຽນເສັ້ນທາງ URI:

  
  
  ການເຊື່ອມຕໍ່ທີ່ ເຊີບເວີການອະນຸຍາດ ຈະປ່ຽນເສັ້ນທາງ ເຈົ້າຂອງຊັບພະຍາກອນ'ແລະ​ຫຼັງ​ຈາກ​ການ​ອະ​ນຸ​ຍາດ​ ລູກ​ຄ້າ'ເຈົ້າ. ບາງຄັ້ງອັນນີ້ເອີ້ນວ່າ "URL ເອີ້ນຄືນ".

• ປະເພດການຕອບສະໜອງ:

  
  
  ປະເພດຂອງຂໍ້ມູນທີ່ຄາດວ່າຈະໄດ້ຮັບ ລູກ​ຄ້າ. ທົ່ວໄປທີ່ສຸດ ປະເພດການຕອບສະໜອງ'om ແມ່ນລະຫັດ, ນັ້ນແມ່ນ ລູກ​ຄ້າ ຄາດວ່າຈະໄດ້ຮັບ ລະຫັດອະນຸຍາດ.

• ຂອບເຂດ:

  
  
  ນີ້ແມ່ນລາຍລະອຽດຂອງການອະນຸຍາດທີ່ຕ້ອງການ ລູກ​ຄ້າ'y, ເຊັ່ນ: ການເຂົ້າເຖິງຂໍ້ມູນຫຼືການປະຕິບັດບາງຢ່າງ.

• ຍິນຍອມເຫັນດີ:

  
  
  ເຊີບເວີການອະນຸຍາດ ໃຊ້ເວລາ ຂອບເຂດ, ຮ້ອງຂໍ ລູກ​ຄ້າ'om, ແລະຖາມ ເຈົ້າຂອງຊັບພະຍາກອນ'ອ່າ, ລາວພ້ອມທີ່ຈະສະຫນອງ ລູກ​ຄ້າ'ມີການອະນຸຍາດທີ່ເຫມາະສົມ.

• ID ລູກຄ້າ:

  
  
  ID ນີ້ຖືກໃຊ້ສໍາລັບການລະບຸຕົວຕົນ ລູກ​ຄ້າ'ແລະຕໍ່ໄປ ເຊີບເວີການອະນຸຍາດ'ອີ.

• ຄວາມລັບລູກຄ້າ:

  
  
  ນີ້ແມ່ນລະຫັດຜ່ານທີ່ຮູ້ຈັກເທົ່ານັ້ນ ລູກ​ຄ້າ'ເຈົ້າ ແລະ ເຊີບເວີການອະນຸຍາດ'ເຈົ້າ. ມັນອະນຸຍາດໃຫ້ພວກເຂົາແລກປ່ຽນຂໍ້ມູນເປັນຄວາມລັບ.

• ລະຫັດອະນຸຍາດ:

  
  
  ລະຫັດຊົ່ວຄາວທີ່ມີໄລຍະເວລາສັ້ນຂອງຄວາມຖືກຕ້ອງ, ເຊິ່ງ ລູກ​ຄ້າ ສະຫນອງ ເຊີບເວີການອະນຸຍາດ'y ໃນ​ການ​ແລກ​ປ່ຽນ​ສໍາ​ລັບ ເຂົ້າໃຊ້ Token.

• ເຂົ້າໃຊ້ Token:

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

Примечание: ບາງຄັ້ງເຄື່ອງແມ່ຂ່າຍການອະນຸຍາດ ແລະເຄື່ອງແມ່ຂ່າຍຊັບພະຍາກອນແມ່ນເຄື່ອງແມ່ຂ່າຍດຽວກັນ. ຢ່າງໃດກໍຕາມ, ໃນບາງກໍລະນີເຫຼົ່ານີ້ອາດຈະເປັນເຄື່ອງແມ່ຂ່າຍທີ່ແຕກຕ່າງກັນ, ເຖິງແມ່ນວ່າບໍ່ແມ່ນຂອງອົງການຈັດຕັ້ງດຽວກັນ. ຕົວຢ່າງ, ເຄື່ອງແມ່ຂ່າຍການອະນຸຍາດອາດຈະເປັນບໍລິການພາກສ່ວນທີສາມທີ່ໄວ້ວາງໃຈໂດຍເຄື່ອງແມ່ຂ່າຍຊັບພະຍາກອນ.

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

1. ເຈົ້າ, ເຈົ້າຂອງຊັບພະຍາກອນ, ຕ້ອງການໃຫ້ບໍລິການ Pun ຂີ້ຮ້າຍຂອງມື້ (ລູກ​ຄ້າ'y) ເຂົ້າເຖິງຜູ້ຕິດຕໍ່ຂອງທ່ານເພື່ອວ່າລາວສາມາດສົ່ງຄໍາເຊີນໄປຫາຫມູ່ເພື່ອນຂອງທ່ານທັງຫມົດ.
2. ລູກ​ຄ້າ redirects ຕົວທ່ອງເວັບໄປຫາຫນ້າ ເຊີບເວີການອະນຸຍາດ'a ແລະລວມຢູ່ໃນຄໍາຮ້ອງຂໍ ID ລູກຄ້າ, ປ່ຽນເສັ້ນທາງ URI, ປະເພດການຕອບສະໜອງ ແລະຫນຶ່ງຫຼືຫຼາຍກວ່ານັ້ນ ຂອບເຂດ (ການອະນຸຍາດ) ທີ່ລາວຕ້ອງການ.
3. ເຊີບເວີການອະນຸຍາດ ກວດເບິ່ງທ່ານ, ຖ້າຈໍາເປັນ, ຂໍໃຫ້ເຂົ້າສູ່ລະບົບແລະລະຫັດຜ່ານ.
4. ເຊີບເວີການອະນຸຍາດ ສະແດງແບບຟອມ ຍິນຍອມເຫັນດີ (ການຢືນຢັນ) ກັບບັນຊີລາຍຊື່ຂອງທັງຫມົດ ຂອບເຂດຮ້ອງຂໍ ລູກ​ຄ້າ'ໂອ. ທ່ານຕົກລົງຫຼືປະຕິເສດ.
5. ເຊີບເວີການອະນຸຍາດ redirects ທ່ານໄປຫາເວັບໄຊທ໌ ລູກ​ຄ້າ'a, ການນໍາໃຊ້ ປ່ຽນເສັ້ນທາງ URI ພ້ອມດ້ວຍ ລະຫັດອະນຸຍາດ (ລະຫັດການອະນຸຍາດ).
6. ລູກ​ຄ້າ ຕິດ​ຕໍ່​ພົວ​ພັນ​ໂດຍ​ກົງ​ ເຊີບເວີການອະນຸຍາດ'om (ຂ້າມ browser ເຈົ້າຂອງຊັບພະຍາກອນ'a) ແລະສົ່ງຢ່າງປອດໄພ ID ລູກຄ້າ, ຄວາມລັບລູກຄ້າ и ລະຫັດອະນຸຍາດ.
7. ເຊີບເວີການອະນຸຍາດ ກວດ​ສອບ​ຂໍ້​ມູນ​ແລະ​ຕອບ​ສະ​ຫນອງ​ກັບ​ ເຂົ້າໃຊ້ Token'om (ໂທເຄັນການເຂົ້າເຖິງ).
8. ໃນປັດຈຸບັນ ລູກ​ຄ້າ ສາມາດນໍາໃຊ້ ເຂົ້າໃຊ້ Token ເພື່ອສົ່ງຄໍາຮ້ອງຂໍໃຫ້ ເຊີບເວີຊັບພະຍາກອນ ເພື່ອໃຫ້ໄດ້ຮັບບັນຊີລາຍຊື່ຕິດຕໍ່.

ID ລູກຄ້າແລະຄວາມລັບ

ດົນນານກ່ອນທີ່ທ່ານຈະອະນຸຍາດໃຫ້ Terrible Pun of the Day ເຂົ້າເຖິງການຕິດຕໍ່ຂອງທ່ານ, ລູກຄ້າແລະເຄື່ອງແມ່ຂ່າຍການອະນຸຍາດສ້າງຄວາມສໍາພັນໃນການເຮັດວຽກ. ເຄື່ອງແມ່ຂ່າຍການອະນຸຍາດສ້າງ ID ລູກຄ້າແລະຄວາມລັບຂອງລູກຄ້າ (ບາງຄັ້ງເອີ້ນວ່າ ID ແອັບ и ແອັບລັບ) ແລະສົ່ງພວກມັນໄປໃຫ້ລູກຄ້າເພື່ອໂຕ້ຕອບເພີ່ມເຕີມພາຍໃນ OAuth.

“-ສະບາຍດີ! ຂ້ອຍຢາກເຮັດວຽກກັບເຈົ້າ! - ແນ່ນອນ, ບໍ່ແມ່ນບັນຫາ! ນີ້ແມ່ນລະຫັດລູກຄ້າ ແລະຄວາມລັບຂອງເຈົ້າ!”

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

ແຕ່ນັ້ນບໍ່ແມ່ນທັງໝົດ... ກະລຸນາເວົ້າສະບາຍດີກັບ OpenID Connect!

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

OpenID Connect ຊ່ວຍໃຫ້ທ່ານສາມາດປະຕິບັດສະຖານະການທີ່ການເຂົ້າສູ່ລະບົບດຽວສາມາດຖືກນໍາໃຊ້ໃນຫຼາຍຄໍາຮ້ອງສະຫມັກ - ວິທີການນີ້ຍັງເອີ້ນວ່າ ເຊັນດຽວ (ສສຊ). ຕົວຢ່າງ, ແອັບພລິເຄຊັນສາມາດສະຫນັບສະຫນູນການເຊື່ອມໂຍງ SSO ກັບເຄືອຂ່າຍສັງຄົມເຊັ່ນ Facebook ຫຼື Twitter, ໃຫ້ຜູ້ໃຊ້ສາມາດໃຊ້ບັນຊີທີ່ພວກເຂົາມີຢູ່ແລ້ວແລະມັກໃຊ້.

ຂັ້ນຕອນ OpenID Connect ມີລັກສະນະດຽວກັນກັບ OAuth. ຄວາມແຕກຕ່າງພຽງແຕ່ວ່າໃນຄໍາຮ້ອງຂໍຕົ້ນຕໍຂອບເຂດສະເພາະທີ່ໃຊ້ແມ່ນ openid, - ກ ລູກ​ຄ້າ ໃນທີ່ສຸດມັນໄດ້ຮັບການຄ້າຍຄື ເຂົ້າໃຊ້ Token, ແລະ ID Token.

ຄືກັນກັບໃນກະແສ OAuth, ເຂົ້າໃຊ້ Token ໃນ OpenID Connect - ນີ້ແມ່ນຄ່າທີ່ແນ່ນອນທີ່ບໍ່ຊັດເຈນ ລູກ​ຄ້າ'ເຈົ້າ. ຈາກທັດສະນະ ລູກ​ຄ້າ'ກ ເຂົ້າໃຊ້ Token ເປັນຕົວແທນຂອງສະຕຣິງຂອງຕົວອັກສອນທີ່ຖືກສົ່ງໄປພ້ອມກັບແຕ່ລະຄໍາຮ້ອງຂໍ ເຊີບເວີຊັບພະຍາກອນ'y, ແລະທີ່ກໍານົດວ່າ token ຖືກຕ້ອງຫຼືບໍ່. ID Token ແມ່ນບາງສິ່ງບາງຢ່າງທີ່ແຕກຕ່າງກັນຫມົດ.

ID Token ແມ່ນ JWT

ID Token ເປັນສະຕຣິງທີ່ມີຮູບແບບສະເພາະຂອງຕົວອັກສອນທີ່ຮູ້ຈັກເປັນ JSON Web Token ຫຼື JWT (JWT tokens ບາງຄັ້ງຖືກອອກສຽງເປັນ "jots"). ສໍາລັບຜູ້ສັງເກດການພາຍນອກ, JWT ອາດຈະເບິ່ງຄືວ່າ gobbledygook ທີ່ບໍ່ສາມາດເຂົ້າໃຈໄດ້, ແຕ່ ລູກ​ຄ້າ ສາມາດສະກັດຂໍ້ມູນຕ່າງໆຈາກ JWT ເຊັ່ນ ID, ຊື່ຜູ້ໃຊ້, ເວລາເຂົ້າສູ່ລະບົບບັນຊີ, ວັນໝົດອາຍຸ ID Token'ah, ການປະກົດຕົວຂອງຄວາມພະຍາຍາມທີ່ຈະແຊກແຊງ JWT. ຂໍ້ມູນພາຍໃນ ID Token'ແລະຖືກເອີ້ນວ່າ ຄໍາຮ້ອງສະຫມັກ [ການຮຽກຮ້ອງ].

ໃນກໍລະນີຂອງ ODDC ຍັງມີວິທີການມາດຕະຖານເຊັ່ນ ລູກ​ຄ້າ ອາດຈະຮ້ອງຂໍຂໍ້ມູນສ່ວນຕົວເພີ່ມເຕີມ [ຕົວຕົນ] ຈາກ ເຊີບເວີການອະນຸຍາດ'ແລະ, ສໍາລັບການຍົກຕົວຢ່າງ, ທີ່ຢູ່ອີເມວໂດຍໃຊ້ ເຂົ້າໃຊ້ Token.

ສຶກສາເພີ່ມເຕີມກ່ຽວກັບ OAuth ແລະ OIDC

ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ເບິ່ງສັ້ນໆວ່າ OAuth ແລະ ODC ເຮັດວຽກແນວໃດ. ພ້ອມ​ທີ່​ຈະ​ຂຸດ​ເລິກ​? ນີ້ແມ່ນຊັບພະຍາກອນເພີ່ມເຕີມເພື່ອຊ່ວຍໃຫ້ທ່ານຮຽນຮູ້ເພີ່ມເຕີມກ່ຽວກັບ OAuth 2.0 ແລະ OpenID Connect:

• OAuth ແມ່ນຫຍັງ?
• ບໍ່ມີໃຜສົນໃຈ OAuth ຫຼື OpenID Connect
• ປະຕິບັດລະຫັດການອະນຸຍາດ OAuth 2.0 ກັບ PKCE Flow
• ປະເພດການຊ່ວຍເຫຼືອລ້າ OAuth 2.0 ແມ່ນຫຍັງ?
• OAuth 2.0 ຈາກເສັ້ນຄໍາສັ່ງ
• ສ້າງແອັບ Node.js ທີ່ປອດໄພດ້ວຍ SQL Server

ໃນຖານະເປັນສະເຫມີ, ມີຄວາມຮູ້ສຶກໃຫ້ກັບຜູ້ສະແດງຄວາມຄິດເຫັນ. ເພື່ອຕິດຕາມຂ່າວສານຫຼ້າສຸດຂອງພວກເຮົາ, ສະໝັກສະມາຊິກ Twitter и YouTube Okta ສໍາລັບນັກພັດທະນາ!

PS ຈາກນັກແປ

ອ່ານຍັງຢູ່ໃນ blog ຂອງພວກເຮົາ:

• «ABC ຂອງຄວາມປອດໄພໃນ Kubernetes: ການກວດສອບຄວາມຖືກຕ້ອງ, ການອະນຸຍາດ, ການກວດສອບ"
• «ຜູ້ໃຊ້ແລະການອະນຸຍາດ RBAC ໃນ Kubernetes"
• «33+ ເຄື່ອງມືຄວາມປອດໄພ Kubernetes"
• «ຄວາມປອດໄພສໍາລັບ Docker containers".

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