ບັນທຶກການຕັດສິນໃຈດ້ານສະຖາປັດຕະຍະກຳ: ທາງເລືອກການພິສູດຢືນຢັນຕົວຕົນ ແລະ ການອະນຸຍາດ

ການພິສູດຢືນຢັນຕົວຕົນ (authentication) ແລະ ການອະນຸຍາດ (authorization) ຂອງເວັບແອັບພລິເຄຊັນເປັນສອງແນວຄິດສຳຄັນໃນການຮັກສາຄວາມປອດໄພຂອງການເຂົ້າເຖິງແອັບພລິເຄຊັນ ແລະ ບໍລິການ. ທັງສອງກ່ຽວຂ້ອງກັບຕົວຕົນຂອງຜູ້ໃຊ້ ແລະ ວິທີມອບສິດ ແຕ່ເນັ້ນດ້ານທີ່ແຕກຕ່າງກັນ:

ການພິສູດຢືນຢັນຕົວຕົນ (Authentication) ແມ່ນຂະບວນການກວດສອບຕົວຕົນຂອງຜູ້ໃຊ້ ຫຼື ລະບົບ.
ການອະນຸຍາດ (Authorization) ແມ່ນຂະບວນການກຳນົດວ່າຜູ້ໃຊ້ ຫຼື ລະບົບທີ່ໄດ້ຮັບການພິສູດຢືນຢັນແລ້ວສາມາດເຂົ້າເຖິງຊັບພະຍາກອນ ຫຼື ການກະທຳໃດ.

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

1. OAuth (Open Authorization)

OAuth ແມ່ນມາດຕະຖານເປີດສຳລັບການອະນຸຍາດ. ມັນຊ່ວຍໃຫ້ຜູ້ໃຊ້ມອບສິດການເຂົ້າເຖິງຊັບພະຍາກອນຂອງຕົນແບບຈຳກັດໃຫ້ແອັບພລິເຄຊັນຂອງບຸກຄົນທີສາມ ໂດຍບໍ່ແບ່ງປັນຂໍ້ມູນຢັ້ງຢືນຕົວຕົນຂອງຕົນ. ແນວຄິດຫຼັກແມ່ນ ການເຂົ້າເຖິງແບບມອບໝາຍ (delegated access). OAuth ມັກຖືກໃຊ້ໃນສະຖານະການທີ່ຜູ້ໃຊ້ສາມາດເຂົ້າສູ່ລະບົບບໍລິການຂອງບຸກຄົນທີສາມ (ເຊັ່ນ ການເຂົ້າສູ່ລະບົບດ້ວຍ Google) ໂດຍບໍ່ໃຫ້ຊື່ຜູ້ໃຊ້ ແລະ ລະຫັດຜ່ານຕໍ່ບຸກຄົນທີສາມໂດຍກົງ.

ຂັ້ນຕອນ (Flow): OAuth ໂດຍທົ່ວໄປປະຕິບັດຕາມຂັ້ນຕອນແບບ ໂທເຄັນ (token-based) ເຊິ່ງເຊີບເວີການອະນຸຍາດອອກ access token ໃຫ້ແອັບພລິເຄຊັນຂອງບຸກຄົນທີສາມ. ໂທເຄັນນີ້ເປັນຕົວແທນຂອງສິດຂອງຜູ້ໃຊ້ ແລະ ແອັບພລິເຄຊັນໃຊ້ມັນເພື່ອເຂົ້າເຖິງຂໍ້ມູນ ຫຼື ຊັບພະຍາກອນຂອງຜູ້ໃຊ້ຈາກ API.
ຕົວຢ່າງ: ຜູ້ໃຊ້ເຂົ້າສູ່ລະບົບແອັບຂອງບຸກຄົນທີສາມໂດຍໃຊ້ບັນຊີ Google ຂອງຕົນ. Google ກວດສອບຕົວຕົນຂອງຜູ້ໃຊ້ ແລ້ວມອບໂທເຄັນທີ່ຊ່ວຍໃຫ້ແອັບຂອງບຸກຄົນທີສາມເຂົ້າເຖິງຂໍ້ມູນ Google ບາງຢ່າງ (ເຊັ່ນ Google Calendar).

