Cloudflare OAuth cho mọi khách hàng
(blog.cloudflare.com)- Cloudflare cho phép khách hàng tự tạo ứng dụng self-managed OAuth, giúp cung cấp quyền truy cập Cloudflare API theo luồng ủy quyền tiêu chuẩn
- Trước đây chỉ một số đối tác được onboard thủ công mới có thể dùng OAuth bên thứ ba, còn nhà phát triển tự xây dựng tích hợp phải phụ thuộc vào API token vốn không phù hợp với luồng ứng dụng ủy quyền
- Để mở công khai hoàn toàn, hãng đã cải thiện màn hình đồng ý, khả năng thu hồi và hiển thị quyền sở hữu ứng dụng, đồng thời nâng cấp dần OAuth engine Hydra từ 1.X lên 2.X
- Trong quá trình nâng cấp, họ gặp các vấn đề như migration schema, lỗi làm mới token, nguy cơ mất sự kiện thu hồi và số lượng 403 tăng, rồi xử lý bằng tạo chỉ mục đồng thời, hàng đợi phát lại thu hồi và khôi phục dữ liệu
- Sau nâng cấp, API P95 giảm từ 185ms xuống 101ms, tức 45% giảm, và mức dùng CPU cũng giảm từ 1.07 core xuống 0.67 core, giúp ổn định nền tảng vận hành OAuth công khai
Mở rộng phạm vi công khai của Cloudflare OAuth
- Cloudflare từ lâu đã cho phép xây dựng tự động hóa, CI/CD và tích hợp hạ tầng qua platform API, và lần này hãng mở self-managed OAuth cho toàn bộ khách hàng
- Bản thân Cloudflare OAuth không phải tính năng mới, vì trước đó đã được dùng trong các tích hợp đối tác như Wrangler và PlanetScale
- Tuy vậy, OAuth bên thứ ba trước đây chỉ được cung cấp cho một số ít tích hợp onboard thủ công, chưa mở ra cho hệ sinh thái nhà phát triển rộng hơn
- Các nhà phát triển tự xây dựng tích hợp buộc phải dựa vào API token, một cách làm khó quản lý và không phù hợp với nhiều luồng ứng dụng ủy quyền
- Với self-managed OAuth, nhà phát triển có thể cung cấp luồng OAuth tiêu chuẩn để khách hàng tự phê duyệt quyền truy cập theo phạm vi được chỉ định
- Các trường hợp sử dụng chính gồm tích hợp SaaS, nền tảng nhà phát triển nội bộ và công cụ agent
- Người dùng có được sự đồng ý rõ ràng hơn, khả năng thu hồi dễ dàng hơn và kiểm soát tốt hơn đối với quyền của ứng dụng
Củng cố nền tảng bảo mật để mở công khai hoàn toàn
- Giải pháp OAuth ban đầu đủ dùng cho một số đối tác được quản lý, nhưng chưa đủ trưởng thành về mô hình quyền hạn, trải nghiệm đồng ý và cách giảm thiểu lạm dụng để mở cho toàn bộ khách hàng
- Đầu năm nay, Cloudflare đã cải thiện trải nghiệm đồng ý để hiển thị rõ hơn ứng dụng nào đang yêu cầu quyền truy cập và sẽ nhận những quyền gì
- Trên dashboard, hãng bổ sung chức năng thu hồi để nhà phát triển dễ kiểm soát ứng dụng nào có thể truy cập dữ liệu
- Để giảm các cuộc tấn công phishing OAuth, Cloudflare cũng làm cho quyền sở hữu ứng dụng hiển thị rõ ràng hơn
- Để mở self-managed OAuth cho mọi khách hàng, cần nâng cấp OAuth engine trong khi vẫn giữ ổn định dữ liệu và bảo mật, đồng thời giảm tối đa gián đoạn cho người dùng
Chuẩn bị nâng cấp Hydra 1.X
- Cloudflare từ lâu đã dùng OAuth engine mã nguồn mở Hydra làm engine nội bộ cho Cloudflare OAuth
- Khi nền tảng nhà phát triển phát triển và workflow agent tăng lên, một đợt nâng cấp lớn để có tính năng mới và cải thiện hiệu năng trở nên cần thiết
- Thay vì nâng cấp lớn một lần, hãng chọn cách tuần tự: chuyển trước lên bản 1.X mới nhất, đánh giá thay đổi về hành vi và hiệu năng, rồi mới tiếp tục lên 2.X
- Chỉ riêng nâng cấp 1.X cũng đã có khả năng ảnh hưởng đến khách hàng
- Cơ sở dữ liệu Hydra tạo chỉ mục theo cách giữ khóa độc quyền trên các bảng quan trọng
- Nó thêm cột vào các bảng quan trọng và chuyển các cột khác sang bảng mới
- SDK của phiên bản Hydra đang dùng thực hiện
SELECT *, nên khi schema thay đổi có thể phát sinh vấn đề deserialize
- Để tránh ảnh hưởng đến người dùng, Cloudflare viết lại migration SQL theo cách như
CREATE INDEX CONCURRENTLY, và tạo một bản Hydra tùy biến chọn các cột tường minh thay vìSELECT *
Chiến lược nâng cấp Hydra 2.X
- Việc nâng cấp 2.X có quy mô thay đổi schema lớn nên không phù hợp với in-place upgrade, và Cloudflare chọn chiến lược blue-green
- Chỉ đơn giản chuyển công tắc sang phiên bản mới là không đủ
- Quá trình nâng cấp và migration mất nhiều giờ
- Trong khoảng thời gian đó, hệ thống vẫn phải tiếp tục hoạt động chính xác
- Phương án blue-green đầu tiên là chặn ghi vào cơ sở dữ liệu để ngăn cấp quyền mới
- Trong lúc chuyển đổi, các lần ghi mới sẽ không bị mất
- Người dùng chưa có thông tin xác thực hợp lệ sẽ không thể dùng các ứng dụng OAuth hiện có
- Người dùng cũng không thể thu hồi quyền truy cập ứng dụng trong lúc nâng cấp
- Chiến lược cuối cùng là vẫn duy trì ghi vào cơ sở dữ liệu nhưng chấp nhận một phần mất ghi và giảm thiểu rủi ro đó
- Để giảm số lần ghi token mới, họ kéo dài thời gian hết hạn token lên vài giờ
- Ứng dụng đã nhận token trước nâng cấp có thể tiếp tục dùng mà không cần làm mới ngay
- Nguy cơ mất sự kiện thu hồi được ngăn chặn bằng hệ thống hàng đợi dựa trên Cloudflare Queues
- Khi có sự kiện thu hồi, thông tin đó được ghi vào hàng đợi
- Sau khi chuyển sang cơ sở dữ liệu phiên bản green, hàng đợi được xả để phát lại các lần thu hồi diễn ra trong cửa sổ nâng cấp
- Nếu xử lý này thất bại, quyền truy cập của các ứng dụng đã bị người dùng thu hồi có thể vô tình được khôi phục
Nâng cấp 1.X và vấn đề làm mới token
- Lần nâng cấp đầu tiên lên bản 1.X mới nhất diễn ra mà không có vấn đề lớn về mặt vận hành
- Migration cơ sở dữ liệu tùy biến chạy nhanh hơn dự kiến và không ảnh hưởng người dùng
- Vì phiên bản cũ không thể introspect token được tạo bởi phiên bản mới, nên cần một hard cutover
- Sau khi cutover, lỗi refresh token trước đây không thấy bắt đầu tăng lên
- Nguyên nhân là do hành vi vô hiệu hóa refresh nghiêm ngặt hơn của phiên bản mới
- Nếu refresh token bị tái sử dụng, Hydra sẽ vô hiệu toàn bộ chuỗi access token và refresh token
- Các client Wrangler và MCP có lưu lượng yêu cầu cao, nên chỉ một lần tái sử dụng refresh token cũng có thể làm vô hiệu cả phiên
- Cloudflare đã thêm hành vi refresh token coalescing vào Worker dùng để định tuyến lưu lượng OAuth đến đúng đích
- Các yêu cầu refresh token được cache ngắn trước khi tới Hydra
- Khi phát hiện retry, hệ thống phản hồi theo cách rút gọn mà không vô hiệu token
- Trong Hydra 2.X có
refresh token grace periodcó thể cấu hình để cho phép retry refresh token trong một khoảng thời gian mà không vô hiệu toàn bộ chuỗi
Quá trình chuyển sang 2.X và khôi phục
- Cloudflare không thể chấp nhận nhiều giờ gián đoạn có ảnh hưởng lớn đến người dùng, nên đã thực hiện nâng cấp blue-green
- Việc chuyển đổi thực tế đòi hỏi nhiều việc hơn là chỉ sao chép cơ sở dữ liệu và triển khai Hydra mới
- Kích hoạt hàng đợi ghi lại việc phát lại thu hồi
- Sao chép cơ sở dữ liệu và khôi phục sang đích mới
- Dọn dẹp dữ liệu cũ vi phạm các ràng buộc của phiên bản mới
- Cutover đồng thời dịch vụ Hydra và hai hệ thống nội bộ cốt lõi
- Giám sát và xác minh sau cutover
- Cửa sổ nâng cấp được chọn vào thời điểm Hydra có số request mỗi giây thấp nhất để giảm tối đa nguy cơ mất ghi token
- Migration production chạy tốt trên cơ sở dữ liệu mới ngoài một số tinh chỉnh timeout, và thời gian chạy thuần khoảng 3 giờ
- Ngay sau khi chuyển lưu lượng, tác vụ dọn dẹp dữ liệu của authorization service bắt đầu xóa quá mức dữ liệu OAuth policy
- Dịch vụ này phụ thuộc vào Hydra consent session API
- Một migration của Hydra đã làm hỏng một phần trạng thái phiên OAuth hợp lệ, khiến các phiên hợp lệ bị đánh dấu là không hợp lệ
- Sự không nhất quán giữa Hydra và authorization service biểu hiện thành số lượng 403 tăng
- Cloudflare giảm nhẹ vấn đề bằng khôi phục dữ liệu, đồng thời bắt đầu cải thiện hành vi OAuth authorization để giảm phụ thuộc vào dữ liệu policy tĩnh
- Một số chỉnh sửa nhỏ khác phát sinh từ hành vi riêng của từng client cũng nhanh chóng được áp dụng
Cải thiện hiệu năng sau nâng cấp
- Sau khi hoàn tất nâng cấp phiên bản Hydra, lưu lượng OAuth duy trì ổn định và hiệu năng cũng như độ tin cậy của hệ thống dành cho khách hàng được cải thiện
- Nền tảng mới này cũng chính là nền tảng của các OAuth API mới đã được xác thực trong staging, và là cơ sở cho bản phát hành self-managed OAuth ngày 3 tháng 6
- Các chỉ số chính quan sát được trong quá trình migration cơ sở dữ liệu:
- Hàng được cập nhật: 132.5M
- Hàng được chèn: 114.7M
- Temporary bytes: 136.97GB
- Giao dịch commit: 22.2k
- Các chỉ số hiệu năng trung bình của Hydra nhìn chung đều cải thiện sau nâng cấp
- API P95: 185ms → 101ms, giảm 45%
- Bộ nhớ RSS: 888MB → 763MB, giảm 14%
- Go heap alloc: 449MB → 271MB, giảm 40%
- Goroutines: 4015 → 3076, giảm 23%
- CPU: 1.07 core → 0.67 core, giảm 37%
1 bình luận
Ý kiến trên Hacker News
Tôi là người tạo ra Ory Hydra. Thật vui khi đọc bài blog này và phần giải thích kỹ thuật; tôi chưa từng tưởng tượng phần mềm này lại có thể bảo vệ các công ty Internet trên toàn thế giới
Thật tốt khi thấy phiên bản 2.x hoạt động ổn ở quy mô đó, và mức sử dụng CPU có vẻ thấp đến mức khó tin
Nếu gặp vấn đề thì cũng có phiên bản thương mại nhanh hơn. Nếu bạn quan tâm đến OAuth tự triển khai, IAM, phân quyền ReBAC, API key và bảo mật agent, có thể xem các sản phẩm mã nguồn mở và thương mại tại https://github.com/ory và https://www.ory.com/
Trước đây tôi từng vận hành self-host framework identity server cho dotnet và xử lý hàng tỷ request mỗi tháng; ở quy mô đó thì OAuth và OpenID Connect gần như là bài toán đã được giải quyết, và gánh nặng bảo trì cũng thấp
Đây là dịch vụ cốt lõi của tổ chức và còn có yêu cầu compliance nghiêm ngặt, nhưng đội phụ trách chắc chỉ khoảng 3 người và đến giờ vẫn chạy tốt
Tôi không hiểu vì sao lại có nhiều sự lẫn lộn quanh các giao thức này đến vậy, và gần như mọi kỹ sư junior tôi từng làm việc cùng đều gặp khó khăn trong việc hiểu nó. Blog của Scott Brady https://www.scottbrady.io/ rất hữu ích về chủ đề này
Có vẻ khi dính đến xác thực/phân quyền thì các kỹ sư nảy sinh một kiểu “nỗi sợ” rất bản năng. Họ vốn quen với việc giải quyết vấn đề, nhưng xác thực/phân quyền lại chen vào như một điều kiện tiên quyết của việc giải quyết vấn đề đó, nên tạo ra chi phí nhận thức
Rất điển hình của Cloudflare. Hoạt động tốt cho mọi người và không quá đắt, nhưng kết quả của tất cả những ưu điểm đó là nó trở thành trung tâm của mọi thứ
Tôi là Grant. Cùng với Aeneas, tôi đã viết phần lớn mã migration 2.0. Cảm ơn bài viết từ đội ngũ Cloudflare
Tôi muốn hỏi liệu đoạn “Qua điều tra, chúng tôi phát hiện một trong các migration Hydra có vấn đề, làm hỏng trạng thái của một số phiên OAuth hợp lệ, khiến migration đánh dấu các phiên đó là không hợp lệ” có phải là một trong các file migration mã nguồn mở không
Giờ tôi không còn tham gia dự án nữa, nhưng muốn biết liệu lỗi đó đã được sửa ở upstream chưa
Trong bối cảnh tổng thể, ít nhất cũng cần có kế hoạch về luồng phân quyền và xác thực trong hệ sinh thái Cloudflare, nên cảm xúc của tôi khá lẫn lộn. Thậm chí cũng không có ví dụ GitHub
Dù vậy, đúng là Cloudflare đã khởi đầu theo hướng đúng, nhưng vẫn còn một chặng đường dài nếu so với toàn bộ bộ sản phẩm nền tảng của Ory. Ory Kratos xử lý danh tính, đăng nhập, đăng ký, khôi phục, đa yếu tố xác thực, v.v.: https://github.com/ory
Tôi nghĩ phạm vi đầy đủ còn phải bao gồm kho lưu trữ người dùng, SAML và kế hoạch cho mô hình tổ chức đa tenant. Một ví dụ hay là Zitadel https://github.com/zitadel cung cấp UI quản trị cho multi-tenancy theo tổ chức, hỗ trợ OIDC/PKCE, và cũng có thể gắn thêm một phần RBAC
Supabase cũng cung cấp xác thực dạng managed và mã nguồn mở: https://github.com/supabase/auth
Bỏ qua chuyện “MCP đã chết, Skills là mãi mãi”, tôi lo rằng kế hoạch gắn MCP vào tất cả các hệ này và xoay vòng key sẽ sớm bùng nổ rất lớn
Đăng ký client động của OAuth 2.0 (RFC 7591): https://datatracker.ietf.org/doc/html/rfc7591
https://modelcontextprotocol.io/specification/2025-03-26/bas...
Tôi đặc biệt muốn nghe ý kiến trong bối cảnh SaaS đa tenant và AI assistant nhúng
Trong luồng redirect thường dùng khi kết nối MCP với agent, đặc tả gần như không nói gì về cách làm cho việc này an toàn
Bạn không muốn cho phép bất kỳ ai đăng ký client với callback tùy ý. Đó là con đường phơi bày ra phishing
Nếu ai đó đăng ký client với callback URL độc hại rồi lừa người dùng nhấp vào liên kết khởi động luồng đó, thì nhà cung cấp danh tính hợp pháp sẽ xác thực người dùng và sau đó chuyển access token cho kẻ tấn công
Đặc tả chỉ lướt qua chuyện initial access token mà client phải lấy trước khi đăng ký, nhưng thiếu chi tiết, và có lẽ khó hoạt động trong tình huống mọi end user đều là client
Lý tưởng nhất là bạn muốn chỉ định allowlist cho các mẫu redirect để giới hạn vào các đích như ChatGPT. Nhưng đây là hành vi phi tiêu chuẩn nên các vendor IAM không vội hỗ trợ
Tôi không rõ mục đích ở đây là gì. Không có kịch bản nào kết thúc tốt đẹp cả. Cloudflare gần như là một nhà cung cấp hạ tầng, mà mô hình hạ tầng cho phép người dùng ủy quyền quyền trên tài khoản của họ cho client bên thứ ba thì có khả năng bị lạm dụng rất lớn
Nếu một công ty như AWS không làm điều đó thì tôi nghĩ hẳn phải có lý do
Ví dụ, IAM có thể cấp quyền cập nhật Lambda cho GitHub Actions chạy từ một repository cụ thể
OAuth và xác thực doanh nghiệp có lẽ là một trong những thứ tệ nhất từng được tạo ra. Có thể đây là phần gây rối và bực bội nhất khi làm việc với đám mây
Ngay cả các công cụ AI cũng mất tới 1 năm chỉ để xử lý OAuth cơ bản trên hệ thống headless, thay vì giả định rằng có thể mở trình duyệt
Nếu đã phải chui xuống đủ mọi hang thỏ xác thực của các nhà cung cấp cloud lớn như RBAC/IAM/danh tính workload/tài khoản dịch vụ, thì xin hãy để lại một cách đơn giản cho mục đích sử dụng cá nhân
Chỉ cần một API key là đủ. Giữ nó bí mật và thu hồi khi cần, đâu cần 10.000 lớp rác rưởi xác thực quấn vào nhau ở mọi tầng của mọi nền tảng
Đúng là cơn ác mộng về quyền riêng tư
Chúng tôi vừa ra mắt Ory Talos cho API key(https://github.com/ory/talos). Đây là lựa chọn thay thế tốt khi OAuth2 là quá mức cần thiết so với trường hợp sử dụng
Cũng có những trường hợp sử dụng và lo ngại bảo mật đủ để biện minh cho việc dùng OAuth2. Các đặc tả như DPoP có thể làm những luồng này an toàn hơn
Trường hợp sử dụng được nêu ở đây có vẻ phù hợp với OAuth2, nhưng không phải thứ gì cũng vậy. Độ phức tạp khiến việc bảo mật hệ thống khó hơn
Ưu điểm của OAuth2/OIDC là niềm tin không được đặt vào người giữ API key, mà vào danh tính thực sự cần quyền truy cập
Xác thực khó là trường hợp xác thực cho nhiều người dùng. Xác thực cho chính bạn thì rất đơn giản, và còn dễ hơn nếu dùng framework tử tế
Nếu không yên tâm về triển khai thì cứ ném cho một trong các model mới nhất. Chúng khá giỏi trong việc tìm ra vấn đề của những hệ thống xác thực đơn giản như vậy
“Ory Enterprise License: mở khóa các tính năng cấp doanh nghiệp như CVE security SLA, SAML, tổ chức B2B, multi-tenancy, khả năng mở rộng tốt hơn” [0]
Hoặc bạn cứ tiếp tục dùng Keycloak, vốn cung cấp sản phẩm tự self-host hoàn chỉnh [1]
[0]https://github.com/ory
[1]https://www.keycloak.org/
Lý do có bản thương mại là vì câu hỏi làm thế nào để duy trì tài chính cho phần mềm nguồn mở đẳng cấp thế giới. Việc có một mô hình kinh doanh hoạt động được cho phần mềm nguồn mở đang chống lưng cho các công ty phần mềm lớn nhất hành tinh không phải điều xấu mà là điều tốt
Nhân tiện, IBM cũng đã tìm ra cách kiếm tiền với Keycloak
Về cơ bản đây là câu chuyện về OAuth cho quyền truy cập tài khoản Cloudflare, chứ không phải kiểu tính năng “đăng nhập” đa dụng do Cloudflare host cho các ứng dụng tùy chỉnh của người dùng
Tôi tưởng mình hiểu OAuth là gì, nhưng bài này làm tôi bối rối. Tôi nghĩ đó là một giao thức chuẩn hóa để cung cấp khóa truy cập theo từng client
Ở đây OAuth tự quản là gì? Cần giải thích đang cấp quyền truy cập cho cái gì, client là ai, và đối tác là ai
Nó cho phép bạn tự host hệ thống OAuth để phê duyệt hoặc từ chối quyền truy cập vào tài nguyên của chính mình. Thay vì chờ Cloudflare cho phép Y theo điều kiện X, bạn có thể tự tạo logic mình muốn
Về bản chất, luồng sẽ là “đăng nhập vào Cloudflare” → Cloudflare xác nhận việc dùng OAuth tự quản → chuyển hướng sang OAuth của người dùng → Cloudflare tin cậy phản hồi → nếu người dùng chấp thuận thì cho phép truy cập tài khoản