Đặc tả OpenID Connect được công bố thành tiêu chuẩn ISO

• 9 đặc tả OpenID Connect đã được phát hành thành tiêu chuẩn ISO/IEC, đưa Core 1.0 cùng Discovery, Dynamic Client Registration, các đặc tả đăng xuất và cả chế độ phản hồi OAuth 2.0 vào hệ thống tiêu chuẩn quốc tế
• OpenID Foundation đã nộp lên ISO vào tháng 12/2023 theo hình thức PAS(Publicly Available Specifications), sau đó hoàn tất từ bỏ phiếu phê duyệt của ISO đến phát hành
• Việc tiêu chuẩn hóa ISO có thể giúp triển khai OpenID Connect dễ dàng hơn cả ở các khu vực pháp lý yêu cầu đặc tả từ tổ chức tiêu chuẩn hóa được công nhận theo điều ước quốc tế
• Trước khi nộp, OpenID Connect working group đã thực hiện quy trình áp dụng errata corrections để các bản sửa lỗi đã biết được đưa vào phiên bản ISO
• Dựa trên kinh nghiệm từ quy trình PAS lần này, OpenID Foundation dự định sẽ nộp FAPI 1.0, và sau khi hoàn tất, cả các bộ đặc tả eKYC-IDA và FAPI 2.0 để phát hành thành ISO

---

Các đặc tả được phát hành thành tiêu chuẩn ISO/IEC

• Lần này có 9 đặc tả liên quan đến OpenID Connect được phát hành thành tiêu chuẩn ISO/IEC
  • ISO/IEC 26131:2024 — Information technology — OpenID connect — OpenID connect core 1.0 incorporating errata set 2
  • ISO/IEC 26132:2024 — Information technology — OpenID connect — OpenID connect discovery 1.0 incorporating errata set 2
  • ISO/IEC 26133:2024 — Information technology — OpenID connect — OpenID connect dynamic client registration 1.0 incorporating errata set 2
  • ISO/IEC 26134:2024 — Information technology — OpenID connect — OpenID connect RP-initiated logout 1.0
  • ISO/IEC 26135:2024 — Information technology — OpenID connect — OpenID connect session management 1.0
  • ISO/IEC 26136:2024 — Information technology — OpenID connect — OpenID connect front-channel logout 1.0
  • ISO/IEC 26137:2024 — Information technology — OpenID connect — OpenID connect back-channel logout 1.0 incorporating errata set 1
  • ISO/IEC 26138:2024 — Information technology — OpenID connect — OAuth 2.0 multiple response type encoding practices
  • ISO/IEC 26139:2024 — Information technology — OpenID connect — OAuth 2.0 form post response mode

Nộp theo PAS và phê duyệt của ISO

• Việc nộp các đặc tả OpenID Connect cho OpenID Foundation được thực hiện vào tháng 12/2023 dưới dạng PAS(Publicly Available Specifications)
• Sau cuộc bỏ phiếu phê duyệt của ISO, các đặc tả này đã được phát hành thành tiêu chuẩn ISO/IEC
• Vì ISO là một trong các tổ chức tiêu chuẩn hóa được công nhận theo điều ước quốc tế, khả năng áp dụng OpenID Connect có thể mở rộng tại những khu vực pháp lý bắt buộc sử dụng tiêu chuẩn của các tổ chức như vậy

Các sửa đổi được đưa vào phiên bản ISO

• Trước khi nộp, OpenID Connect working group đã thực hiện quy trình áp dụng errata corrections cho các đặc tả
• Kết quả là phiên bản ISO đã phản ánh các sửa lỗi đã biết

Kế hoạch nộp ISO tiếp theo

• Sau khi hoàn tất một lần quy trình nộp ISO PAS, OpenID Foundation dự định tiếp tục nộp thêm các bộ đặc tả cuối cùng để phát hành thành ISO
• Đối tượng tiếp theo bao gồm đặc tả FAPI 1.0
• Các đặc tả eKYC-IDA và FAPI 2.0 được đặt làm đối tượng nộp sau khi hoàn tất

[GN⁺]

Ý kiến trên Hacker News