OAuth ບໍ່ໄດ້ ຈັດການການພິສູດຢືນຢັນຕົວຕົນໂດຍກົງ; ມັນກ່ຽວກັບການມອບສິດການເຂົ້າເຖິງ. ສຳລັບການພິສູດຢືນຢັນຕົວຕົນ OAuth ມັກຖືກຈັບຄູ່ກັບໂປຣໂຕຄອນອື່ນ ເຊັ່ນ OpenID Connect.

2. OpenID Connect (OIDC)

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

ຂັ້ນຕອນ (Flow): ເມື່ອຜູ້ໃຊ້ເຂົ້າສູ່ລະບົບໂດຍໃຊ້ OpenID Connect ແອັບພລິເຄຊັນຂອງບຸກຄົນທີສາມຮ້ອງຂໍ ID token (ນອກເໜືອຈາກ OAuth access token). ID token ມີຂໍ້ມູນກ່ຽວກັບຜູ້ໃຊ້ (ເຊັ່ນ ຊື່ຜູ້ໃຊ້, ອີເມວ ແລະ claims ອື່ນໆ). ສິ່ງນີ້ຊ່ວຍໃຫ້ແອັບພລິເຄຊັນຮູ້ວ່າຜູ້ໃຊ້ແມ່ນໃຜ ແລະ ໄດ້ຮັບການພິສູດຢືນຢັນແລ້ວຫຼືບໍ່.
ຕົວຢ່າງ: ການເຂົ້າສູ່ລະບົບບໍລິການເຊັ່ນ Slack ໂດຍໃຊ້ບັນຊີ Google ຂອງທ່ານ (Google ເປັນຜູ້ໃຫ້ບໍລິການ OpenID Connect) ກ່ຽວຂ້ອງກັບການພິສູດຢືນຢັນຕົວຕົນຜ່ານ OpenID Connect ໃນຂະນະທີ່ OAuth ຈັດການການເຂົ້າເຖິງຊັບພະຍາກອນ Google ຂອງທ່ານ.

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

3. SAML (Security Assertion Markup Language)

SAML ແມ່ນມາດຕະຖານເກົ່າກວ່າທີ່ອີງໃສ່ XML ໃຊ້ແລກປ່ຽນຂໍ້ມູນການພິສູດຢືນຢັນຕົວຕົນ ແລະ ການອະນຸຍາດລະຫວ່າງຝ່າຍຕ່າງໆ ໂດຍສະເພາະໃນສະຖານະການ Single Sign-On (SSO). ມັນຖືກໃຊ້ຫຼັກໆໃນສະພາບແວດລ້ອມວິສາຫະກິດ ເພື່ອໃຫ້ຜູ້ໃຊ້ພິສູດຢືນຢັນຕົວຕົນຄັ້ງດຽວ ແລະ ເຂົ້າເຖິງຫຼາຍແອັບພລິເຄຊັນໂດຍບໍ່ຕ້ອງໃສ່ຂໍ້ມູນຢັ້ງຢືນຕົວຕົນຄືນໃໝ່.

ຂັ້ນຕອນ (Flow): ຜູ້ໃຊ້ພິສູດຢືນຢັນຕົວຕົນກັບຜູ້ໃຫ້ບໍລິການຕົວຕົນ (IdP) ກ່ອນ. IdP ສ້າງ SAML assertion ທີ່ລົງລາຍເຊັນ ເຊິ່ງລວມຕົວຕົນຂອງຜູ້ໃຊ້ ແລະ ຄຸນລັກສະນະທີ່ກ່ຽວຂ້ອງ. assertion ຖືກສົ່ງໄປຫາຜູ້ໃຫ້ບໍລິການ (SP) ເຊິ່ງໃຊ້ມັນເພື່ອອະນຸຍາດການເຂົ້າເຖິງແອັບພລິເຄຊັນ.
ຕົວຢ່າງ: ພະນັກງານເຂົ້າສູ່ລະບົບພອດທັນຂອງບໍລິສັດ (IdP) ແລະ ຖືກເຂົ້າສູ່ລະບົບລະບົບອື່ນໂດຍອັດຕະໂນມັດ ເຊັ່ນ ອີເມວ, CRM ແລະ ອື່ນໆ ໂດຍບໍ່ຕ້ອງໃສ່ຂໍ້ມູນຢັ້ງຢືນຕົວຕົນຄືນໃໝ່. ຂະບວນການພິສູດຢືນຢັນຕົວຕົນອີງໃສ່ SAML assertion ທີ່ IdP ສົ່ງ.

