OAuth 2 khác với OAuth 1 như thế nào?

Nói một cách rất đơn giản, ai đó có thể giải thích sự khác biệt giữa OAuth 2 và OAuth 1 không?

Bây giờ OAuth 1 đã lỗi thời? Chúng ta có nên thực hiện OAuth 2 không? Tôi không thấy nhiều triển khai của OAuth 2; hầu hết vẫn đang sử dụng OAuth 1, điều này khiến tôi nghi ngờ OAuth 2 đã sẵn sàng để sử dụng. Là nó?

Eran Hammer-Lahav đã thực hiện một công việc tuyệt vời trong việc giải thích phần lớn sự khác biệt trong bài viết của mình Giới thiệu OAuth 2.0 . Tóm lại, đây là những khác biệt chính:

Nhiều luồng OAuth hơn cho phép hỗ trợ tốt hơn cho các ứng dụng không dựa trên trình duyệt. Đây là một chỉ trích chính chống lại OAuth từ các ứng dụng khách không dựa trên trình duyệt. Ví dụ: trong OAuth 1.0, các ứng dụng máy tính để bàn hoặc ứng dụng điện thoại di động phải hướng người dùng mở trình duyệt của họ tới dịch vụ mong muốn, xác thực với dịch vụ và sao chép mã thông báo từ dịch vụ trở lại ứng dụng. Những lời chỉ trích chính ở đây là chống lại trải nghiệm người dùng. Với OAuth 2.0, giờ đây có những cách mới để ứng dụng nhận ủy quyền cho người dùng.

OAuth 2.0 không còn yêu cầu các ứng dụng khách phải có mật mã. Điều này giúp quay trở lại API Auth API cũ, vốn không yêu cầu ứng dụng mã thông báo băm HMAC và chuỗi yêu cầu. Với OAuth 2.0, ứng dụng có thể thực hiện yêu cầu chỉ sử dụng mã thông báo đã phát hành qua HTTPS.

Chữ ký OAuth 2.0 ít phức tạp hơn nhiều. Không có phân tích, phân loại hoặc mã hóa đặc biệt hơn.

Mã thông báo truy cập OAuth 2.0 là "ngắn hạn". Thông thường, mã thông báo truy cập OAuth 1.0 có thể được lưu trữ trong một năm hoặc hơn (Twitter không bao giờ để chúng hết hạn). OAuth 2.0 có khái niệm về mã thông báo làm mới. Mặc dù tôi không hoàn toàn chắc chắn đây là những gì, tôi đoán là mã thông báo truy cập của bạn có thể tồn tại trong thời gian ngắn (tức là dựa trên phiên) trong khi mã thông báo làm mới của bạn có thể là "thời gian sống". Bạn sẽ sử dụng mã thông báo làm mới để có được mã thông báo truy cập mới thay vì người dùng ủy quyền lại cho ứng dụng của bạn.

Cuối cùng, OAuth 2.0 có nghĩa là có sự phân tách rõ ràng về vai trò giữa máy chủ chịu trách nhiệm xử lý các yêu cầu OAuth và máy chủ xử lý ủy quyền người dùng. Thông tin thêm về điều đó được chi tiết trong bài viết nói trên.

Tôi thấy những câu trả lời tuyệt vời ở đây nhưng những gì tôi bỏ lỡ là một số sơ đồ và vì tôi phải làm việc với Spring Framework, tôi đã xem qua lời giải thích của họ .

Tôi thấy các sơ đồ sau rất hữu ích. Chúng minh họa sự khác biệt trong giao tiếp giữa các bên với OAuth2 và OAuth1.

OAuth 2

Ôi 1

Các giải thích trước đây đều là IMO quá chi tiết và phức tạp. Nói một cách đơn giản, OAuth 2 ủy quyền bảo mật cho giao thức HTTPS. OAuth 1 không yêu cầu điều này và do đó có các phương pháp thay thế để đối phó với các cuộc tấn công khác nhau. Các phương pháp này yêu cầu ứng dụng tham gia vào các giao thức bảo mật nhất định rất phức tạp và có thể khó thực hiện. Do đó, đơn giản hơn là chỉ dựa vào HTTPS để bảo mật để các nhà phát triển ứng dụng không cần phải lo lắng về điều đó.

