รักษาความปลอดภัยแอปพลิเคชันบนคลาวด์ด้วย OAuth 2.0 และ OpenID Connect

บทนำ#

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

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

โพสต์นี้ถือว่าคุณมีพื้นฐานดังนี้:

1. คุณมีความเข้าใจพื้นฐานเกี่ยวกับการพัฒนาแอปพลิเคชัน (เว็บ, มือถือ, หรือประเภทใดๆ)
2. คุณเคยได้ยินเกี่ยวกับแนวคิดของการรับรองและการอนุญาต
3. คุณเคยได้ยินเกี่ยวกับ OAuth 2.0 และ OpenID Connect

ใช่, "เคยได้ยิน" ก็เพียงพอสำหรับข้อ 2 และ 3 โพสต์นี้จะใช้ตัวอย่างในโลกจริงเพื่ออธิบายแนวคิดและแสดงกระบวนการด้วยแผนภาพ มาเริ่มกันเลย!

OAuth 2.0 เทียบกับ OpenID Connect#

หากคุณคุ้นเคยกับ OAuth 2.0 และ OpenID Connect คุณก็สามารถอ่านต่อได้เพราะเราจะครอบคลุมตัวอย่างในโลกจริงในส่วนนี้ด้วย; ถ้าคุณเป็นคนใหม่ในมาตรฐานเหล่านี้ ก็ปลอดภัยที่จะอ่านต่อเพราะเราจะแนะนำพวกเขาในวิธีที่ง่าย

OAuth 2.0#

OAuth 2.0 เป็นกรอบการทำงานของการอนุญาตที่ช่วยให้แอปพลิเคชันได้รับการเข้าถึงทรัพยากรที่ได้รับการป้องกันในแอปพลิเคชันอื่นในนามของผู้ใช้หรือแอปพลิเคชันเอง บริการยอดนิยมส่วนใหญ่เช่น Google, Facebook, และ GitHub ใช้ OAuth 2.0 สำหรับการลงชื่อเข้าสู่ระบบสังคม (เช่น "Sign in with Google")

ตัวอย่างเช่น คุณมีแอปพลิเคชันเว็บ MyApp ที่ต้องการเข้าถึง Google Drive ของผู้ใช้ แทนที่จะขอให้ผู้ใช้แชร์ข้อมูลประจำตัวของ Google Drive MyApp สามารถใช้ OAuth 2.0 เพื่อขอเข้าถึง Google Drive ในนามของผู้ใช้ ต่อไปนี้เป็นกระแสง่าย ๆ:

ในกระบวนการนี้ MyApp ไม่เคยเห็นข้อมูลประจำตัว Google Drive ของผู้ใช้ ในทางกลับกัน มันจะได้รับ โทเค็นการเข้าถึง จาก Google ที่ช่วยให้มันสามารถเข้าถึง Google Drive ในนามของผู้ใช้ได้

ในแง่ของ OAuth 2.0, MyApp คือลูกค้า client, Google เป็นทั้ง เซิร์ฟเวอร์การอนุญาต และ เซิร์ฟเวอร์ทรัพยากร เพื่อความง่าย ในโลกจริง ส่วนใหญ่เรามีเซิร์ฟเวอร์การอนุญาตและเซิร์ฟเวอร์ทรัพยากรแยกกันเพื่อนำเสนอประสบการณ์การลงชื่อเข้าใช้ครั้งเดียว (SSO) ตัวอย่างเช่น Google เป็นเซิร์ฟเวอร์การอนุญาตและอาจมีเซิร์ฟเวอร์ทรัพยากรหลายตัวเช่น Google Drive, Gmail, และ YouTube

โปรดทราบว่ากระบวนการอนุญาตจริงนั้นซับซ้อนกว่านี้ OAuth 2.0 มีประเภทการอนุญาตที่แตกต่างกัน ขอบเขต และแนวคิดอื่น ๆ ที่คุณควรทราบ เป็นการดีที่เรามาข้ามเรื่องนั้นชั่วคราวแล้วไปสู่ OpenID Connect

OpenID Connect (OIDC)#

