OAuth 2.0: Lợi ích và trường hợp sử dụng - tại sao?

Bất cứ ai có thể giải thích những gì tốt về OAuth2 và tại sao chúng ta nên thực hiện nó? Tôi hỏi bởi vì tôi hơi bối rối về nó - đây là suy nghĩ hiện tại của tôi:

Các yêu cầu OAuth1 (chính xác hơn là HMAC) có vẻ hợp lý, dễ hiểu, dễ phát triển và thực sự, thực sự an toàn.

Thay vào đó, OAuth2 mang đến các yêu cầu ủy quyền, mã thông báo truy cập và mã thông báo làm mới và bạn phải thực hiện 3 yêu cầu ngay khi bắt đầu phiên để nhận dữ liệu bạn theo dõi. Và thậm chí sau đó, một trong những yêu cầu của bạn cuối cùng sẽ thất bại khi mã thông báo hết hạn.

Và để có được mã thông báo truy cập khác, bạn sử dụng mã thông báo làm mới được chuyển cùng lúc với mã thông báo truy cập. Điều đó có làm cho mã thông báo truy cập vô ích theo quan điểm bảo mật không?

Thêm vào đó, như / r / Netsec đã chỉ ra gần đây, SSL không hoàn toàn an toàn, do đó, việc thúc đẩy mọi thứ vào TLS / SSL thay vì một HMAC an toàn làm tôi bối rối.

OAuth đang lập luận rằng nó không an toàn 100%, nhưng được xuất bản và hoàn thành. Điều đó không chính xác âm thanh hứa hẹn từ quan điểm của nhà cung cấp. Tôi có thể thấy những gì bản dự thảo đang cố gắng đạt được khi đề cập đến 6 luồng khác nhau, nhưng nó chỉ không khớp với nhau trong đầu tôi.

Tôi nghĩ rằng có lẽ tôi sẽ khó khăn hơn để hiểu được lợi ích và lý luận của nó hơn là thực sự không thích nó, vì vậy đây có thể là một cuộc tấn công không chính đáng, và xin lỗi nếu điều này có vẻ giống như một lời nói.

Bối cảnh: Tôi đã viết ngăn xếp máy khách và máy chủ cho OAuth 1.0a và 2.0.

Cả OAuth 1.0a & 2.0 đều hỗ trợ xác thực hai chân , trong đó máy chủ được đảm bảo về danh tính người dùng và xác thực ba chân , trong đó máy chủ được đảm bảo bởi nhà cung cấp nội dung về danh tính người dùng. Xác thực ba chân là nơi các yêu cầu ủy quyền và mã thông báo truy cập xuất hiện và điều quan trọng cần lưu ý là OAuth 1 cũng có những yêu cầu đó.

Một phức tạp: xác thực ba chân

Điểm chính của thông số kỹ thuật OAuth là dành cho nhà cung cấp nội dung (ví dụ: Facebook, Twitter, v.v.) để đảm bảo máy chủ (ví dụ: ứng dụng Web muốn nói chuyện với nhà cung cấp nội dung thay mặt khách hàng) rằng khách hàng có một số nhận dạng . Những gì xác thực ba chân cung cấp là khả năng thực hiện điều đó mà không cần máy khách hoặc máy chủ cần biết chi tiết về danh tính đó (ví dụ: tên người dùng và mật khẩu).

Không có (?) Nhận được quá sâu vào các chi tiết của OAuth:

1. Máy khách gửi yêu cầu ủy quyền đến máy chủ, xác nhận rằng máy khách là máy khách hợp pháp của dịch vụ.
2. Máy chủ chuyển hướng khách hàng đến nhà cung cấp nội dung để yêu cầu quyền truy cập vào tài nguyên của nó.
3. Nhà cung cấp nội dung xác thực danh tính người dùng và thường yêu cầu sự cho phép của họ để truy cập tài nguyên.
4. Nhà cung cấp nội dung chuyển hướng khách hàng trở lại máy chủ, thông báo về việc thành công hay thất bại. Yêu cầu này bao gồm mã ủy quyền thành công.
5. Máy chủ đưa ra yêu cầu ngoài băng cho nhà cung cấp nội dung và trao đổi mã ủy quyền để lấy mã thông báo truy cập.

Giờ đây, máy chủ có thể thực hiện các yêu cầu cho nhà cung cấp nội dung thay mặt cho người dùng bằng cách chuyển mã thông báo truy cập.

Mỗi trao đổi (client-> máy chủ, máy chủ-> nhà cung cấp nội dung) bao gồm xác thực một bí mật được chia sẻ, nhưng vì OAuth 1 có thể chạy qua một kết nối không được mã hóa, mỗi xác thực không thể truyền bí mật qua dây.