• Dù từng tham gia khá sâu vào OpenID khoảng 17 năm trước (https://simonwillison.net/search/?tag=openid&year=2007), tôi đã mất lâu đến mức hơi xấu hổ mới hiểu rằng OpenID Connect gần như không liên quan gì đến ý tưởng OpenID ban đầu: “định danh là một URL và chứng minh quyền sở hữu URL đó”
  OpenID Connect thực ra gần với một dạng tiến hóa của OAuth hơn

  • Ghi chú cho chính tôi sau này: OpenID Connect (OIDC) chủ yếu xử lý xác thực, còn OAuth, chính xác hơn là OAuth v2.0, xử lý ủy quyền
    Tôi nghĩ OpenID Connect, xét về tầm nhìn và tinh thần, gần với sự tiến hóa của OpenID hơn là sự tiến hóa của OAuth. OIDC tập trung vào định danh và xác thực người dùng giống OpenID, nhưng khác với OpenID, nó không tạo lại một luồng xác thực hoàn toàn mới; thay vào đó, nó đặt luồng xác thực lên trên đặc tả OAuth vốn đã bị dùng sai mục đích cho xác thực, để đạt mục tiêu chính
  • OAuth2 quá linh hoạt về cách ghép các thành phần, còn OIDC cung cấp nhiều thực hành tốt về “ghép như thế nào”
    Vì vậy ngay cả các hệ thống không nhắm đến việc tuân thủ OIDC cũng thường tuân theo một phần OIDC. Nếu một phần của tiêu chuẩn OIDC đã cung cấp thứ cần thiết thì không có lý do gì phải phát minh lại bánh xe
  • Cách đặt tên đúng là một cơn ác mộng
    OpenID Connect là một phần mở rộng thêm lớp xác thực vào OAuth2 (RFC 6749), còn OAuth2 là một framework ủy quyền để cấp quyền
    Trong khi đó OAuth 1.0/1.0a và OpenID 1/2 chỉ giống tên, còn lại là các giao thức không liên quan và không tương thích với nhau, nên tính đến năm 2024 thì phần lớn là không liên quan. Cần cẩn thận khi tìm kiếm
  • Tôi hiểu OpenID Connect gần như là một chuyên biệt hóa được xây trên OAuth2
  • Tôi bắt đầu quan tâm đến OpenID nhờ bài trình bày tại Webstock năm 2008

• Đây không phải là điều tốt ở bất kỳ khía cạnh nào. Trước hết, tiêu chuẩn trả phí mà muốn xem phải trả tiền là rất tệ
  Thứ hai, tôi mong có nhiều nỗ lực hơn trong việc thiết kế các tiêu chuẩn và triển khai sao cho khi cần dùng không trở thành hố đen thời gian bất tận

  • Tôi đồng ý về ISO, nhưng trong trường hợp này khó nói là có một rào chắn thu phí đáng kể. Bản thân tiêu chuẩn đã được công bố miễn phí, và việc này trông giống như gán một định danh trong không gian tên tiêu chuẩn hóa của ISO
    Tuy nhiên tôi không rõ việc có số tiêu chuẩn ISO thì có lợi gì hơn so với việc đưa một tài liệu HTML lên Internet
  • Về phía Internet, tôi thắc mắc vì sao những thứ như vậy không được làm thành RFC. Email và TCP cũng là RFC, các thành phần cốt lõi khác cũng vậy, và các công ty toàn cầu cũng dùng thường xuyên

• Tiêu chuẩn thì tốt, nhưng các tổ chức tiêu chuẩn hóa lớn như ISO thu tiền để xem tiêu chuẩn thì thật khó chịu
  Có lẽ vì trong một số doanh nghiệp hoặc ngành công nghiệp, họ yêu cầu tiêu chuẩn “thật” từ các tổ chức như vậy hơn là thứ do IETF hay một đám hippie mã nguồn mở bẩn thỉu tạo ra

  • Lập luận của phía đó là để cung cấp khả năng tiếp cận và nguồn tài chính cho các khu vực kém phát triển hơn
  • “Tiêu chuẩn” và “tốn tiền” nghe có vẻ mâu thuẫn với nhau. Nếu muốn một cách làm trở thành tiêu chuẩn, tức cách phổ biến nhất, thì nó phải đủ dễ tiếp cận để có thể được triển khai rộng rãi
  • Phần lớn tiêu chuẩn có giá thấp đến mức gần như bán lỗ. Thay vào đó, nếu muốn quyên góp cho ISO hoặc IEEE thì điều đó sẽ giúp giảm chi phí soạn thảo tiêu chuẩn
  • Tôi hiểu rằng trong bối cảnh chính phủ hoặc quốc gia, vì ISO được công nhận trong nhiều điều ước quốc tế, nên việc được phê duyệt dùng tiêu chuẩn ISO thường dễ hơn so với tiêu chuẩn của OpenID Foundation
    Vì vậy nếu OpenID Connect được phát hành với số ISO, việc áp dụng trong một số dự án sẽ dễ hơn. Tất nhiên bản thân OpenID Connect vẫn tiếp tục được đọc và sử dụng miễn phí, nhưng những người ở trong các tình huống như trên sẽ có một lựa chọn dễ dàng hơn

• ISO là thứ rác rưởi không tự do và không giúp ích cho hệ sinh thái phần mềm
  Nhìn ISO 8601 mà xem: nó quá phức tạp, thường không được triển khai đúng vì các maintainer dùng bản nháp miễn phí, và thực tế cũng không giải quyết được điều gì cho ra hồn. Ví dụ, nó không thể biểu diễn giờ đồng hồ treo tường, nên gặp vấn đề với các ngày trong tương lai khi múi giờ có thể thay đổi
  Trước đây tôi cũng từng xử lý mp4, và nhận ra chỉ ISO thôi là không đủ vì có những thay đổi trong stack của Apple

  • Tôi hiểu những bất mãn cụ thể, nhưng tôi lại xem việc không biểu diễn giờ đồng hồ treo tường là một tính năng
    Phê phán thường trôi sang các giả định như thay đổi giờ mùa hè. Kiểu phê phán phổ biến là: “Tôi muốn chỉ định 14:00 giờ địa phương Absurdistan sau 4 năm nữa, bất kể quan hệ của nó với UTC là gì, nhưng không làm được”. Nhưng nếu đẩy giả định đi xa hơn một chút, Absurdistan cũng có thể thêm lãnh thổ hải ngoại, gia nhập một liên minh, hoặc thay đổi múi giờ và giờ mùa hè
    Nếu nghĩ kỹ vấn đề, bản thân định nghĩa giờ địa phương có thể thay đổi, nên trừ khi định nghĩa đầy đủ mọi thay đổi có thể xảy ra, việc chỉ định giờ địa phương trong tương lai là bất khả thi. Cuối cùng, hoặc phải ấn định số tick của đồng hồ nguyên tử trong tương lai (TAI) rồi diễn giải thành giờ địa phương tại thời điểm sử dụng, hoặc chỉ định một thời điểm cố định nào đó rồi diễn giải thành giờ địa phương tại thời điểm sử dụng
  • Tôi thắc mắc liệu có lựa chọn thay thế cho ISO 8601 không. Bất mãn của tôi chỉ là dường như có nhiều hơn một cách để biểu diễn vài thứ, còn vấn đề giờ đồng hồ treo tường thì tôi không biết
    Tôi cũng tò mò liệu API JS Temporal mới có xử lý việc này không. Có vẻ nó đã đi khá sâu

• Các tiêu chuẩn phải trả tiền để đọc như ISO đang chủ động cản trở tiến bộ của nhân loại. Tôi mong đừng khuyến khích kiểu hành vi này

  • Với C++, bản nháp tiêu chuẩn mới nhất được công bố miễn phí https://en.cppreference.com/w/cpp/links#C.2B.2B_standard_doc...
    Tôi hiểu rằng bản nháp cuối cùng và tiêu chuẩn chính thức gần như giống nhau về nội dung thực chất. Có lẽ bản nháp tiêu chuẩn OIDC cũng được công bố ở đâu đó
  • Không phải mọi thứ đều cần trắng đen rõ ràng. Có thể thừa nhận rằng tồn tại vùng xám
    Nói rằng các kỹ sư đó vừa tạo ra tiến bộ cho nhân loại, đồng thời lại đang chủ động gây hại cho tiến bộ của nhân loại, nghe khá kỳ lạ

• Cấp phát danh tính là một con quái vật lẽ ra không nên được phát minh
  Vào giữa những năm 2000, tôi từng là fan đến mức tự vận hành máy chủ OpenID, nhưng khi đó không nhận ra toàn bộ khái niệm này về căn bản khiếm khuyết đến mức nào
  Danh tính là thuộc tính không thể chuyển nhượng, vốn có của một cá nhân, chứ không phải thứ mà cá nhân khác, công ty/trang web, chính phủ, v.v. có thể “cung cấp”. Họ chỉ có thể cung cấp thông tin xác thực để chứng minh, kiểu như cấp hộ chiếu mà thôi
  Ít nhất WebAuthn đã xử lý đúng phần này

  • Chẳng phải nó đang giả định rằng danh tính được cung cấp chính xác là bạn và chỉ mình bạn sao? Tôi luôn xem và sử dụng những danh tính này như bút danh nằm trên một nhà cung cấp danh tính nào đó
    Một số danh tính được dùng ở đủ nhiều nơi đến mức với vài bên thì khó phủ nhận đó là của tôi, nhưng ngay cả khi đó, trong số các bên đã thấy danh tính ấy, chỉ một tập con nhỏ có thể chứng minh đó là tôi
  • Tôi tò mò liệu sự phân biệt giữa chứng minh và cấp phát có hệ quả thực tế nào không, hay chỉ thuần túy là phân biệt triết học

• Bên ngoài Google, MS, Apple, liệu còn nhà phát hành OIDC độc lập nào cho phép tạo tài khoản không?
  Cách đây không lâu tôi muốn tạo tài khoản Tailscale mà không dùng tài khoản GitHub, nhưng không làm được
  Trước đây hình như openid.net và Ubuntu One từng cung cấp dịch vụ kiểu này, nhưng tôi biết là đã ngừng rồi

  • Vẫn còn vài nơi, và https://gitlab.com là nơi tôi hay dùng
    Tuy nhiên chi phí bảo mật và hỗ trợ cần cho các dịch vụ như vậy rất lớn, nên đặc biệt nếu cung cấp miễn phí thì với các tổ chức nhỏ là không thực tế. Lợi thế kinh tế theo quy mô giúp những thứ này khả thi là rất lớn, và đặc biệt phù hợp khi các công ty lớn trả tiền cho sản phẩm doanh nghiệp

• OpenID Connect là một giao thức khá đơn giản. Tôi đã đọc đặc tả (https://openid.net/specs/openid-connect-core-1_0.html) và hiểu được phần lớn chỉ trong khoảng một ngày
  Với những ai không muốn đọc đặc tả, tôi cũng đã viết một tutorial tổng hợp triển khai OpenID client bằng các yêu cầu HTTP đơn giản (https://spapas.github.io/2023/11/29/openid-connect-tutorial/)
  Ví dụ dùng Python, nhưng triển khai bằng ngôn ngữ bạn muốn chắc cũng không khó. Phần lớn độ phức tạp nằm ở việc giải mã và kiểm tra JWT token
  Tôi đã dùng client viết thủ công này trong một dự án production thực tế khoảng 1 năm để xác thực với Keycloak, và mọi thứ đang hoạt động hoàn hảo
  Tái bút: Tôi biết trang của mình có quá nhiều quảng cáo. Đáng tiếc là tôi không có thời gian cấu hình Google Ads cho đúng, cũng không tìm được lựa chọn thay thế tốt hơn. Khi đọc thì cứ dùng trình chặn quảng cáo là được

  • Bài viết rất thú vị và được viết tốt
    Tuy nhiên nên cẩn thận với các cách diễn đạt chủ quan như đơn giản. Nếu độc giả cảm thấy khó mà tác giả lại nói là đơn giản, họ có thể thấy khá bị nản lòng
  • Tutorial xuất sắc
    Dù vậy tôi vẫn chưa tin chắc rằng OIDC là dễ. Keycloak đang che giấu độ phức tạp khổng lồ, và không phải các lập trình viên tạo ra nó như vậy chỉ vì rảnh rỗi. Ví dụ, có rất nhiều cấu hình timeout khác nhau như timeout SSO, timeout client, timeout cho nhiều loại token, v.v.

• Việc kiếm tiền và vận hành tổ chức quanh các tiêu chuẩn ISO nhìn chung tạo cảm giác rất đáng ngờ
  Một mẹo ít người biết là có thể tìm các phiên bản tiêu chuẩn rẻ hơn trên trang Estonia thân thiện https://evs.ee. Họ thường tự tạo các phiên bản riêng có nội dung gần như giống bản gốc. Đáng tiếc trong trường hợp này có vẻ họ chỉ cung cấp tiêu chuẩn thực với mức giá tương tự https://www.evs.ee/en/search?OnlySuggestedProducts=false&que...
  Vẫn đáng theo dõi trang này xem sau này có phiên bản riêng với giá tốt hơn không. Thường giá chỉ khoảng 10% so với bản gốc. Đây là thêm một dữ kiện nữa cho thấy Estonia đang làm những việc rất hay
  Vì làm về tuân thủ quy định thiết bị y tế, tôi thường xuyên phải làm việc với những tổ chức tiêu chuẩn hóa khá đáng ngờ https://openregulatory.com/accessing-standards/
  Tôi đã nghe hết các lập luận quen thuộc kiểu “tiêu chuẩn hóa tốn tiền”, “các tổ chức này làm việc tốt”, nhưng hoàn toàn không đồng ý. Nếu một thứ là tiêu chuẩn thì tôi xem nó gần giống luật. Mọi người phải có khả năng tuân theo nó, và để vậy thì phải được truy cập tự do. Có vẻ Tổng luật sư EU cũng đồng ý https://openregulatory.com/maybe-eu-standards-are-becoming-f...
  Có rất nhiều hoạt động tiêu chuẩn hóa không cần bán PDF lấy tiền một cách đáng ngờ. ECMAScript và ANSI C là những ví dụ tôi nghĩ đến, và còn nhiều nữa

• Khi biến thành ấn phẩm ISO, nó trở thành lá chắn né trách nhiệm cho bộ phận mua sắm
  Dù sao thì chưa ai từng bị sa thải vì yêu cầu tuân thủ một bộ tiêu chuẩn ISO cả