OAuth 2.0 ยอดเยี่ยมในการอนุญาต แต่คุณอาจสังเกตว่ามันไม่มีวิธีระบุผู้ใช้ (เช่น การระบุตัวตน) OpenID Connect เป็นชั้นบ่งชี้ที่ทำงานบน OAuth 2.0 ที่เพิ่มความสามารถในการระบุตัวตน

ในตัวอย่างข้างต้น MyApp จำเป็นต้องรู้ว่าผู้ใช้คือใครก่อนเริ่มกระบวนการอนุญาต โปรดทราบว่านี่มีผู้ใช้สองคนที่เกี่ยวข้อง: ผู้ใช้ของ MyApp และผู้ใช้ของ Google Drive ในกรณีนี้ MyApp จำเป็นต้องรู้ผู้ใช้ของแอปพลิเคชันของตนเอง

ลองดูตัวอย่างที่ตรงไปตรงมา สมมติว่าผู้ใช้สามารถลงชื่อเข้าใช้ MyApp โดยใช้ชื่อผู้ใช้และรหัสผ่าน:

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

คุณอาจสังเกตว่า ผู้ให้บริการเอกลักษณ์ (IdP) เป็นผู้เข้าร่วมใหม่ในกระบวนการนี้ มันเหมือนกับเซิร์ฟเวอร์การอนุญาตใน OAuth 2.0 แต่เพื่อความชัดเจน เราใช้คำว่า IdP เพื่อแสดงว่ามันรับผิดชอบในการรับรองความถูกต้องของผู้ใช้และการจัดการเอกลักษณ์

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

อีกครั้ง นี่เป็นกระบวนการที่ง่ายที่สุดที่สามารถทำได้และมีรายละเอียดมากกว่านี้ใต้เครื่อง ให้เราข้ามไปสู่ส่วนถัดไปก่อนที่จะเกิดภาระข้อมูลเกินกำลัง

ประเภทของแอปพลิเคชัน#

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

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

โดยมุมมองนี้ ให้เราดูว่า OAuth 2.0 และ OpenID Connect สามารถใช้ในประเภทของแอปพลิเคชันที่แตกต่างกันได้อย่างไร

"แอปพลิเคชัน" และ "ลูกค้า" สามารถใช้แทนกันได้ในบริบทของโพสต์นี้

แอปพลิเคชันเว็บที่ทำงานบนเซิร์ฟเวอร์#

แอปพลิเคชันทำงานบนเซิร์ฟเวอร์และให้บริการหน้า HTML แก่ผู้ใช้ เฟรมเวิร์กเว็บยอดนิยมหลายตัว เช่น Express.js, Django, และ Ruby on Rails เข้าข่ายนี้; และเฟรมเวิร์กที่เป็นส่วนหลังสำหรับส่วนหน้า (BFF) เช่น Next.js และ Nuxt.js ก็รวมอยู่ในนี้เช่นกัน แอปพลิเคชันเหล่านี้มีลักษณะดังนี้:

1. เนื่องจากเซิร์ฟเวอร์อนุญาตให้เข้าถึงภายในอย่างเดียว (ไม่มีทางที่ผู้ใช้สาธารณะจะเห็นโค้ดหรือข้อมูลเฉพาะตัวของเซิร์ฟเวอร์) มันจึงถือเป็นลูกค้าเอกชน
2. กระบวนการรับรองผู้ใช้ทั่วไปเหมือนกับที่เราพูดถึงในส่วน "OpenID Connect"
3. แอปพลิเคชันสามารถใช้โทเค็น ID ที่ออกโดยผู้ให้บริการเอกลักษณ์ (เช่น ผู้ให้บริการ OpenID Connect) เพื่อตรวจสอบผู้ใช้และแสดงเนื้อหาเฉพาะผู้ใช้
4. เพื่อความปลอดภัยของแอปพลิเคชัน แอปพลิเคชันมักจะใช้ การดำเนินการแบบมีโค้ดการอนุญาต สำหรับการรับรองผู้ใช้และการรับโทเค็น

ในขณะเดียวกัน แอปพลิเคชันอาจต้องเข้าถึงบริการ API ภายในอื่น ๆ ในสถาปัตยกรรมไมโครเซดะม หรือนั่นคือแอปพลิเคชันโมโนลิทที่ต้องการการควบคุมการเข้าถึงสำหรับส่วนต่าง ๆ ของแอปพลิเคชัน เราจะพูดถึงนี้ในส่วน "ป้องกัน API ของคุณ"