SAML ຖືກໃຊ້ທົ່ວໄປໃນ ວິທີແກ້ໄຂ SSO ຂອງວິສາຫະກິດ ແລະ ເຮັດວຽກໄດ້ດີສຳລັບເວັບແອັບພລິເຄຊັນໃນສະພາບແວດລ້ອມບໍລິສັດ ແຕ່ເປັນມິດກັບມືຖືໜ້ອຍກວ່າເມື່ອທຽບກັບ OAuth/OIDC.

4. WS-Federation (Web Services Federation)

WS-Federation ແມ່ນໂປຣໂຕຄອນອີກອັນທີ່ໃຊ້ສຳລັບ Single Sign-On (SSO) ໂດຍສະເພາະໃນສະພາບແວດລ້ອມວິສາຫະກິດທີ່ອີງໃສ່ Microsoft. ມັນເປັນສ່ວນໜຶ່ງຂອງຕະກູນຂໍ້ກຳນົດສະເພາະ WS- (Web Services)* ແລະ ຊ່ວຍໃຫ້ເຮັດ identity federation ຂ້າມໂດເມນຄວາມປອດໄພທີ່ແຕກຕ່າງກັນ (ເຊັ່ນ ລະຫວ່າງອົງກອນທີ່ແຕກຕ່າງກັນ ຫຼື ລະຫວ່າງບໍລິການທີ່ແຕກຕ່າງກັນ).

ຂັ້ນຕອນ (Flow): WS-Federation ຊ່ວຍໃຫ້ ຜູ້ໃຫ້ບໍລິການຕົວຕົນທີ່ເຊື່ອຖືໄດ້ (IdP) ພິສູດຢືນຢັນຕົວຕົນຜູ້ໃຊ້ ແລະ ອອກໂທເຄັນທີ່ຜູ້ໃຫ້ບໍລິການສາມາດໃຊ້ສຳລັບການອະນຸຍາດ. ມັນຄ້າຍກັບ SAML ແຕ່ມັກຖືກໃຊ້ໃນສະຖານະການທີ່ອີງໃສ່ເທັກໂນໂລຢີ Microsoft ຢ່າງໜັກ.
ຕົວຢ່າງ: ຜູ້ໃຊ້ເຂົ້າສູ່ລະບົບແອັບພລິເຄຊັນວິສາຫະກິດທີ່ໂຮດໂດຍ Microsoft Azure Active Directory (AD) ແລະ ຕົວຕົນຂອງເຂົາສາມາດໃຊ້ເຂົ້າເຖິງບໍລິການ federated ອື່ນ ລວມທັງແອັບພລິເຄຊັນທີ່ໂຮດໂດຍຜູ້ຂາຍບຸກຄົນທີສາມ.

ເຖິງແມ່ນ WS-Federation ຖືກແທນທີ່ໃນສ່ວນໃຫຍ່ໂດຍໂປຣໂຕຄອນໃໝ່ກວ່າເຊັ່ນ OAuth2.0 ແລະ OpenID Connect ໃນຫຼາຍສະພາບແວດລ້ອມເວັບສະໄໝໃໝ່ ແຕ່ມັນຍັງຖືກໃຊ້ໃນລະບົບເກົ່າ ໂດຍສະເພາະໃນວິສາຫະກິດທີ່ເນັ້ນ Microsoft.

5. LDAP (Lightweight Directory Access Protocol)