Đối với các câu hỏi khác của bạn, câu trả lời phụ thuộc. Một số dịch vụ không muốn yêu cầu sử dụng HTTPS, đã được phát triển trước OAuth 2 hoặc có một số yêu cầu khác có thể ngăn chúng sử dụng OAuth 2. Hơn nữa, đã có rất nhiều tranh luận về chính giao thức OAuth 2. Như bạn có thể thấy, Facebook, Google và một vài người khác đều có các phiên bản giao thức được thay đổi một chút. Vì vậy, một số người gắn bó với OAuth 1 vì nó đồng đều hơn trên các nền tảng khác nhau. Gần đây, giao thức OAuth 2 đã được hoàn thiện nhưng chúng ta vẫn chưa thấy việc áp dụng nó sẽ diễn ra như thế nào.

Lưu ý rằng có các đối số bảo mật nghiêm trọng đối với việc sử dụng Oauth 2:

một bài báo ảm đạm

và một kỹ thuật hơn

Lưu ý những điều này đến từ tác giả chính của Oauth 2.

Những điểm chính:

• Oauth 2 không cung cấp bảo mật trên SSL trong khi Oauth 1 không phụ thuộc vào vận chuyển.

• Theo một nghĩa nào đó, SSL không an toàn ở chỗ máy chủ không xác minh kết nối và các thư viện máy khách phổ biến giúp bạn dễ dàng bỏ qua các lỗi.

  Vấn đề với SSL / TLS, là khi bạn không xác minh chứng chỉ ở phía máy khách, kết nối vẫn hoạt động. Bất cứ khi nào bỏ qua một lỗi dẫn đến thành công, các nhà phát triển sẽ làm điều đó. Máy chủ không có cách nào để thực thi xác minh chứng chỉ và thậm chí nếu có thể, kẻ tấn công chắc chắn sẽ không.

• bạn có thể loại bỏ tất cả các bảo mật của mình, điều này khó thực hiện hơn trong OAuth 1.0:

  Vấn đề tiềm năng phổ biến thứ hai là lỗi chính tả. Bạn có xem nó là một thiết kế phù hợp khi bỏ qua một ký tự ('s' trong 'https') làm trống toàn bộ bảo mật của mã thông báo không? Hoặc có thể gửi yêu cầu (qua kết nối SSL / TLS hợp lệ và được xác minh) đến đích sai (giả sử ' http://gacebook.com '?). Hãy nhớ rằng, việc có thể sử dụng mã thông báo mang OAuth từ dòng lệnh rõ ràng là một trường hợp sử dụng mã thông báo mang mã thông báo được sử dụng.

Bảo mật của giao thức OAuth 1.0 ( RFC 5849 ) dựa trên giả định rằng một khóa bí mật được nhúng trong ứng dụng khách có thể được giữ bí mật. Tuy nhiên, giả định là ngây thơ.

Trong OAuth 2.0 ( RFC 6749 ), một ứng dụng khách ngây thơ như vậy được gọi là ứng dụng khách bí mật . Mặt khác, một ứng dụng khách trong một môi trường khó giữ bí mật khóa bí mật được gọi là ứng dụng khách công khai . Xem 2.1. Các loại khách hàng để biết chi tiết.

Theo nghĩa đó, OAuth 1.0 là một đặc điểm kỹ thuật chỉ dành cho khách hàng bí mật.

" OAuth 2.0 và Đường xuống địa ngục " nói rằng OAuth 2.0 kém an toàn hơn, nhưng không có sự khác biệt thực tế về mức độ bảo mật giữa các máy khách OAuth 1.0 và máy khách bí mật OAuth 2.0. OAuth 1.0 yêu cầu tính toán chữ ký, nhưng nó không tăng cường bảo mật nếu đã được đảm bảo rằng một khóa bí mật ở phía máy khách có thể được giữ bí mật. Chữ ký điện toán chỉ là một tính toán cồng kềnh mà không có bất kỳ sự tăng cường bảo mật thực tế nào. Ý tôi là, so với sự đơn giản mà máy khách OAuth 2.0 kết nối với máy chủ qua TLS và chỉ trình bày client_idvà client_secret, không thể nói rằng tính toán cồng kềnh là tốt hơn về mặt bảo mật.

Ngoài ra, RFC 5849 (OAuth 1.0) không đề cập bất cứ điều gì về chuyển hướng mở trong khi RFC 6749 (OAuth 2.0) thì không. Đó là, oauth_callbacktham số của OAuth 1.0 có thể trở thành lỗ hổng bảo mật.

