Architecture Decision Record
← ตัวอย่างบันทึกการตัดสินใจ

บันทึกการตัดสินใจด้านสถาปัตยกรรม: ตัวเลือกการยืนยันตัวตนและการอนุญาตสิทธิ์

การยืนยันตัวตนและการอนุญาตสิทธิ์ของเว็บแอปพลิเคชันเป็นสองแนวคิดสำคัญในการรักษาความปลอดภัยการเข้าถึงแอปพลิเคชันและบริการ ทั้งสองเกี่ยวข้องกับตัวตนของผู้ใช้และวิธีการให้สิทธิ์ แต่มุ่งเน้นแง่มุมที่ต่างกัน:

  • การยืนยันตัวตน (Authentication) คือกระบวนการตรวจสอบตัวตนของผู้ใช้หรือระบบ
  • การอนุญาตสิทธิ์ (Authorization) คือกระบวนการกำหนดว่าผู้ใช้หรือระบบที่ผ่านการยืนยันตัวตนแล้วเข้าถึงทรัพยากรหรือการกระทำใดได้

ต่อไปเรามาเจาะลึกโปรโตคอลและเทคโนโลยีเฉพาะที่คุณกล่าวถึง ซึ่งใช้กันทั่วไปในเว็บแอปพลิเคชันสมัยใหม่เพื่อจัดการการยืนยันตัวตนและการอนุญาตสิทธิ์

1. OAuth (Open Authorization)

OAuth เป็นมาตรฐานเปิดสำหรับการอนุญาตสิทธิ์ ช่วยให้ผู้ใช้ให้แอปพลิเคชันของบุคคลที่สามเข้าถึงทรัพยากรของตนได้อย่างจำกัดโดยไม่ต้องแบ่งปันข้อมูลรับรอง แนวคิดหลักคือ การเข้าถึงที่มอบหมาย OAuth มักใช้ในสถานการณ์ที่ผู้ใช้เข้าสู่ระบบบริการของบุคคลที่สามได้ (เช่น เข้าสู่ระบบด้วย Google) โดยไม่ต้องให้ชื่อผู้ใช้และรหัสผ่านโดยตรงแก่บุคคลที่สาม

  • ลำดับขั้น: OAuth มักเป็นไปตามลำดับขั้นแบบ อิงโทเค็น ซึ่งเซิร์ฟเวอร์การอนุญาตสิทธิ์ออกโทเค็นการเข้าถึงให้แอปพลิเคชันของบุคคลที่สาม โทเค็นนี้แสดงถึงสิทธิ์ของผู้ใช้ และแอปพลิเคชันใช้เพื่อเข้าถึงข้อมูลหรือทรัพยากรของผู้ใช้จาก API
  • ตัวอย่าง: ผู้ใช้เข้าสู่ระบบแอปของบุคคลที่สามด้วยบัญชี Google ของตน Google ตรวจสอบตัวตนของผู้ใช้แล้วให้โทเค็นที่ช่วยให้แอปของบุคคลที่สามเข้าถึงข้อมูล Google บางส่วนได้ (เช่น Google Calendar)

OAuth ไม่ได้จัดการการยืนยันตัวตนโดยตรง แต่เป็นเรื่องการให้สิทธิ์การเข้าถึง สำหรับการยืนยันตัวตน OAuth มักใช้คู่กับโปรโตคอลอื่น เช่น OpenID Connect

2. OpenID Connect (OIDC)