LDAP ແມ່ນໂປຣໂຕຄອນທີ່ໃຊ້ເຂົ້າເຖິງ ແລະ ຈັດການບໍລິການໄດເຣັກທໍຣີ ເຊິ່ງໃຊ້ທົ່ວໄປສຳລັບ ການເກັບຂໍ້ມູນຢັ້ງຢືນຕົວຕົນຂອງຜູ້ໃຊ້ ແລະ ການຈັດການການຄວບຄຸມການເຂົ້າເຖິງໃນໄດເຣັກທໍຣີສູນກາງ (ມັກເອີ້ນວ່າ Directory Service). LDAP ບໍ່ໄດ້ກ່ຽວກັບການພິສູດຢືນຢັນຕົວຕົນ ຫຼື ການອະນຸຍາດໂດຍສະເພາະ ແຕ່ຖືກໃຊ້ເກັບ ແລະ ດຶງຂໍ້ມູນຕົວຕົນ ເຊິ່ງຈາກນັ້ນຖືກໃຊ້ໃນຂະບວນການເຫຼົ່ານັ້ນ.

ການພິສູດຢືນຢັນຕົວຕົນ: LDAP ຊ່ວຍໃຫ້ແອັບພລິເຄຊັນພິສູດຢືນຢັນຕົວຕົນຜູ້ໃຊ້ໂດຍສອບຖາມບໍລິການໄດເຣັກທໍຣີເພື່ອຂໍ້ມູນຢັ້ງຢືນຕົວຕົນ (ເຊັ່ນ ລະຫັດຜ່ານ).
ການອະນຸຍາດ: ມັນຍັງຈັດການບົດບາດ ແລະ ສິດຂອງຜູ້ໃຊ້ ຊ່ວຍກຳນົດວ່າຜູ້ໃຊ້ມີສິດເຂົ້າເຖິງຊັບພະຍາກອນບາງຢ່າງຫຼືບໍ່.
ຕົວຢ່າງ: ວິສາຫະກິດຫຼາຍແຫ່ງໃຊ້ໄດເຣັກທໍຣີທີ່ອີງໃສ່ LDAP (ເຊັ່ນ Active Directory) ສຳລັບການພິສູດຢືນຢັນຕົວຕົນ ແລະ ການອະນຸຍາດ ໂດຍສະເພາະພາຍໃນສະພາບແວດລ້ອມ Windows.

LDAP ມີຄວາມສຳຄັນຕໍ່ວິສາຫະກິດໃນການຈັດການການເຂົ້າເຖິງຂອງຜູ້ໃຊ້ຂ້າມລະບົບພາຍໃນ ແຕ່ໃນບໍລິບົດເວັບສະໄໝໃໝ່ LDAP ມັກຖືກລວມກັບໂປຣໂຕຄອນອື່ນເຊັ່ນ SAML ຫຼື OAuth ເພື່ອການຈັດການຕົວຕົນທີ່ສົມບູນກວ່າ.

ຜູ້ໃຫ້ບໍລິການ Social Single Sign-On (SSO) ເຊັ່ນ Facebook, Google, Twitter, GitHub ແລະ ອື່ນໆ ຊ່ວຍໃຫ້ຜູ້ໃຊ້ພິສູດຢືນຢັນຕົວຕົນເຂົ້າແອັບພລິເຄຊັນຂອງບຸກຄົນທີສາມໂດຍໃຊ້ຂໍ້ມູນຢັ້ງຢືນຕົວຕົນໃນສື່ສັງຄົມຂອງຕົນ. ນີ້ເປັນການພິສູດຢືນຢັນຕົວຕົນປະເພດ ທີ່ອີງໃສ່ OAuth ເຊິ່ງບໍລິການຂອງບຸກຄົນທີສາມ (ເຊັ່ນ Google) ເປັນຜູ້ໃຫ້ບໍລິການຕົວຕົນ.