แอปพลิเคชันหน้าเดียว (SPAs)#

แอปพลิเคชันทำงานในเบราว์เซอร์ของผู้ใช้และสื่อสารกับเซิร์ฟเวอร์ผ่าน API React, Angular, และ Vue.js เป็นเฟรมเวิร์กยอดนิยมในการสร้าง SPAs แอปพลิเคชันเหล่านี้มีลักษณะดังนี้:

1. เนื่องจากโค้ดของแอปพลิเคชันนี้สามารถมองเห็นได้โดยสาธารณะ มันถือเป็นลูกค้าสาธารณะ
2. กระบวนการรับรองผู้ใช้ทั่วไปเหมือนกับที่เราพูดถึงในส่วน "OpenID Connect"
3. แอปพลิเคชันสามารถใช้โทเค็น ID ที่ออกโดยผู้ให้บริการเอกลักษณ์ (เช่น ผู้ให้บริการ OpenID Connect) เพื่อตรวจสอบผู้ใช้และแสดงเนื้อหาเฉพาะผู้ใช้
4. เพื่อความปลอดภัยของแอปพลิเคชัน แอปพลิเคชันมักจะใช้ การดำเนินการแบบมีโค้ดการอนุญาตพร้อม PKCE (Proof Key for Code Exchange) สำหรับการรับรองผู้ใช้และการรับโทเค็น

โดยปกติ SPAs จำเป็นต้องเข้าถึงบริการ API อื่น ๆ สำหรับการดึงและการอัพเดทข้อมูล เราจะพูดถึงนี้ในส่วน "ป้องกัน API ของคุณ"

แอปพลิเคชันมือถือ#

แอปพลิเคชันทำงานบนอุปกรณ์มือถือ (iOS, Android, ฯลฯ) และสื่อสารกับเซิร์ฟเวอร์ผ่าน API ในหลายกรณี แอปพลิเคชันเหล่านี้มีลักษณะเหมือนกับ SPAs

แอปพลิเคชันระหว่างเครื่องถึงเครื่อง (M2M)#

แอปพลิเคชันระหว่างเครื่องถึงเครื่อง เป็น ลูกค้า ที่ทำงานบนเซิร์ฟเวอร์ (เครื่อง) และสื่อสารกับเซิร์ฟเวอร์อื่น ๆ แอปพลิเคชันเหล่านี้มีลักษณะดังนี้:

1. เหมือนกับแอปพลิเคชันเว็บที่ทำงานบนเซิร์ฟเวอร์ แอปพลิเคชัน M2M เป็นลูกค้าเอกชน
2. แอปพลิเคชันอาจไม่จำเป็นต้องระบุผู้ใช้ ในทางกลับกัน อาจต้องการรับรองความถูกต้องของตนเองเพื่อเข้าถึงบริการอื่น ๆ
3. แอปพลิเคชันสามารถใช้โทเค็นการเข้าถึงที่ออกโดยผู้ให้บริการเอกลักษณ์ (เช่น ผู้ให้บริการ OAuth 2.0) เพื่อเข้าถึงบริการอื่น ๆ
4. เพื่อความปลอดภัยของแอปพลิเคชัน แอปพลิเคชันมักจะใช้ การดำเนินการแบบข้อมูลส่วนตัวของลูกค้าลูกค้า เพื่อรับโทเค็นการเข้าถึง

เมื่อเข้าถึงบริการอื่น ๆ แอปพลิเคชันอาจจำเป็นต้องระบุโทเค็นการเข้าถึงในส่วนหัวของคำขอ เราจะพูดถึงนี้ในส่วน "ป้องกัน API ของคุณ"

แอปพลิเคชันที่ทำงานบนอุปกรณ์ IoT#

แอปพลิเคชันทำงานบนอุปกรณ์ IoT (เช่น สมาร์ทโฮม, IoT, ฯลฯ) และสื่อสารกับเซิร์ฟเวอร์ผ่าน API แอปพลิเคชันเหล่านี้มีลักษณะดังนี้:

1. ขึ้นอยู่กับความสามารถของอุปกรณ์ มันอาจเป็นลูกค้าสาธารณะหรือเอกชน
2. การดำเนินการรับรองอาจแตกต่างจากที่เราพูดถึงในส่วน "OpenID Connect" ขึ้นอยู่กับความสามารถของอุปกรณ์ เช่น บางอุปกรณ์อาจไม่มีหน้าจอให้ผู้ใช้กรอกข้อมูลรับรอง
3. หากอุปกรณ์ไม่จำเป็นต้องระบุผู้ใช้ มันอาจไม่จำเป็นต้องใช้โทเค็น ID หรือจุดสิ้นสุดผู้ใช้ ในทางกลับกัน มันอาจสามารถถือเป็นแอปพลิเคชันระหว่างเครื่องถึงเครื่อง (M2M)
4. เพื่อความปลอดภัยของแอปพลิเคชัน อาจใช้ การดำเนินการแบบมีโค้ดการอนุญาตพร้อม PKCE (Proof Key for Code Exchange) เพื่อรับรองและการรับโทเค็นหรือ การดำเนินการแบบข้อมูลส่วนตัวของลูกค้า เพื่อรับโทเค็นการเข้าถึง

เมื่อสื่อสารกับเซิร์ฟเวอร์ อุปกรณ์อาจจำเป็นต้องระบุโทเค็นการเข้าถึงในส่วนหัวของคำขอ เราจะพูดถึงนี้ในส่วน "ป้องกัน API ของคุณ"

ป้องกัน API ของคุณ#

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

ที่นี่คือที่การอนุญาตเข้ามามีบทบาท จำไว้ว่าการอนุญาต OAuth 2.0 เป็นกรอบการทำงานการอนุญาต และ OpenID Connect เป็นชั้นบ่งชี้ที่ทำงานบน OAuth 2.0 ซึ่งหมายความว่าคุณสามารถใช้ OAuth 2.0 ได้เมื่อ OpenID Connect เข้ามามีบทบาทแล้ว

ลองนึกถึงตัวอย่างที่เราใช้ในส่วน "OAuth 2.0": MyApp ต้องการเข้าถึง Google Drive ของผู้ใช้ มันไม่เหมาะสมที่จะให้ MyApp เข้าถึงไฟล์ทั้งหมดของผู้ใช้ใน Google Drive แทนที่นั้น MyApp ต้องระบุให้ชัดเจนว่าต้องการเข้าถึงอะไร (เช่น การเข้าถึงแบบอ่านอย่างเดียวในโฟลเดอร์เฉพาะ) ในแง่ของ OAuth 2.0 นี่เรียกว่า ขอบเขต

คุณอาจเห็นคำว่า "การอนุญาต" ถูกใช้แทนคำว่า "ขอบเขต" ในบริบทของ OAuth 2.0 เนื่องจากบางครั้ง "ขอบเขต" อาจสับสนสำหรับผู้ใช้ที่ไม่ใช่ด้านเทคนิค

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

แน่นอน เราสามารใช้ Google Drive แทนที่ด้วยบริการ API ของเราเองได้ ตัวอย่างเช่น MyApp จำเป็นต้องเข้าถึง OrderService เพื่อดึงประวัติการสั่งซื้อของผู้ใช้ ครั้งนี้ เนื่องจากการรับรองผู้ใช้ได้ดำเนินการโดยผู้ให้บริการเอกลักษณ์และทั้ง MyApp กับ OrderService อยู่ภายใต้การควบคุมของเราแล้ว เราสามารถข้ามการขออนุญาตผู้ใช้ได้; MyApp สามารถส่งคำขอไปยัง OrderService พร้อมโทเค็นการเข้าถึงที่ออกโดยผู้ให้บริการเอกลักษณ์ได้โดยตรง

โทเค็นการเข้าถึงอาจมีขอบเขต read:order ขอบเขต เพื่อแสดงว่าผู้ใช้สามารถอ่านประวัติการสั่งซื้อของตัวเองได้