Do đó, tôi không nghĩ OAuth 1.0 an toàn hơn OAuth 2.0.

Bảo mật OAuth 1.0 dựa trên tính toán chữ ký. Chữ ký được tính bằng khóa bí mật trong đó khóa bí mật là khóa chung cho HMAC-SHA1 ( RFC 5849, 3.4.2 ) hoặc khóa riêng cho RSA-SHA1 ( RFC 5849, 3.4.3 ). Bất cứ ai biết khóa bí mật đều có thể tính chữ ký. Vì vậy, nếu khóa bí mật bị xâm phạm, sự phức tạp của tính toán chữ ký là vô nghĩa tuy nhiên nó phức tạp.

Điều này có nghĩa là bảo mật OAuth 1.0 không phụ thuộc vào độ phức tạp và logic tính toán chữ ký mà chỉ dựa vào tính bảo mật của khóa bí mật. Nói cách khác, những gì cần thiết cho bảo mật OAuth 1.0 chỉ là điều kiện để một khóa bí mật có thể được giữ bí mật. Điều này nghe có vẻ cực đoan, nhưng tính toán chữ ký không thêm sự tăng cường bảo mật nếu điều kiện đã được thỏa mãn.

Tương tự, các máy khách bí mật OAuth 2.0 cũng dựa trên cùng một điều kiện. Nếu điều kiện đã được thỏa mãn, có bất kỳ vấn đề nào trong việc tạo kết nối an toàn bằng TLS và gửi client_idvà client_secretđến một máy chủ ủy quyền thông qua kết nối được bảo mật không? Có sự khác biệt lớn về mức độ bảo mật giữa các máy khách bí mật OAuth 1.0 và OAuth 2.0 nếu cả hai đều dựa trên cùng một điều kiện không?

Tôi không thể tìm thấy bất kỳ lý do chính đáng nào để OAuth 1.0 đổ lỗi cho OAuth 2.0. Thực tế đơn giản là (1) OAuth 1.0 chỉ là thông số kỹ thuật chỉ dành cho khách hàng bí mật và (2) OAuth 2.0 đã đơn giản hóa giao thức cho khách hàng bí mật và khách hàng công cộng được hỗ trợ . Bất kể nó có được biết rõ hay không, các ứng dụng điện thoại thông minh được phân loại là máy khách công cộng ( RFC 6749, 9 ), được hưởng lợi từ OAuth 2.0.

Chữ ký OAuth 2.0 không bắt buộc đối với các lệnh gọi API thực tế sau khi mã thông báo được tạo. Nó chỉ có một mã thông báo bảo mật.

OAuth 1.0 yêu cầu khách hàng gửi hai mã thông báo bảo mật cho mỗi lệnh gọi API và sử dụng cả hai để tạo chữ ký. Nó yêu cầu các điểm cuối tài nguyên được bảo vệ có quyền truy cập vào thông tin đăng nhập của khách hàng để xác thực yêu cầu.

Ở đây mô tả sự khác biệt giữa OAuth 1.0 và 2.0 và cách cả hai hoạt động.

OAuth 2 rõ ràng là một sự lãng phí thời gian (từ miệng của một người có liên quan nhiều đến nó):

https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529

Ông nói (được chỉnh sửa cho ngắn gọn và in đậm để nhấn mạnh):

... Tôi không còn có thể được liên kết với tiêu chuẩn OAuth 2.0. Tôi đã từ bỏ vai trò là tác giả chính và biên tập viên, rút ​​tên của tôi khỏi đặc tả và rời khỏi nhóm làm việc. Xóa tên của tôi khỏi một tài liệu mà tôi đã làm việc chăm chỉ trong ba năm và hơn hai chục bản nháp là không dễ dàng. Quyết định tiến lên từ một nỗ lực mà tôi đã lãnh đạo trong hơn năm năm là đau đớn.

... Cuối cùng, tôi đã đi đến kết luận rằng OAuth 2.0 là một giao thức tồi. WS- * xấu. Nó đủ tệ đến mức tôi không còn muốn liên kết với nó nữa. ... Khi so sánh với OAuth 1.0, thông số kỹ thuật 2.0 phức tạp hơn, ít tương tác hơn, ít hữu ích hơn, không đầy đủ hơn và quan trọng nhất là kém an toàn hơn.

