Bảo mật mùa xuân và OpenID Connect (OIDC)

Question

Trong dự án hiện tại của tôi, tôi sử dụng toàn bộ dự án Spring Security OAuth (http://projects.spring.io/spring-security-oauth/) để bảo vệ tài nguyên của chúng tôi (API Web). Tất cả mọi thứ hoạt động tốt cho đến bây giờ.

Tôi hiện đang làm việc để phát triển khách hàng và tôi đang tìm kiếm sự hỗ trợ tốt cho các kịch bản xác thực (vì OAuth là giao thức ủy quyền). Sau một thời gian dài, tìm kiếm internet dài tôi khá chắc chắn tôi nên dùng OpenID Connect (http://openid.net/connect/) để đáp ứng yêu cầu này, vì nó là "một lớp nhận dạng đơn giản trên OAuth 2.0" (tôi biết tuy nhiên, không có "đơn giản" trong trường hợp chủ đề bảo mật).

Buồn nhưng đúng Tôi không thể tìm thấy bất kỳ tài nguyên nào tốt về hỗ trợ cho OpenID Connect (không gây nhầm lẫn với "OpenID" thuần túy) trong Spring Security. Có một thực hiện tham chiếu OpenID Connect tại https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server nhưng tôi đã mong đợi một cái gì đó tương tự trực tiếp trong/từ Spring Security với tài liệu toàn diện và vân vân. Tôi đã tìm thấy khoảng 2 năm thảo luận về nó ở đây https://github.com/spring-projects/spring-security-oauth/issues/220 nhưng tình trạng hiện tại là gì? Tìm kiếm "Hỗ trợ bảo mật mùa xuân cho OpenID Connect" không cung cấp bất kỳ kết quả "hữu hình" nào.

Bạn có bất kỳ thông tin, tài liệu và/hoặc kinh nghiệm nào về việc triển khai OpenID Connect với sự trợ giúp của Spring Security không?

Answer 1

Trước OpenID Connect nổi lên, đó là thực tế không quan trọng để giả định rằng giá trị của tham số yêu cầu response_type thể là code (ví authorization code flow) hoặc token (ví implicit flow). Tuy nhiên, hiện tại, triển khai máy chủ ủy quyền phải có thể xử lý mọi kết hợp (code, token, id_token) và none. Chi tiết được mô tả trong "OpenID Connect Core 1.0, 3. Authentication" và "OAuth 2.0 Multiple Response Type Encoding Practices".

Là bước đầu tiên để hỗ trợ OpenID Connect, OAuth bảo mật mùa xuân phải trở nên linh hoạt cho response_type. Bạn có thể tìm thấy yêu cầu tại "Issue 619: Handling additional response_types". Tuy nhiên, thật khó để thay đổi mã hiện tại chỉ mong đợi code hoặc token thành mã mới có thể chấp nhận nhiều giá trị cùng một lúc. Theo văn bản này, nhận xét mới nhất của Issue 619 được thực hiện vào ngày 12 tháng 12 năm 2015 kết thúc bằng câu được trích dẫn bên dưới.

Bất kỳ nhận xét nào được hoan nghênh hơn vì điều này hóa ra là (như tôi đã dự đoán) bài tập tái cấu trúc lớn.

Nếu OAuth bảo mật mùa xuân hoàn toàn là dự án tự nguyện mà không có bất kỳ sự hỗ trợ nào từ cơ quan thương mại, thay đổi lớn như vậy sẽ không xảy ra.

Trải nghiệm của tôi: Khoảng hai năm trước, tôi đã viết máy chủ OAuth 2.0 từ đầu. Đó là sau khi tôi biết về sự tồn tại của OpenID Connect. Sau khi đọc các thông số kỹ thuật liên quan đến OpenID Connect, cuối cùng tôi đã đạt được một kết luận để kết thúc việc triển khai hiện tại và viết lại máy chủ từ đầu một lần nữa.

Như bạn đã đoán, OpenID Connect không hề đơn giản chút nào.

cũng Xem "5. Loại Response" trong "Full-Scratch Implementor of OAuth and OpenID Connect Talks About Findings".

---

Cập nhật (2017-tháng mười một-23)

Authorization Server và nhà cung cấp OpenID trên Spring Framework
https://github.com/authlete/spring-oauth-server

Server Resource trên Spring Framework
https://github.com/authlete/spring-resource-server

spring-oauth-server hỗ trợ OAuth 2.0 và OpenID Connect. spring-resource-server có triển khai điểm cuối UserInfo được xác định trong "OpenID Connect 1.0, 5.3. UserInfo Endpoint". Cả hai triển khai đều không sử dụng Spring Security OAuth nhưng sử dụng Spring Boot và Authlete.

Blog: Spring + OAuth 2.0 + OpenID Connect