ตอนนี้ สมมติว่าผู้ใช้ป้อน URL ของหน้าผู้ดูแลในเบราว์เซอร์โดยไม่ได้ตั้งใจ เนื่องจากผู้ใช้ไม่ได้เป็นผู้ดูแล ไม่มีขอบเขต admin ในโทเค็นการเข้าถึง OrderService จะปฏิเสธคำขอและคืนข้อความข้อผิดพลาด

ในกรณีนี้ OrderService อาจคืนสถานะโค้ด 403 Forbidden เพื่อแสดงว่าผู้ใช้ไม่มีสิทธิ์เข้าถึงหน้าแอดมิน

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

การออกแบบการอนุญาต#

เราสามารถเห็นสองสิ่งสำคัญที่ต้องพิจารณาเมื่อออกแบบ การอนุญาต เพื่อป้องกันบริการ API ของคุณ:

1. ขอบเขต: กำหนดสิ่งที่ลูกค้าสามารถเข้าถึงได้ ขอบเขตอาจละเอียดมาก (เช่น read:order, write:order) หรือทั่วไปมากกว่า (เช่น order) ขึ้นอยู่กับความต้องการของคุณ
2. การควบคุมการเข้าถึง: กำหนดว่าใครบ้างที่จะมีขอบเขตเฉพาะ ตัวอย่างเช่น มีเพียงผู้ดูแลระบบเท่านั้นที่สามารถมีขอบเขต admin

เกี่ยวกับ การควบคุมการเข้าถึง วิธีที่นิยมบางอย่าง ได้แก่:

• การควบคุมการเข้าถึงตามบทบาท (RBAC): กำหนดบทบาทให้กับผู้ใช้และกำหนดบทบาทใดที่สามารถเข้าถึงทรัพยากรอะไรได้ ตัวอย่างเช่น บทบาทผู้ดูแลระบบสามารถเข้าถึงหน้าแอดมิน
• การควบคุมการเข้าถึงตามคุณลักษณะ (ABAC): กำหนดนโยบายตามคุณลักษณะ (เช่น แผนกของผู้ใช้, ตำแหน่งที่ตั้ง, ฯลฯ) และทำการตัดสินใจการควบคุมการเข้าถึงตามคุณลักษณะเหล่านี้ ตัวอย่างเช่น ผู้ใช้จากแผนก "วิศวกรรม" สามารถเข้าถึงหน้าแผนกวิศวกรรมได้

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

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการควบคุมการเข้าถึง คุณสามารถดู RBAC และ ABAC: โมเดลการควบคุมการเข้าถึงที่คุณควรรู้

โทเค็นการเข้าถึง#

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

ลองดูที่ตัวอย่างของ Google Drive ในรูปแบบนี้และสมมติว่าเราใช้การดำเนินการแบบมีโค้ดการอนุญาต:

มีขั้นตอนที่สำคัญบางประการในกระบวนการออกโทเค็นการเข้าถึง:

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

ตัวอย่างข้างต้นถือว่าเซิร์ฟเวอร์การอนุญาต (ผู้ให้บริการเอกลักษณ์) และเซิร์ฟเวอร์ทรัพยากรเป็นตัวเดียวกัน (Google) ถ้าเป็นการแยกกัน ใช้ตัวอย่างของ MyApp และ OrderService กระบวนการจะเป็นเช่นนี้:

ในกระบวนการนี้ เซิร์ฟเวอร์การอนุญาต (IdP) ออกทั้งโทเค็น ID และโทเค็นการเข้าถึงให้กับ MyApp (ขั้นตอนที่ 8) โทเค็น ID ใช้เพื่อตรวจสอบผู้ใช้ และโทเค็นการเข้าถึงใช้ในการเข้าถึงบริการอื่น ๆ เช่น OrderService เนื่องจากทั้ง MyApp และ OrderService เป็นบริการของบุคคลเดียวกัน โดยทั่วไปพวกเขาไม่ขออนุญาตจากผู้ใช้; พวกเขาขึ้นอยู่กับการควบคุมการเข้าถึงในผู้ให้บริการเอกลักษณ์เพื่อตัดสินใจว่าผู้ใช้สามารถเข้าถึงทรัพยากรได้หรือไม่ (เช่น โทเค็นการเข้าถึงมีขอบเขตที่จำเป็นหรือไม่)

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

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