OpenID Connect (OIDC) คือชั้นตัวตนที่สร้างบน OAuth 2.0 ซึ่งเพิ่มการยืนยันตัวตนให้ความสามารถด้านการอนุญาตสิทธิ์ของ OAuth โดยหลักแล้ว OpenID Connect ขยาย OAuth เพื่อจัดการ การยืนยันตัวตนของผู้ใช้ และให้วิธีมาตรฐานสำหรับแอปพลิเคชันในการตรวจสอบตัวตนของผู้ใช้

  • ลำดับขั้น: เมื่อผู้ใช้เข้าสู่ระบบโดยใช้ OpenID Connect แอปพลิเคชันของบุคคลที่สามจะขอโทเค็น ID (นอกเหนือจากโทเค็นการเข้าถึง OAuth) โทเค็น ID มีข้อมูลเกี่ยวกับผู้ใช้ (เช่น ชื่อผู้ใช้ อีเมล และ claim อื่น ๆ) ซึ่งทำให้แอปพลิเคชันรู้ว่าผู้ใช้เป็นใครและผ่านการยืนยันตัวตนแล้วหรือไม่
  • ตัวอย่าง: การเข้าสู่ระบบบริการอย่าง Slack ด้วยบัญชี Google ของคุณ (Google เป็นผู้ให้บริการ OpenID Connect) เกี่ยวข้องกับการยืนยันตัวตนผ่าน OpenID Connect ในขณะที่ OAuth จัดการการเข้าถึงทรัพยากร Google ของคุณ

OIDC ทำให้แอปของบุคคลที่สามยืนยันตัวตนผู้ใช้ได้ง่ายขึ้น พร้อมทั้งยังควบคุมอย่างละเอียดว่าแอปเหล่านั้นเข้าถึงทรัพยากรใดได้

3. SAML (Security Assertion Markup Language)

SAML เป็นมาตรฐานรุ่นเก่ากว่าที่ใช้ XML สำหรับแลกเปลี่ยนข้อมูลการยืนยันตัวตนและการอนุญาตสิทธิ์ระหว่างฝ่ายต่าง ๆ โดยเฉพาะในสถานการณ์ Single Sign-On (SSO) ใช้เป็นหลักในสภาพแวดล้อมองค์กรเพื่อให้ผู้ใช้ยืนยันตัวตนครั้งเดียวและเข้าถึงหลายแอปพลิเคชันได้โดยไม่ต้องป้อนข้อมูลรับรองใหม่

  • ลำดับขั้น: ผู้ใช้ยืนยันตัวตนกับผู้ให้บริการข้อมูลระบุตัวตน (IdP) ก่อน IdP สร้าง ข้อยืนยัน SAML ที่มีลายเซ็นซึ่งรวมตัวตนของผู้ใช้และคุณสมบัติที่เกี่ยวข้อง ข้อยืนยันถูกส่งไปยังผู้ให้บริการบริการ (SP) ซึ่งใช้เพื่ออนุญาตสิทธิ์การเข้าถึงแอปพลิเคชัน
  • ตัวอย่าง: พนักงานเข้าสู่ระบบพอร์ทัลขององค์กร (IdP) และถูกเข้าสู่ระบบโดยอัตโนมัติในระบบอื่น เช่น อีเมล CRM ฯลฯ โดยไม่ต้องป้อนข้อมูลรับรองใหม่ กระบวนการยืนยันตัวตนอิงจากข้อยืนยัน SAML ที่ IdP ส่ง

SAML มักใช้ใน โซลูชัน SSO ระดับองค์กร และทำงานได้ดีสำหรับเว็บแอปพลิเคชันในสภาพแวดล้อมองค์กร แต่เป็นมิตรกับมือถือน้อยกว่า OAuth/OIDC

4. WS-Federation (Web Services Federation)

WS-Federation เป็นอีกโปรโตคอลหนึ่งที่ใช้สำหรับ Single Sign-On (SSO) โดยเฉพาะในสภาพแวดล้อมองค์กรที่ใช้ Microsoft เป็นหลัก เป็นส่วนหนึ่งของกลุ่มข้อกำหนด WS- (Web Services)* และช่วยให้เกิดการรวมกลุ่มตัวตน (identity federation) ข้ามโดเมนความปลอดภัยต่าง ๆ (เช่น ระหว่างองค์กรต่างกันหรือระหว่างบริการต่างกัน)

  • ลำดับขั้น: WS-Federation ให้ ผู้ให้บริการข้อมูลระบุตัวตน (IdP) ที่เชื่อถือได้ ยืนยันตัวตนผู้ใช้และออกโทเค็นที่ผู้ให้บริการบริการใช้เพื่ออนุญาตสิทธิ์ คล้ายกับ SAML แต่มักใช้ในสถานการณ์ที่พึ่งพาเทคโนโลยี Microsoft อย่างมาก
  • ตัวอย่าง: ผู้ใช้เข้าสู่ระบบแอปพลิเคชันองค์กรที่โฮสต์โดย Microsoft Azure Active Directory (AD) และตัวตนของผู้ใช้สามารถใช้เข้าถึงบริการที่รวมกลุ่มอื่น รวมถึงแอปพลิเคชันที่โฮสต์โดยผู้ขายบุคคลที่สาม