Điều đó đã được thực hiện, như bạn đã lưu ý, với HMAC. Máy khách sử dụng bí mật mà nó chia sẻ với máy chủ để ký các đối số cho yêu cầu ủy quyền của nó. Máy chủ lấy các đối số, ký chính chúng bằng khóa của máy khách và có thể xem liệu đó có phải là máy khách hợp pháp không (ở bước 1 ở trên).

Chữ ký này yêu cầu cả máy khách và máy chủ đồng ý về thứ tự của các đối số (vì vậy chúng ký chính xác cùng một chuỗi) và một trong những phàn nàn chính về OAuth 1 là nó yêu cầu cả máy chủ và máy khách sắp xếp và ký nhận dạng. Đây là mã khó sử dụng và nó đúng hoặc bạn nhận được 401 Unauthorizedvới sự giúp đỡ nhỏ. Điều này làm tăng rào cản để viết một khách hàng.

Bằng cách yêu cầu ủy quyền yêu cầu chạy qua SSL, OAuth 2.0 loại bỏ nhu cầu sắp xếp đối số và ký hoàn toàn. Máy khách chuyển bí mật của nó đến máy chủ, xác nhận nó trực tiếp.

Các yêu cầu tương tự cũng xuất hiện trong kết nối máy chủ-> nhà cung cấp nội dung và vì SSL đó loại bỏ một rào cản đối với việc viết một máy chủ truy cập các dịch vụ OAuth.

Điều đó làm cho mọi thứ dễ dàng hơn nhiều trong các bước 1, 2 và 5 ở trên.

Vì vậy, tại thời điểm này, máy chủ của chúng tôi có mã thông báo truy cập vĩnh viễn là tên người dùng / mật khẩu tương đương với người dùng. Nó có thể thực hiện các yêu cầu cho nhà cung cấp nội dung thay mặt cho người dùng bằng cách chuyển mã thông báo truy cập đó như một phần của yêu cầu (dưới dạng đối số truy vấn, tiêu đề HTTP hoặc dữ liệu biểu mẫu POST).

Nếu dịch vụ nội dung chỉ được truy cập qua SSL, chúng tôi đã hoàn thành. Nếu nó có sẵn thông qua HTTP đơn giản, chúng tôi muốn bảo vệ mã thông báo truy cập vĩnh viễn đó theo một cách nào đó. Bất cứ ai đánh hơi được kết nối sẽ có thể có quyền truy cập vào nội dung của người dùng mãi mãi.

Cách giải quyết trong OAuth 2 là với mã thông báo làm mới . Mã thông báo làm mới trở thành mật khẩu vĩnh viễn tương đương và nó chỉ được truyền qua SSL . Khi máy chủ cần quyền truy cập vào dịch vụ nội dung, nó sẽ trao đổi mã thông báo làm mới cho mã thông báo truy cập ngắn hạn. Bằng cách đó, tất cả các truy cập HTTP có thể đánh hơi được thực hiện bằng mã thông báo sẽ hết hạn. Google đang sử dụng hết hạn 5 phút trên API OAuth 2 của họ.

Vì vậy, ngoài các mã thông báo làm mới, OAuth 2 đơn giản hóa tất cả các giao tiếp giữa máy khách, máy chủ và nhà cung cấp nội dung. Và mã thông báo làm mới chỉ tồn tại để cung cấp bảo mật khi nội dung đang được truy cập không được mã hóa.

Xác thực hai chân

Tuy nhiên, đôi khi, một máy chủ chỉ cần kiểm soát quyền truy cập vào nội dung của chính nó. Xác thực hai chân cho phép khách hàng xác thực người dùng trực tiếp với máy chủ.

OAuth 2 tiêu chuẩn hóa một số phần mở rộng cho OAuth 1 được sử dụng rộng rãi. Người mà tôi biết rõ nhất được Twitter giới thiệu là xAuth . Bạn có thể thấy nó trong OAuth 2 dưới dạng Thông tin mật khẩu của chủ sở hữu tài nguyên .

Về cơ bản, nếu bạn có thể tin tưởng khách hàng với thông tin đăng nhập của người dùng (tên người dùng và mật khẩu), họ có thể trao đổi trực tiếp những thông tin đó với nhà cung cấp nội dung để lấy mã thông báo truy cập. Điều này làm cho OAuth hữu ích hơn nhiều trên các ứng dụng di động - với xác thực ba chân, bạn phải nhúng chế độ xem HTTP để xử lý quy trình ủy quyền với máy chủ nội dung.