โทเค็นการเข้าถูกเข้ารหัสโดยปกติเป็น JSON Web Tokens (JWT) หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับ JWT คุณสามารถดู What is JSON Web Token (JWT)?

ตัวบ่งชี้ทรัพยากร#

OAuth 2.0 นำเสนอแนวคิดของขอบเขตเพื่อการควบคุมการเข้าถึง อย่างไรก็ตาม คุณอาจตระหนักได้อย่างรวดเร็วว่าขอบเขตไม่เพียงพอ:

• OpenID Connect กำหนดชุดขอบเขตมาตรฐานเช่น openid, offline_access และ profile บางครั้งการผสมขอบเขตที่เป็นมาตรฐานเหล่านี้กับขอบเขตที่คุณกำหนดเองอาจสับสนได้
• คุณอาจมีบริการ API หลายตัวที่แชร์ชื่อขอบเขตเหมือนกันแต่มีความหมายต่างกัน

การแก้ไขปัญหาทั่วไปคือการเพิ่มคำหน้านาม (หรือคำต่อท้าย) ให้กับชื่อขอบเขตเพื่อระบุทรัพยากร (บริการ API) ตัวอย่างเช่น read:order และ read:product ชัดเจนกว่า read และ read ส่วนขยายของ OAuth 2.0 RFC 8707 แนะนำพารามิเตอร์ใหม่ resource เพื่อระบุ เซิร์ฟเวอร์ทรัพยากร ที่ลูกค้าต้องการเข้าถึง

ในความเป็นจริง บริการ API มักถูกนิยามโดย URL ดังนั้นมันจึงเหอะที่จะใช้ URL เป็น ตัวบ่งชี้ทรัพยากร ตัวอย่างเช่น API ของ OrderService สามารถแสดงเป็น:

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

ในเชิงสรุป พารามิเตอร์ resource สามารถใช้ในการขออนุญาตและโทเค็นการเข้าถึงเพื่อระบุทรัพยากรที่เลือกเข้าถึงโดยลูกค้า

ไม่มีการจำกัดการเข้าถึงของตัวบ่งชี้ทรัพยากร กล่าวคือ ตัวบ่งชี้ทรัพยากรไม่จำเป็นต้องเป็น URL จริงที่ชี้ไปที่บริการ API แทบที่ชื่อ "ตัวบ่งชี้ทรัพยากร" แสดงบทบาทของอักษรนี้ในกระบวนการอนุญาต คุณสามารถใช้ URL เสมือนเพื่อนำเสนอทรัพยากรที่ต้องการป้องกันได้ ตัวอย่างเช่น คุณสามารถนิยาม URL เสมือน https://api.example.com/admin ในแอปพลิเคชันโมโนลิทของคุณเพื่อนำเสนอทรัพยากรที่เพียงแค่เล่าเรื่องที่จะเข้าถึงได้เท่านั้น

รวบรวมทั้งหมดเข้าด้วยกัน#

ณ จุดนี้ เราได้ครอบคลุมพื้นฐานของ OAuth 2.0 และ OpenID Connect และวิธีการใช้ในประเภทและฉากที่ต่างกันของแอปพลิเคชัน แม้ว่าเราจะพูดถึงแยกกัน คุณสามารถรวมพวกมันตามความต้องการของธุรกิจของคุณได้ สถาปัตยกรรมรวมสามารถง่ายได้ดังนี้:

หรือซับซ้อนขึ้นเล็กน้อย:

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

หมายเหตุปิด#

สำหรับแอปพลิเคชันคลาวด์ยุคใหม่ ผู้ให้บริการเอกลักษณ์ (หรือเซิร์ฟเวอร์การอนุญาต) เป็นศูนย์กลางสำหรับการรับรองผู้ใช้ authentication, การจัดการเอกลักษณ์ identity management, และการควบคุมการเข้าถึง access control แม้ว่าเราจะได้พูดถึงแนวคิดหลายอย่างในโพสต์นี้ แต่ยังมีรายละเอียดมากมายที่ต้องพิจารณาเมื่อดำเนินการระบบเช่นนี้ หากคุณสนใจในเรื่องนี้ คุณสามารถเรียกดูบทความเพิ่มเติมได้ในบล็อกของเรา