ຂັ້ນຕອນ (Flow): ຜູ້ໃຊ້ຄລິກ "ເຂົ້າສູ່ລະບົບດ້ວຍ Google" (ຕົວຢ່າງ). ແອັບປ່ຽນເສັ້ນທາງໄປ Google ເຊິ່ງຜູ້ໃຊ້ເຂົ້າສູ່ລະບົບ (ຖ້າຍັງບໍ່ໄດ້ເຂົ້າ). ຈາກນັ້ນ Google ໃຫ້ access token ຫຼື ID token ແກ່ແອັບຂອງບຸກຄົນທີສາມ ເຊິ່ງສາມາດໃຊ້ພິສູດຢືນຢັນຕົວຕົນຜູ້ໃຊ້ ແລະ ອາດເຂົ້າເຖິງຂໍ້ມູນຂອງເຂົາ.
ຕົວຢ່າງ: ແອັບພລິເຄຊັນຫຼາຍຕົວຊ່ວຍໃຫ້ທ່ານເຂົ້າສູ່ລະບົບໂດຍໃຊ້ຂໍ້ມູນຢັ້ງຢືນຕົວຕົນ Google ຫຼື Facebook ຂອງທ່ານ. ແອັບຈະໃຊ້ OAuth ຫຼື OpenID Connect ເບື້ອງຫຼັງເພື່ອກວດສອບຕົວຕົນຂອງທ່ານ ແລະ ໃນບາງກໍລະນີ ເຂົ້າເຖິງຂໍ້ມູນສື່ສັງຄົມບາງຢ່າງ.

Social SSO ເປັນວິທີທີ່ສະດວກ ແລະ ຖືກນຳໃຊ້ຢ່າງກວ້າງຂວາງສຳລັບການພິສູດຢືນຢັນຕົວຕົນ ເພາະມັນຫຼຸດຄວາມຝືດສຳລັບຜູ້ໃຊ້ ທີ່ອາດບໍ່ຢາກສ້າງຊື່ຜູ້ໃຊ້ ແລະ ລະຫັດຜ່ານອີກອັນໜຶ່ງ.

ບົດສະຫຼຸບຄວາມແຕກຕ່າງ:

OAuth: ໃຊ້ສຳລັບການອະນຸຍາດ ຊ່ວຍໃຫ້ແອັບຂອງບຸກຄົນທີສາມເຂົ້າເຖິງຂໍ້ມູນຜູ້ໃຊ້ໂດຍບໍ່ເປີດເຜີຍຂໍ້ມູນຢັ້ງຢືນຕົວຕົນ.
OpenID Connect: ຂະຫຍາຍ OAuth ເພື່ອໃຫ້ການພິສູດຢືນຢັນຕົວຕົນ ຊ່ວຍໃຫ້ແອັບກວດສອບຕົວຕົນຜູ້ໃຊ້.
SAML: ໂປຣໂຕຄອນທີ່ອີງໃສ່ XML ໃຊ້ສຳລັບ SSO ມັກຢູ່ໃນສະພາບແວດລ້ອມວິສາຫະກິດ.
WS-Federation: ໂປຣໂຕຄອນສະເພາະຂອງ Microsoft ສຳລັບ identity federation ໃຊ້ໃນລະບົບເກົ່າ.
LDAP: ໂປຣໂຕຄອນສຳລັບສອບຖາມບໍລິການໄດເຣັກທໍຣີເພື່ອພິສູດຢືນຢັນຕົວຕົນຜູ້ໃຊ້ ແລະ ຈັດການການອະນຸຍາດ.
ຜູ້ໃຫ້ບໍລິການ Social SSO: ລະບົບທີ່ອີງໃສ່ OAuth (ເຊັ່ນ Google, Facebook) ທີ່ຊ່ວຍໃຫ້ແອັບຂອງບຸກຄົນທີສາມພິສູດຢືນຢັນຕົວຕົນຜູ້ໃຊ້ໂດຍໃຊ້ຂໍ້ມູນຢັ້ງຢືນຕົວຕົນໃນສື່ສັງຄົມຂອງເຂົາ.

ແຕ່ລະເທັກໂນໂລຢີເຫຼົ່ານີ້ມີຈຸດແຂງ ແລະ ກໍລະນີການນຳໃຊ້ຂອງຕົນເອງ ແລະ ໃນແອັບພລິເຄຊັນສະໄໝໃໝ່ ທ່ານອາດເຫັນການນຳໃຊ້ການປະສົມຂອງພວກມັນສຳລັບດ້ານຕ່າງໆຂອງຄວາມປອດໄພ (ເຊັ່ນ OAuth/OIDC ສຳລັບການເຂົ້າເຖິງ API, SAML ສຳລັບ SSO ວິສາຫະກິດ).