Với OAuth 1, đây không phải là một phần của tiêu chuẩn chính thức và yêu cầu quy trình ký giống như tất cả các yêu cầu khác.

Tôi vừa triển khai phía máy chủ của OAuth 2 với Thông tin mật khẩu của chủ sở hữu tài nguyên và từ góc độ của khách hàng, việc nhận mã thông báo truy cập đã trở nên đơn giản: yêu cầu mã thông báo truy cập từ máy chủ, chuyển id / bí mật của máy khách làm tiêu đề ủy quyền HTTP và đăng nhập / mật khẩu của người dùng dưới dạng dữ liệu.

Ưu điểm: Đơn giản

Vì vậy, từ quan điểm của người triển khai, những lợi thế chính tôi thấy trong OAuth 2 là giảm độ phức tạp. Nó không yêu cầu thủ tục ký yêu cầu, điều này không thực sự khó khăn nhưng chắc chắn là khó khăn. Nó làm giảm đáng kể công việc cần thiết để hoạt động như một khách hàng của một dịch vụ, đó là nơi (trong thế giới di động hiện đại) mà bạn muốn giảm thiểu đau đớn nhất. Sự phức tạp giảm trên máy chủ-> nhà cung cấp nội dung kết thúc làm cho nó có khả năng mở rộng hơn trong trung tâm dữ liệu.

Và nó mã hóa thành một số phần mở rộng tiêu chuẩn thành OAuth 1.0a (như xAuth) hiện đang được sử dụng rộng rãi.

Đầu tiên, như được chỉ định rõ ràng trong xác thực OAuth

OAuth 2.0 không phải là một giao thức xác thực.

Xác thực trong bối cảnh người dùng truy cập vào một ứng dụng cho ứng dụng biết người dùng hiện tại là ai và họ có mặt hay không. Một giao thức xác thực đầy đủ có thể cũng sẽ cho bạn biết một số thuộc tính về người dùng này, chẳng hạn như số nhận dạng duy nhất, địa chỉ email và những gì cần gọi cho họ khi ứng dụng nói "Chào buổi sáng".

Tuy nhiên, OAuth nói với ứng dụng không có điều đó. OAuth hoàn toàn không nói gì về người dùng, cũng như không nói người dùng đã chứng minh sự hiện diện của họ như thế nào hoặc ngay cả khi họ vẫn ở đó. Theo như một khách hàng OAuth có liên quan, họ đã yêu cầu mã thông báo, nhận mã thông báo và cuối cùng đã sử dụng mã thông báo đó để truy cập một số API. Nó không biết bất cứ điều gì về người đã ủy quyền cho ứng dụng hoặc thậm chí nếu có một người dùng ở đó.

Có một tiêu chuẩn để xác thực người dùng bằng OAuth: OpenID Connect, tương thích với OAuth2.

Mã thông báo ID OpenID Connect là mã thông báo web JSON đã ký (JWT) được cấp cho ứng dụng khách cùng với mã thông báo truy cập OAuth thông thường. Mã thông báo ID chứa một tập hợp các khiếu nại về phiên xác thực, bao gồm mã định danh cho người dùng (phụ), mã định danh cho nhà cung cấp nhận dạng đã phát hành mã thông báo (iss) và mã định danh của khách hàng mà mã thông báo này được tạo ( kiểm toán).

Trong Go, bạn có thể xem xét coreos / dex, Nhà cung cấp nhận dạng kết nối OpenID (OIDC) và Nhà cung cấp OAuth 2.0 với Trình kết nối có thể cắm.

Trả lời từ bài này vonc

Tôi sẽ trả lời câu hỏi này một chút khác nhau, và tôi sẽ rất chính xác và ngắn gọn, chủ yếu là vì @Peter T đã trả lời tất cả.

Lợi ích chính mà tôi thấy từ tiêu chuẩn này là tôn trọng hai nguyên tắc:

1. Tách biệt mối quan tâm.
2. Xác thực tách từ ứng dụng web, thường phục vụ kinh doanh.

Bằng cách làm như vậy,

1. Bạn có thể triển khai thay thế cho Đăng nhập một lần: Nếu bạn có nhiều ứng dụng tin tưởng một STS. Ý tôi là, một tên người dùng cho tất cả các ứng dụng.
2. Bạn có thể kích hoạt ứng dụng web của mình (Máy khách) để truy cập các tài nguyên thuộc về người dùng và không thuộc về ứng dụng web (Máy khách).
3. Bạn có thể ủy thác quy trình xác thực cho bên thứ ba mà bạn tin tưởng và không bao giờ lo lắng về xác thực tính xác thực của người dùng.