แม้ 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 เพื่อการจัดการตัวตนที่สมบูรณ์ยิ่งขึ้น

6. ผู้ให้บริการ SSO ทางโซเชียล

ผู้ให้บริการ Single Sign-On (SSO) ทางโซเชียล เช่น Facebook, Google, Twitter, GitHub และอื่น ๆ ช่วยให้ผู้ใช้ยืนยันตัวตนในแอปพลิเคชันของบุคคลที่สามโดยใช้ข้อมูลรับรองโซเชียลมีเดียของตน นี่คือการยืนยันตัวตนแบบ อิง OAuth ซึ่งบริการของบุคคลที่สาม (เช่น Google) เป็นผู้ให้บริการข้อมูลระบุตัวตน

  • ลำดับขั้น: ผู้ใช้คลิก "เข้าสู่ระบบด้วย Google" (ตัวอย่างเช่น) แอปเปลี่ยนเส้นทางไปยัง Google ซึ่งผู้ใช้เข้าสู่ระบบ (หากยังไม่ได้เข้าสู่ระบบ) จากนั้น Google ให้โทเค็นการเข้าถึงหรือโทเค็น ID แก่แอปของบุคคลที่สาม ซึ่งใช้ยืนยันตัวตนผู้ใช้และอาจเข้าถึงข้อมูลของผู้ใช้
  • ตัวอย่าง: หลายแอปพลิเคชันให้คุณเข้าสู่ระบบด้วยข้อมูลรับรอง Google หรือ Facebook ของคุณ แอปใช้ OAuth หรือ OpenID Connect เบื้องหลังเพื่อตรวจสอบตัวตนของคุณและในบางกรณีเข้าถึงข้อมูลโซเชียลมีเดียบางอย่าง

SSO ทางโซเชียลเป็นวิธียืนยันตัวตนที่สะดวกและนำไปใช้อย่างกว้างขวางเพราะลดแรงเสียดทานสำหรับผู้ใช้ที่อาจไม่ต้องการสร้างชื่อผู้ใช้และรหัสผ่านอีกชุด

สรุปความแตกต่าง:

  • OAuth: ใช้สำหรับการอนุญาตสิทธิ์ ช่วยให้แอปของบุคคลที่สามเข้าถึงข้อมูลผู้ใช้โดยไม่เปิดเผยข้อมูลรับรอง
  • OpenID Connect: ขยาย OAuth เพื่อให้การยืนยันตัวตน ช่วยให้แอปตรวจสอบตัวตนของผู้ใช้
  • SAML: โปรโตคอลที่ใช้ XML สำหรับ SSO มักใช้ในสภาพแวดล้อมองค์กร
  • WS-Federation: โปรโตคอลเฉพาะของ Microsoft สำหรับการรวมกลุ่มตัวตน ใช้ในระบบเดิม
  • LDAP: โปรโตคอลสำหรับสอบถามบริการไดเรกทอรีเพื่อยืนยันตัวตนผู้ใช้และจัดการการอนุญาตสิทธิ์
  • ผู้ให้บริการ SSO ทางโซเชียล: ระบบที่อิง OAuth (เช่น Google, Facebook) ที่ช่วยให้แอปของบุคคลที่สามยืนยันตัวตนผู้ใช้ด้วยข้อมูลรับรองโซเชียลมีเดียของพวกเขา

แต่ละเทคโนโลยีมีจุดแข็งและกรณีใช้งานของตนเอง และในแอปพลิเคชันสมัยใหม่คุณอาจเห็นการใช้ผสมกันสำหรับแง่มุมต่าง ๆ ของความปลอดภัย (เช่น OAuth/OIDC สำหรับการเข้าถึง API, SAML สำหรับ SSO ระดับองค์กร)