Cloudflare OAuth สำหรับลูกค้าทุกคน
(blog.cloudflare.com)- Cloudflare เปิดให้ลูกค้าสามารถสร้างแอป self-managed OAuth ได้ด้วยตนเอง ทำให้สามารถให้สิทธิ์เข้าถึง Cloudflare API ผ่านกระบวนการมอบสิทธิ์แบบมาตรฐานได้
- ก่อนหน้านี้มีเพียงพาร์ตเนอร์บางรายที่ onboarding แบบแมนนวลเท่านั้นที่ใช้ OAuth ของบุคคลที่สามได้ และนักพัฒนาที่สร้างการเชื่อมต่อเองต้องพึ่งพา API token ซึ่งไม่เหมาะกับโฟลว์แอปแบบมอบสิทธิ์
- เพื่อเปิดใช้งานอย่างเต็มรูปแบบ Cloudflare ได้ปรับปรุงหน้าจอขอความยินยอม การเพิกถอนสิทธิ์ และการแสดงความเป็นเจ้าของแอป พร้อมอัปเกรดเอนจิน OAuth Hydra จาก 1.X ไปเป็น 2.X แบบค่อยเป็นค่อยไป
- ระหว่างการอัปเกรด พบปัญหาเช่น schema migration, ข้อผิดพลาดในการต่ออายุโทเค็น, ความเสี่ยงที่เหตุการณ์เพิกถอนจะสูญหาย, และการเพิ่มขึ้นของ 403 ซึ่งรับมือด้วยการสร้างดัชนีพร้อมกัน คิวเล่นซ้ำเหตุการณ์เพิกถอน และการกู้คืนข้อมูล
- หลังอัปเกรด API P95 ลดลงจาก 185ms เหลือ 101ms หรือ 45% และการใช้ CPU ก็ลดจาก 1.07 คอร์เหลือ 0.67 คอร์ ทำให้รากฐานสำหรับการให้บริการ OAuth สาธารณะมีเสถียรภาพมากขึ้น
การขยายการเปิดให้ใช้งาน Cloudflare OAuth
- Cloudflare สนับสนุนการสร้างระบบอัตโนมัติ, CI/CD และการเชื่อมต่อโครงสร้างพื้นฐานผ่าน platform API มาอย่างต่อเนื่อง และครั้งนี้ได้เปิด self-managed OAuth ให้ลูกค้าทุกคนใช้งาน
- Cloudflare OAuth เองไม่ใช่ฟีเจอร์ใหม่ เพราะถูกใช้มาก่อนแล้วในอินทิเกรชันของพาร์ตเนอร์อย่าง Wrangler และ PlanetScale
- อย่างไรก็ตาม OAuth ของบุคคลที่สามแบบเดิมเปิดให้ใช้เฉพาะอินทิเกรชันจำนวนน้อยที่ต้อง onboarding แบบแมนนวล จึงยังไม่เปิดกว้างต่อ ecosystem นักพัฒนาในวงกว้าง
- นักพัฒนาที่สร้างอินทิเกรชันของตัวเองต้องพึ่งพา API token ซึ่งจัดการยากและไม่สอดคล้องกับโฟลว์ของแอปแบบมอบสิทธิ์จำนวนมาก
- เมื่อใช้ self-managed OAuth นักพัฒนาจะสามารถมอบประสบการณ์ OAuth มาตรฐานที่ให้ลูกค้าอนุมัติการเข้าถึงแบบกำหนดขอบเขตได้ด้วยตนเอง
- กรณีใช้งานหลักคือ SaaS integration, แพลตฟอร์มนักพัฒนาภายใน และเครื่องมือ agent
- ผู้ใช้จะได้ความยินยอมที่ชัดเจนขึ้น เพิกถอนได้ง่ายขึ้น และควบคุมสิทธิ์ของแอปพลิเคชันได้มากขึ้น
การเสริมฐานความปลอดภัยเพื่อเปิดใช้งานเต็มรูปแบบ
- โซลูชัน OAuth ระยะแรกเพียงพอสำหรับพาร์ตเนอร์ที่มีการดูแลอยู่ไม่กี่ราย แต่ยังไม่สมบูรณ์พอในด้านโมเดลสิทธิ์ ประสบการณ์ความยินยอม และการลดการใช้งานในทางที่ผิด สำหรับการเปิดให้ลูกค้าทั้งหมดใช้งาน
- เมื่อต้นปีนี้ Cloudflare ได้ปรับปรุงประสบการณ์ความยินยอม ให้แสดงชัดเจนขึ้นว่าแอปใดกำลังขอเข้าถึง และจะได้รับสิทธิ์อะไรบ้าง
- ในแดชบอร์ดได้เพิ่ม ฟังก์ชันเพิกถอน เพื่อให้นักพัฒนาควบคุมได้ง่ายว่ามีแอปใดบ้างที่เข้าถึงข้อมูลได้
- เพื่อลดการโจมตีแบบ OAuth phishing จึงทำให้ ความเป็นเจ้าของแอป มองเห็นได้ชัดเจนยิ่งขึ้น
- การเปิด self-managed OAuth ให้ลูกค้าทุกคนใช้งานจำเป็นต้องอัปเกรดเอนจิน OAuth โดยยังคงความเสถียรและความปลอดภัยของข้อมูล พร้อมลดการรบกวนผู้ใช้ให้มากที่สุด
การเตรียมอัปเกรด Hydra 1.X
- Cloudflare ใช้เอนจิน OAuth แบบโอเพนซอร์ส Hydra เป็นเอนจินภายในของ Cloudflare OAuth มานานแล้ว
- เมื่อแพลตฟอร์มนักพัฒนาเติบโตขึ้นและ workflow ของ agent เพิ่มมากขึ้น ก็จำเป็นต้องมีการอัปเกรดครั้งใหญ่เพื่อรองรับฟีเจอร์ใหม่และการปรับปรุงประสิทธิภาพ
- แทนที่จะอัปเกรดใหญ่ครั้งเดียว Cloudflare เลือกแนวทางแบบเป็นลำดับ โดยย้ายไปยัง 1.X รุ่นล่าสุดก่อน ประเมินพฤติกรรมและประสิทธิภาพ แล้วจึงค่อยไปอัปเกรด 2.X
- การอัปเกรด 1.X เพียงอย่างเดียวก็มีความเป็นไปได้ที่จะกระทบลูกค้า
- ฐานข้อมูลของ Hydra สร้างดัชนีโดยใช้ exclusive lock กับตารางสำคัญ
- มีการเพิ่มคอลัมน์ในตารางสำคัญ และย้ายคอลัมน์อื่นไปยังตารางใหม่
- SDK ของ Hydra เวอร์ชันที่ใช้อยู่ทำ
SELECT *ซึ่งอาจทำให้เกิดปัญหา deserialization เมื่อ schema เปลี่ยน
- เพื่อป้องกันผลกระทบต่อผู้ใช้ Cloudflare จึงเขียน SQL migration ใหม่ให้ใช้วิธีอย่าง
CREATE INDEX CONCURRENTLYและสร้าง Hydra เวอร์ชัน custom ที่เลือก คอลัมน์แบบระบุชัดเจน แทนSELECT *
กลยุทธ์การอัปเกรด Hydra 2.X
- การอัปเกรด 2.X มีการเปลี่ยนแปลง schema ขนาดใหญ่ จึงไม่เหมาะกับ in-place upgrade และ Cloudflare เลือกใช้กลยุทธ์ blue-green
- การสลับไปใช้เวอร์ชันใหม่แบบง่าย ๆ ไม่เพียงพอ
- การอัปเกรดและ migration ใช้เวลาหลายชั่วโมง
- ระหว่างนั้นระบบยังต้องทำงานได้อย่างถูกต้องต่อไป
- ทางเลือก blue-green แบบแรกคือปิดการเขียนลงฐานข้อมูลเพื่อบล็อกการอนุมัติใหม่
- การเขียนใหม่ระหว่างการสลับจะไม่สูญหาย
- ผู้ใช้ที่ไม่มี credential ที่ยังใช้งานได้อยู่จะไม่สามารถใช้แอป OAuth เดิมได้
- ผู้ใช้จะไม่สามารถ เพิกถอน การเข้าถึงของแอปพลิเคชันได้ระหว่างการอัปเกรด
- กลยุทธ์สุดท้ายคือคงการเขียนลงฐานข้อมูลไว้ แต่ยอมรับความเสี่ยงของการสูญเสียการเขียนบางส่วน พร้อมลดความเสี่ยงนั้นให้มากที่สุด
- เพื่อให้มีการเขียนโทเค็นใหม่น้อยลง จึงขยายเวลาหมดอายุของโทเค็นออกไปเป็นหลายชั่วโมง
- แอปที่ได้รับโทเค็นก่อนอัปเกรดสามารถใช้งานต่อได้โดยไม่ต้องต่ออายุใหม่
- การสูญหายของเหตุการณ์เพิกถอนถูกป้องกันด้วยระบบคิวที่ใช้ Cloudflare Queues
- เมื่อเกิดเหตุการณ์เพิกถอน จะบันทึกข้อมูลนั้นลงคิว
- หลังสลับไปยังฐานข้อมูลของเวอร์ชัน green แล้ว จึงล้างคิวเพื่อเล่นซ้ำการเพิกถอนที่เกิดขึ้นระหว่างช่วงอัปเกรด
- หากขั้นตอนนี้ล้มเหลว การเข้าถึงของแอปที่ผู้ใช้เพิกถอนไปแล้วอาจถูกกู้คืนกลับมาโดยไม่ตั้งใจ
การอัปเกรด 1.X และปัญหาการต่ออายุโทเค็น
- การอัปเกรดครั้งแรกไปยัง 1.X รุ่นล่าสุดดำเนินไปได้ดีในเชิงปฏิบัติการโดยแทบไม่มีปัญหาใหญ่
- database migration แบบ custom ทำงานได้เร็วกว่าที่คาด และไม่ส่งผลกระทบต่อผู้ใช้
- เนื่องจากเวอร์ชันเก่าไม่สามารถ introspect โทเค็นที่สร้างจากเวอร์ชันใหม่ได้ จึงจำเป็นต้องทำ hard cutover
- หลัง cutover จำนวนข้อผิดพลาดของ refresh token ที่ไม่เคยเห็นมาก่อนเพิ่มขึ้น
- สาเหตุมาจากพฤติกรรมการทำให้ refresh ไม่ถูกต้องที่เข้มงวดขึ้นในเวอร์ชันใหม่
- หาก refresh token ถูกใช้ซ้ำ Hydra จะทำให้ chain ทั้งหมดของ access token และ refresh token ใช้งานไม่ได้
- ไคลเอนต์อย่าง Wrangler และ MCP มีปริมาณคำขอสูง ทำให้การใช้ refresh token ซ้ำเพียงครั้งเดียวอาจทำให้ทั้งเซสชันใช้ไม่ได้
- Cloudflare จึงเพิ่มพฤติกรรม refresh token coalescing เข้าไปใน Worker ที่ทำหน้าที่ route ทราฟฟิก OAuth ไปยังปลายทางที่ถูกต้อง
- คำขอ refresh token จะถูกแคชชั่วคราวก่อนถึง Hydra
- เมื่อพบการ retry จะตอบกลับแบบตัดขั้นตอน โดยไม่ทำให้โทเค็นใช้ไม่ได้
- ใน Hydra 2.X มี
refresh token grace periodที่ตั้งค่าได้ ซึ่งอนุญาตให้ retry refresh token ได้ภายในช่วงเวลาหนึ่งโดยไม่ทำให้ทั้ง chain ใช้งานไม่ได้
การสลับไป 2.X และกระบวนการกู้คืน
- Cloudflare ไม่สามารถยอมรับการหยุดให้บริการหลายชั่วโมงที่กระทบผู้ใช้ได้ จึงดำเนินการอัปเกรดแบบ blue-green
- การสลับใช้งานจริงต้องทำมากกว่าแค่คัดลอกฐานข้อมูลและ deploy Hydra ตัวใหม่
- เปิดใช้งานคิวสำหรับจับและเล่นซ้ำเหตุการณ์เพิกถอน
- คัดลอกฐานข้อมูลและกู้คืนไปยังปลายทางใหม่
- ล้างข้อมูลเดิมที่ละเมิดข้อกำหนดของเวอร์ชันใหม่
- cutover พร้อมกันทั้งบริการ Hydra และระบบภายในหลักสองตัว
- ตรวจสอบและยืนยันผลหลัง cutover
- ช่วงเวลาอัปเกรดถูกเลือกให้เป็นเวลาที่ Hydra มี requests per second ต่ำที่สุด เพื่อลดการสูญเสียการเขียนโทเค็น
- migration ใน production ทำงานได้ดีบนฐานข้อมูลใหม่ นอกเหนือจากการปรับ timeout บางส่วน และใช้เวลาทำงานจริงประมาณ 3 ชั่วโมง
- ทันทีหลังสลับทราฟฟิก พบว่างานล้างข้อมูลของ authorization service ลบข้อมูล OAuth policy มากเกินไป
- บริการดังกล่าวพึ่งพา Hydra consent session API
- migration รายการหนึ่งของ Hydra ทำให้สถานะเซสชัน OAuth ที่ยังใช้งานได้บางส่วนเสียหาย และถูกมองว่าไม่ถูกต้อง
- ความไม่สอดคล้องกันระหว่าง Hydra กับ authorization service แสดงออกมาเป็น 403 ที่เพิ่มขึ้น
- Cloudflare บรรเทาปัญหาด้วยการกู้คืนข้อมูล และเริ่มปรับปรุงพฤติกรรมการ authorization ของ OAuth เพื่อลดการพึ่งพาข้อมูล policy แบบ static
- นอกจากนี้ยังรีบปล่อยการแก้ไขเล็ก ๆ สำหรับพฤติกรรมเฉพาะของไคลเอนต์บางรายด้วย
การปรับปรุงประสิทธิภาพหลังอัปเกรด
- หลังอัปเกรดเวอร์ชัน Hydra เสร็จสิ้น ทราฟฟิก OAuth ยังคงเสถียร และประสิทธิภาพกับความน่าเชื่อถือของระบบสำหรับลูกค้าก็ดีขึ้น
- รากฐานใหม่นี้เป็นพื้นฐานเดียวกับ OAuth API ใหม่ที่ผ่านการตรวจสอบแล้วใน staging และทำให้สามารถเปิดตัว self-managed OAuth ได้ในวันที่ 3 มิถุนายน
- ตัวเลขสำคัญที่สังเกตได้ระหว่าง database migration:
- แถวที่อัปเดต: 132.5M
- แถวที่แทรก: 114.7M
- ไบต์ชั่วคราว: 136.97GB
- transaction commit: 22.2k
- ตัวชี้วัดประสิทธิภาพเฉลี่ยของ Hydra โดยรวมดีขึ้นหลังอัปเกรด
- API P95: 185ms → 101ms, ลดลง 45%
- หน่วยความจำ RSS: 888MB → 763MB, ลดลง 14%
- Go heap alloc: 449MB → 271MB, ลดลง 40%
- Goroutines: 4015 → 3076, ลดลง 23%
- CPU: 1.07 คอร์ → 0.67 คอร์, ลดลง 37%
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ผมเป็นคนที่สร้าง Ory Hydra เห็นบล็อกโพสต์นี้กับคำอธิบายทางเทคนิคแล้วดีใจมาก ไม่เคยคิดเลยว่าซอฟต์แวร์นี้จะได้มาปกป้องบริษัทอินเทอร์เน็ตรายใหญ่ของโลก
ดีใจที่ เวอร์ชัน 2.x ทำงานได้ดีในสเกลนั้น และการใช้ CPU ก็ดูน้อยจนน่าเหลือเชื่อ
ถ้ามีปัญหาก็ยังมีเวอร์ชันเชิงพาณิชย์ที่เร็วกว่า ถ้าสนใจ OAuth, IAM, สิทธิ์แบบ ReBAC, API key และความปลอดภัยของเอเจนต์แบบโฮสต์เอง สามารถดูทั้งโอเพนซอร์สและผลิตภัณฑ์เชิงพาณิชย์ได้ที่ https://github.com/ory และ https://www.ory.com/
เมื่อก่อนผมเคยรัน identity server framework สำหรับ dotnet แบบ self-hosted และรองรับคำขอระดับหลายพันล้านครั้งต่อเดือน ที่สเกลนั้น OAuth และ OpenID Connect แทบจะเป็นปัญหาที่แก้กันจบแล้ว และภาระการดูแลรักษาก็ต่ำ
มันเป็นบริการแกนกลางขององค์กรและมีข้อกำหนดด้านคอมพลายแอนซ์เข้มมาก แต่ทีมที่ดูแลน่าจะมีแค่ราว 3 คน และตอนนี้ก็น่าจะยังทำงานได้ดีอยู่
ผมไม่เข้าใจว่าทำไมโปรโตคอลนี้ถึงสร้างความสับสนได้มากขนาดนั้น และวิศวกรจูเนียร์แทบทุกคนที่ผมเคยร่วมงานด้วยก็มักเข้าใจได้ยาก บล็อกของ Scott Brady https://www.scottbrady.io/ ช่วยเรื่องนี้ได้มาก
ดูเหมือนว่าเมื่อมีเรื่องการยืนยันตัวตน/การกำหนดสิทธิ์เข้ามา วิศวกรจะเกิด “ความกลัว” แบบดั้งเดิมขึ้นมา พวกเขาคุ้นเคยกับการแก้ปัญหา แต่การยืนยันตัวตน/การกำหนดสิทธิ์กลับแทรกเข้ามาเหมือนเป็นเงื่อนไขก่อนหน้าของการแก้ปัญหานั้น เลยสร้างภาระทางความคิด
Cloudflare ตามสไตล์เลย ทำงานได้ดีสำหรับทุกคนและราคาไม่แรงนัก แต่ผลจากข้อดีทั้งหมดนั้นก็คือมันเข้าไปอยู่ ศูนย์กลางของทุกสิ่ง
ผมคือ Grant เขียน โค้ดย้ายระบบ 2.0 ส่วนใหญ่ร่วมกับ Aeneas ขอบคุณทีม Cloudflare สำหรับโพสต์นี้
ผมสงสัยว่าส่วนที่บอกว่า “จากการสืบสวนพบว่ามีปัญหาในหนึ่งในการย้ายระบบของ Hydra ทำให้สถานะของบาง OAuth session ที่ยังใช้ได้เกิดความเสียหาย และผลคือการย้ายระบบทำเครื่องหมายว่า session เหล่านั้นเป็นโมฆะ” นั้น เป็นไฟล์ migration ตัวหนึ่งในโอเพนซอร์สหรือไม่
ตอนนี้ผมไม่ได้มีส่วนร่วมกับโปรเจ็กต์แล้ว แต่ก็อยากรู้ว่ามันถูกแก้ upstream แล้วหรือยัง
อย่างน้อยบริบททั้งหมดควรมีแผนเรื่อง โฟลว์การกำหนดสิทธิ์และการยืนยันตัวตน ภายใน ecosystem ของ Cloudflare รวมอยู่ด้วย เลยรู้สึกก้ำกึ่งพอสมควร และยังไม่มีตัวอย่างบน GitHub ด้วย
ถึงอย่างนั้น Cloudflare ก็เริ่มต้นมาถูกทางแล้ว แต่ถ้าเทียบกับชุดผลิตภัณฑ์ Ory ทั้งหมดที่เป็นฐานอยู่ ก็ยังต้องไปอีกไกล Ory Kratos จัดการเรื่องตัวตน การล็อกอิน การลงทะเบียน การกู้คืน การยืนยันตัวตนหลายปัจจัย ฯลฯ: https://github.com/ory
ผมคิดว่าขอบเขตทั้งหมดควรครอบคลุมถึงที่เก็บผู้ใช้, SAML และแผนโมเดลองค์กรแบบ multi-tenant ด้วย ตัวอย่างที่ดีคือ Zitadel https://github.com/zitadel ซึ่งมี UI สำหรับจัดการ multi-tenancy ขององค์กร, รองรับ OIDC/PKCE และยังพอผูก RBAC ได้บางส่วน
Supabase ก็มีระบบยืนยันตัวตนทั้งแบบ managed และโอเพนซอร์ส: https://github.com/supabase/auth
นอกเรื่องจาก “MCP ตายแล้ว และ Skills จะอยู่ตลอดไป” ผมกังวลว่าแผนผูก MCP และหมุนเวียนคีย์ในระบบเหล่านี้ทั้งหมดจะระเบิดเป็นเรื่องใหญ่ในไม่ช้า
OAuth 2.0 Dynamic Client Registration (RFC 7591): https://datatracker.ietf.org/doc/html/rfc7591
https://modelcontextprotocol.io/specification/2025-03-26/bas...
โดยเฉพาะในบริบทของ SaaS แบบ multi-tenant และ AI assistant แบบฝังตัว ผมอยากฟังความเห็นของคนอื่น
ในโฟลว์แบบ redirect ที่มักใช้ตอนเชื่อม MCP เข้ากับเอเจนต์ สเปกแทบไม่ได้อธิบายเลยว่าจะทำให้สิ่งนี้ปลอดภัยได้อย่างไร
คุณคงไม่อยากให้ใครก็ได้มาลงทะเบียน client พร้อม callback ตามอำเภอใจ นั่นคือการเปิดทางให้ phishing
ถ้ามีการลงทะเบียน client ด้วย callback URL อันตราย แล้วหลอกให้ผู้ใช้กดลิงก์เพื่อเริ่มโฟลว์นั้น ผู้ให้บริการตัวตนที่ถูกต้องตามกฎหมายก็จะยืนยันตัวตนผู้ใช้ แล้วส่ง access token ไปให้ผู้โจมตี
สเปกพูดถึง initial access token ที่ client ต้องได้มาก่อนการลงทะเบียนแบบผ่านๆ แต่รายละเอียดมีน้อยมาก และในสถานการณ์ที่ผู้ใช้ปลายทางทุกคนกลายเป็น client มันก็น่าจะใช้การได้ยาก
ในอุดมคติ ผมอยากกำหนด allowlist ของรูปแบบ redirect เพื่อจำกัดให้เหลือเป้าหมายอย่าง ChatGPT แต่สิ่งนี้เป็นพฤติกรรมที่ไม่เป็นมาตรฐาน เลยไม่ค่อยมี IAM vendor รีบทำ
ผมไม่เข้าใจว่าเจตนาตรงนี้คืออะไร ไม่มีโลกไหนที่มันจะจบสวย Cloudflare แทบจะเป็นผู้ให้บริการโครงสร้างพื้นฐานอยู่แล้ว และโมเดลสำหรับโครงสร้างพื้นฐานที่ให้ผู้ใช้คนหนึ่งมอบสิทธิ์ของบัญชีตัวเองให้ client บุคคลที่สามนั้นมี โอกาสถูกนำไปใช้ในทางที่ผิด สูงมาก
ถ้าบริษัทอย่าง AWS ไม่ทำ ก็น่าจะมีเหตุผลของมัน
ตัวอย่างเช่น IAM สามารถให้ GitHub Actions ที่รันจาก repository เฉพาะมีสิทธิ์อัปเดต Lambda ได้
OAuth และการยืนยันตัวตนระดับองค์กรอาจเป็นหนึ่งในสิ่งที่แย่ที่สุดที่มนุษย์สร้างขึ้นมา มันอาจเป็นส่วนที่ชวนสับสนและน่าหงุดหงิดที่สุดเวลาใช้งานคลาวด์
แม้แต่เครื่องมือ AI เองก็ใช้เวลาถึง 1 ปีแค่เพื่อจัดการ OAuth พื้นฐานบนระบบแบบ headless โดยไม่สมมติว่าสามารถเปิดเบราว์เซอร์ได้
ถ้าจะต้องดำดิ่งลงไปในโพรงกระต่ายของระบบยืนยันตัวตนสารพัดแบบจากผู้ให้บริการคลาวด์รายใหญ่ เช่น RBAC/IAM/workload identity/service account อย่างน้อยก็น่าจะยังเหลือวิธีที่เรียบง่ายสำหรับการใช้งานส่วนบุคคลไว้บ้าง
แค่มี API key อันเดียวก็พอแล้ว เก็บเป็นความลับไว้และเพิกถอนเมื่อจำเป็น ไม่จำเป็นต้องให้มีชั้นของความรกด้านการยืนยันตัวตนพันกันเป็นหมื่นชั้นบนทุกแพลตฟอร์ม
นี่คือฝันร้ายด้านความเป็นส่วนตัว
เราเพิ่งเปิดตัว Ory Talos(https://github.com/ory/talos) สำหรับ API key ด้วย เป็นทางเลือกที่ดีเมื่อ OAuth2 ดูเกินความจำเป็นสำหรับ use case นั้น
แน่นอนว่าก็มี use case และข้อกังวลด้านความปลอดภัยที่ทำให้การใช้ OAuth2 สมเหตุสมผล และสเปกอย่าง DPoP ก็ช่วยทำให้ flow แบบนี้ปลอดภัยขึ้นได้
use case ที่ยกมาในที่นี้ดูเหมาะกับ OAuth2 แต่ไม่ได้แปลว่าจะเหมาะกับทุกที่ ความซับซ้อนทำให้การรักษาความปลอดภัยของระบบยากขึ้น
ข้อดีของ OAuth2/OIDC คือมันไม่ได้ฝากความเชื่อใจไว้กับผู้ถือ API key แต่ฝากไว้กับตัวตนจริงที่ต้องการสิทธิ์เข้าถึง
ที่ว่าการยืนยันตัวตนมันยาก นั่นใช้กับระบบยืนยันตัวตนสำหรับผู้ใช้จำนวนมาก การยืนยันตัวตนสำหรับตัวเองนั้นง่ายมาก และจะยิ่งง่ายขึ้นถ้าใช้เฟรมเวิร์กที่ดีพอ
ถ้าไม่มั่นใจในการ implement ก็โยนให้โมเดลรุ่นใหม่ ๆ ตัวใดตัวหนึ่งดูได้เลย มันค่อนข้างเก่งในการหาปัญหาในระบบยืนยันตัวตนที่เรียบง่ายแบบนั้น
“Ory Enterprise License: ปลดล็อกฟีเจอร์ระดับองค์กรอย่าง CVE security SLA, SAML, องค์กร B2B, multi-tenancy และ scalability ที่ดีกว่า” [0]
หรือจะใช้ Keycloak ต่อไปก็ได้ ซึ่งให้ผลิตภัณฑ์ self-host แบบครบถ้วน [1]
[0]https://github.com/ory
[1]https://www.keycloak.org/
เหตุผลที่มีเวอร์ชันเชิงพาณิชย์ก็เพราะคำถามว่าคุณจะทำให้โอเพนซอร์สระดับโลกยั่งยืนทางการเงินได้อย่างไร การมีโมเดลธุรกิจที่ใช้ได้จริงสำหรับโอเพนซอร์สซึ่งรองรับบริษัทซอฟต์แวร์ที่ใหญ่ที่สุดในโลกนั้นไม่ใช่เรื่องแย่ แต่เป็นเรื่องดี
อนึ่ง IBM เองก็หาวิธีหารายได้จาก Keycloak ได้เหมือนกัน
โดยพื้นฐานแล้วนี่คือเรื่อง OAuth สำหรับการเข้าถึงบัญชี Cloudflare ไม่ใช่ฟีเจอร์แนว “ล็อกอิน” แบบทั่วไปที่ Cloudflare โฮสต์ให้สำหรับแอปแบบกำหนดเองของผู้ใช้
ผมคิดว่าตัวเองเข้าใจแล้วว่า OAuth คืออะไร แต่บทความนี้ทำให้งง ผมเข้าใจว่ามันเป็นโปรโตคอลมาตรฐานสำหรับให้ access key แยกตามไคลเอนต์
แล้ว self-managed OAuth ในที่นี้คืออะไร? ต้องอธิบายว่ามีการให้สิทธิ์เข้าถึงอะไร ใครคือไคลเอนต์ และใครคือพาร์ตเนอร์
มันคือการเปิดให้คุณโฮสต์ระบบ OAuth ของตัวเองเพื่ออนุมัติ/ปฏิเสธการเข้าถึงทรัพยากรของตัวเอง แทนที่จะต้องรอให้ Cloudflare อนุญาต Y ภายใต้เงื่อนไข X คุณก็สร้างตรรกะที่ต้องการเองได้
โดยแก่นแล้ว flow คือ “ล็อกอินเข้า Cloudflare” → Cloudflare ตรวจสอบว่ามีการใช้ self-managed OAuth → redirect ไปยัง OAuth ของคุณ → Cloudflare เชื่อถือคำตอบนั้น → ถ้าผู้ใช้อนุมัติ ก็อนุญาตให้เข้าถึงบัญชี