Để rõ ràng, OAuth 2.0 trong tay một nhà phát triển có hiểu biết sâu sắc về bảo mật web có thể sẽ dẫn đến việc triển khai an toàn. Tuy nhiên, dưới bàn tay của hầu hết các nhà phát triển - như đã có kinh nghiệm trong hai năm qua - 2.0 có khả năng tạo ra các triển khai không an toàn.

Nếu bạn cần một số giải thích nâng cao, bạn cần đọc cả hai thông số kỹ thuật:

https://oauth.net/core/1.0a/

https://oauth.net/2/

Nếu bạn cần một lời giải thích rõ ràng về sự khác biệt của dòng chảy, điều này có thể giúp bạn:

Lưu lượng OAuth 1.0

1. Đăng ký ứng dụng khách với nhà cung cấp, chẳng hạn như Twitter.
2. Twitter cung cấp cho khách hàng một bí mật dành cho người tiêu dùng, người dùng duy nhất trên ứng dụng đó.
3. Ứng dụng khách ký tất cả các yêu cầu OAuth lên Twitter với bí mật người tiêu dùng độc đáo của họ .
4. Nếu bất kỳ yêu cầu OAuth nào không đúng, thiếu dữ liệu hoặc được ký không đúng, yêu cầu sẽ bị từ chối.

Dòng chảy OAuth 2.0

1. Đăng ký ứng dụng khách với nhà cung cấp, chẳng hạn như Twitter.
2. Twitter cung cấp cho khách hàng một ứng dụng khách bí mật của người dùng, duy nhất cho ứng dụng đó.
3. Ứng dụng khách bao gồm các ứng dụng khách bí mật trực tuyến, với mọi yêu cầu thường là tiêu đề http.
4. Nếu bất kỳ yêu cầu OAuth nào không đúng định dạng, thiếu dữ liệu hoặc chứa bí mật sai, yêu cầu sẽ bị từ chối.

Nguồn: https://codiscope.com/oauth-2-0-vs-oauth-1-0/

OAuth 2.0 hứa hẹn sẽ đơn giản hóa mọi thứ theo các cách sau:

1. SSL là bắt buộc cho tất cả các giao tiếp cần thiết để tạo mã thông báo. Đây là một sự giảm sút lớn về độ phức tạp vì những chữ ký phức tạp đó không còn cần thiết nữa.
2. Chữ ký không bắt buộc đối với các lệnh gọi API thực tế sau khi mã thông báo đã được tạo - SSL cũng được khuyến nghị mạnh mẽ ở đây.
3. Khi mã thông báo được tạo, OAuth 1.0 yêu cầu khách hàng gửi hai mã thông báo bảo mật trên mỗi lệnh gọi API và sử dụng cả hai để tạo chữ ký. OAuth 2.0 chỉ có một mã thông báo bảo mật và không yêu cầu chữ ký.
4. Nó được chỉ định rõ ràng phần nào của giao thức được "chủ sở hữu tài nguyên" triển khai, đó là máy chủ thực tế thực hiện API và phần nào có thể được thực hiện bởi một "máy chủ ủy quyền" riêng biệt. Điều đó sẽ giúp các sản phẩm như Apigee cung cấp hỗ trợ OAuth 2.0 dễ dàng hơn cho các API hiện có.

Nguồn: http://blog.apigee.com/detail/oauth_differences

Từ quan điểm bảo mật, tôi sẽ đi OAuth 1. Xem OAuth 2.0 và đường đến địa ngục

trích dẫn từ liên kết đó: "Nếu bạn hiện đang sử dụng 1.0 thành công, hãy bỏ qua 2.0. Nó không cung cấp giá trị thực trên 1.0 (Tôi đoán bây giờ các nhà phát triển khách hàng của bạn đã tìm ra chữ ký 1.0).

Nếu bạn chưa quen với không gian này và xem mình là chuyên gia bảo mật, hãy sử dụng 2.0 sau khi kiểm tra cẩn thận các tính năng của nó. Nếu bạn không phải là chuyên gia, hãy sử dụng 1.0 hoặc sao chép triển khai 2.0 của nhà cung cấp mà bạn tin tưởng để làm cho đúng (tài liệu API của Facebook là một nơi tốt để bắt đầu). 2.0 tốt hơn cho quy mô lớn, nhưng nếu bạn đang điều hành một hoạt động lớn, có lẽ bạn có một số chuyên gia bảo mật trên trang web để tìm ra tất cả cho bạn. "