Kết nối OpenID nào thêm vào OAuth 2.0 (tại sao OAuth 2.0 không đủ để xác thực?)

Question

Tôi đã đọc một số lần viết khác nhau về điều này ngay bây giờ, nhưng tôi vẫn chưa rõ ràng về giá trị chính mà OpenID Connect cung cấp trên OAuth 2.0.

Hiểu biết của tôi:
Khi nhận mã thông báo truy cập qua luồng OAuth 2.0, khách hàng sẽ biết rằng người dùng đã được xác thực bởi máy chủ ủy quyền. Dường như OpenID Connect chỉ thêm một mã thông báo ID với thông tin người dùng - nhưng thông tin đó có thể là một phần của mã thông báo truy cập hoặc có sẵn thông qua tài nguyên được bảo vệ (như tài nguyên userDetails riêng biệt). Điều đó dường như không biện minh cho việc tạo OpenID Connect, vì vậy tôi chắc chắn rằng tôi thiếu một số thứ ...

Cảm ơn sự giúp đỡ của bạn!

Thêm các chi tiết khác quá dài để nhận xét. Cảm ơn bạn rất nhiều vì đã giúp đỡ bạn.

Tôi nghĩ rằng tôi đang tiến gần hơn, nhờ phản hồi của bạn. Vì vậy, tôi đã xem lại bài viết này: http://oauth.net/articles/authentication/. Nó nói rằng "OAuth nói hoàn toàn không có gì về người dùng". Tuy nhiên, bạn tin tưởng rằng cùng một dịch vụ để xác thực Người dùng cuối trước khi phát hành Mã thông báo truy cập. Trong "phần cạm bẫy phổ biến", bài viết thảo luận tại sao bạn không thể sử dụng mã thông báo truy cập để xác thực. Tôi có vấn đề sau đây với điều đó trong sự hiểu biết của tôi:

truy cập thẻ làm bằng chứng xác thực Các access token là bằng chứng xác thực tại một thời điểm nào trước khi. Nếu Khách hàng không muốn xác thực người dùng tại một số điểm sau khi nhận được mã thông báo truy cập, tại sao không chỉ lặp lại luồng Oauth hiện tại với người dùng cuối hiện tại đang cố truy cập ứng dụng khách?

Truy cập tài nguyên được bảo vệ dưới dạng bằng chứng Tương tự như trên - nếu khách hàng yêu cầu xác thực tại bất kỳ thời điểm nào, hãy lặp lại luồng Oauth.

Injection của thẻ truy cập Không rõ ràng như thế nào OpenID giúp này

Thiếu hạn chế khán giả Tại sao nó khó khăn hơn để tay một khách hàng ngây thơ một ID hợp lệ thẻ cùng với các thẻ truy cập? Điều này có liên quan chút nào với luồng phía máy chủ không? Và một lần nữa, có thể lặp lại luồng OAuth nếu cần.

Tiêm thông tin người dùng không hợp lệ Điều này dường như yêu cầu chữ ký chứ không phải mã thông báo riêng. Nếu luồng OAuth diễn ra qua HTTPS, có phải thêm bất kỳ bảo mật nào cho nhà cung cấp danh tính để ký chi tiết người dùng hai lần không?

Các giao thức khác nhau cho mọi nhà cung cấp nhận dạng tiềm năng Điều này có vẻ công bằng, nhưng mục đích duy nhất là chuẩn hóa mã thông báo được sử dụng cho thông tin người dùng.

Answer 1

Mã thông báo truy cập bị mờ đối với Khách hàng và có thể được cung cấp bởi bất kỳ ai, điều đó có nghĩa là nó không nhất thiết được Khách hàng đăng nhập trao cho Khách hàng. Kẻ tấn công có thể cung cấp mã thông báo truy cập cho Khách hàng mà nó nhận được từ một người dùng khác trong dịch vụ của riêng họ (không nhất thiết là độc hại).Mã thông báo ID từ OpenID Connect đảm bảo rằng người dùng đã đăng nhập gần đây tại OP và cung cấp thông tin về người dùng đó có thể được Khách hàng xác minh. Hơn nữa mã thông báo ID được nhắm mục tiêu cụ thể cho Khách hàng của bạn.

Sự khác biệt được mô tả khá tốt trong http://oauth.net/articles/authentication/

Answer 2

Một ID thẻ có thể được ký kết giữa máy chủ xác thực. Ứng dụng khách có thể xác minh chữ ký để xác nhận rằng người dùng cuối đã được xác thực bởi máy chủ xác thực rất. Mã thông báo truy cập + cuộc gọi tài nguyên được bảo vệ không cung cấp cơ chế như vậy.

Bên cạnh đó, OpenID Connect đã giới thiệu các cơ chế khác liên quan đến xác thực như:

1. Xác thực Context Lớp Reference
2. Maximum Xác thực Tuổi request parameter
3. sub tuyên bố trong claims

để đáp ứng yêu cầu bảo mật cấp cao hơn của chính phủ.

Đọc OpenID Connect Core 1.0 và các thông số có liên quan khác. Ngoài ra, bạn có thể tìm thấy "Authorization interaction" hữu ích dưới dạng tóm tắt về những gì OpenID Connect đã thêm để kiểm soát xác thực người dùng cuối.

Answer 3

OAuth 2.0 sắp cấp quyền truy cập hạn chế cho bên thứ ba vào tài nguyên. The RFC bắt đầu với

Các quyền của OAuth 2.0 khuôn khổ cho phép một bên thứ ba ứng dụng để có được quyền truy cập hạn chế đến một dịch vụ HTTP ...

OpenID Connect là về việc thiết lập bản sắc của một người dùng cuối. OpenID Connect Core spec bắt đầu bằng

OpenID Connect 1.0 là lớp nhận dạng đơn giản trên giao thức OAuth 2.0 . Nó cho phép khách hàng để xác minh danh tính của người dùng cuối dựa trên xác thực được thực hiện bởi một máy chủ ủy quyền ...

Trong OAuth 2.0, khi một máy chủ tài nguyên nhận được yêu cầu có chứa một thẻ truy cập, máy chủ tài nguyên biết rằng chủ sở hữu tài nguyên đã cấp cho bên thứ ba quyền truy cập vào tài nguyên. Mã thông báo truy cập thể hiện sự chấp thuận này nhưng không xác định được bên thứ ba đang trình bày nó.

Nếu một công ty cho rằng một người nào đó như Salesforce hoặc Google được trang bị tốt hơn là quản lý tài khoản người dùng, mật khẩu, chứng chỉ kỹ thuật số, v.v ..., công ty có thể sử dụng OpenID Connect về cơ bản "thuê ngoài". . Khi công ty nhận được mã thông báo id trong ngữ cảnh của luồng OpenID Connect, nó biết rằng nhà cung cấp đã xác thực người dùng cuối và thiết lập danh tính của người dùng.

Kết nối OpenID đã định hướng lại luồng OAuth 2.0 để có thể thiết lập danh tính của người dùng cuối.