bí mật khách hàng trong OAuth 2.0

Để sử dụng google drive api, tôi phải thử xác thực bằng OAuth2.0. Và tôi có một vài câu hỏi về điều này.

1. Id ứng dụng khách và bí mật khách hàng được sử dụng để xác định ứng dụng của tôi là gì. Nhưng chúng phải được mã hóa cứng nếu đó là một ứng dụng khách. Vì vậy, mọi người có thể dịch ngược ứng dụng của tôi và trích xuất chúng từ mã nguồn. Nó có nghĩa là một ứng dụng xấu có thể giả vờ là một ứng dụng tốt bằng cách sử dụng id và bí mật của ứng dụng tốt? Vì vậy, người dùng sẽ hiển thị một màn hình yêu cầu cấp quyền cho một ứng dụng tốt mặc dù nó thực sự được yêu cầu bởi một ứng dụng xấu? Nếu có, tôi phải làm gì? Hay thực sự tôi không nên lo lắng về điều này?

2. Trong ứng dụng di động, chúng tôi có thể nhúng chế độ xem web vào ứng dụng của mình. Và rất dễ dàng để trích xuất trường mật khẩu trong webview vì ứng dụng yêu cầu quyền thực sự là một "trình duyệt". Vì vậy, OAuth trong ứng dụng di động không có lợi ích mà ứng dụng khách không có quyền truy cập vào thông tin người dùng của nhà cung cấp dịch vụ?

Tôi bắt đầu viết bình luận cho câu hỏi của bạn nhưng sau đó phát hiện ra có quá nhiều điều để nói vì vậy đây là quan điểm của tôi về chủ đề trong câu trả lời.

1. Có, có một khả năng thực sự cho điều này và đã có một số khai thác dựa trên điều này. Đề xuất là không giữ bí mật ứng dụng trong ứng dụng của bạn, thậm chí có một phần trong thông số kỹ thuật cho rằng các ứng dụng được phân phối không nên sử dụng mã thông báo này. Bây giờ bạn có thể yêu cầu, nhưng XYZ yêu cầu nó để hoạt động. Trong trường hợp đó, họ không triển khai đúng thông số kỹ thuật và bạn A không nên sử dụng dịch vụ đó (không có khả năng xảy ra) hoặc B cố gắng bảo mật mã thông báo bằng một số phương pháp làm xáo trộn để khiến việc tìm hoặc sử dụng máy chủ của bạn làm proxy khó hơn.

   Ví dụ: có một số lỗi trong thư viện Facebook dành cho Android khiến nó bị rò rỉ mã thông báo vào Nhật ký, bạn có thể tìm hiểu thêm về nó tại đây http://attack-secure.com/all-your-facebook-access-tokens-are-belong -to-us và tại đây https://www.youtube.com/watch?v=twyL7Uxe6sk . Nói chung, hãy hết sức thận trọng đối với việc sử dụng thư viện của bên thứ ba (thực ra là cảm giác thông thường nhưng nếu việc xâm nhập mã thông báo là mối quan tâm lớn của bạn, hãy thêm một điều nữa cần thận trọng).

2. Tôi đã nói về điểm 2 trong một thời gian khá dài. Tôi thậm chí đã thực hiện một số cách giải quyết trong ứng dụng của mình để sửa đổi các trang đồng ý (ví dụ: thay đổi thu phóng và thiết kế để phù hợp với ứng dụng) nhưng không có gì ngăn cản tôi đọc các giá trị từ các trường bên trong chế độ xem web bằng tên người dùng và mật khẩu. Do đó, tôi hoàn toàn đồng ý với quan điểm thứ hai của bạn và thấy đó là một "lỗi" lớn trong thông số kỹ thuật OAuth. Việc "Ứng dụng không có quyền truy cập thông tin đăng nhập của người dùng" trong thông số kỹ thuật chỉ là một giấc mơ và mang lại cho người dùng cảm giác an toàn sai lầm ... Ngoài ra, tôi đoán mọi người thường nghi ngờ khi ứng dụng yêu cầu họ cung cấp thông tin đăng nhập Facebook, Twitter, Dropbox hoặc các thông tin khác. Tôi nghi ngờ rằng nhiều người bình thường đọc thông số kỹ thuật của OAuth và nói "Bây giờ tôi đã an toàn" nhưng thay vào đó họ sử dụng cách hiểu thông thường và thường không sử dụng các ứng dụng mà họ không tin tưởng.

Tôi đã có câu hỏi tương tự như câu hỏi 1 ở đây, và gần đây đã tự mình nghiên cứu, và kết luận của tôi là không giữ bí mật cho "thân chủ" là điều có thể. Loại khách hàng không giữ bí mật về bí mật của khách hàng được gọi là "khách hàng công khai" trong đặc tả OAuth2. Khả năng một người nào đó xấu có thể lấy mã ủy quyền và sau đó truy cập mã thông báo, được ngăn chặn bởi các sự kiện sau.

1. Khách hàng cần nhận mã ủy quyền trực tiếp từ người dùng, không phải từ dịch vụ

Ngay cả khi người dùng cho biết dịch vụ mà anh / cô ấy tin tưởng khách hàng, thì khách hàng không thể lấy mã ủy quyền từ dịch vụ chỉ bằng cách hiển thị id khách hàng và bí mật của khách hàng. Thay vào đó, khách hàng phải lấy mã ủy quyền trực tiếp từ người dùng. (Điều này thường được thực hiện bằng cách chuyển hướng URL, mà tôi sẽ nói sau.) Vì vậy, đối với ứng dụng khách độc hại, việc biết id / bí mật của ứng dụng khách được người dùng tin cậy là chưa đủ. Nó phải liên quan đến hoặc giả mạo người dùng bằng cách nào đó để cung cấp cho nó mã ủy quyền, điều này sẽ khó hơn là chỉ biết id / bí mật của khách hàng.

2. URL chuyển hướng được đăng ký với id / bí mật của khách hàng

Giả sử rằng ứng dụng khách độc hại bằng cách nào đó đã quản lý để liên quan đến người dùng và khiến họ nhấp vào nút "Cho phép ứng dụng này" trên trang dịch vụ. Thao tác này sẽ kích hoạt phản hồi chuyển hướng URL từ dịch vụ đến trình duyệt của người dùng với mã ủy quyền đi kèm. Sau đó, mã ủy quyền sẽ được gửi từ trình duyệt của người dùng đến URL chuyển hướng và khách hàng phải lắng nghe URL chuyển hướng để nhận mã ủy quyền. (URL chuyển hướng cũng có thể là localhost và tôi nhận thấy rằng đây là cách điển hình mà “máy khách công cộng” nhận mã ủy quyền.) Vì URL chuyển hướng này được đăng ký tại dịch vụ bằng id / secret của máy khách, nên máy khách độc hại không có một cách để kiểm soát nơi mã ủy quyền được cấp.

Trả lời câu hỏi thứ 2: Các API của Google vì lý do bảo mật yêu cầu không thể thực hiện xác thực / đăng nhập trong chính Ứng dụng (chẳng hạn như không được phép xem web) và cần được thực hiện bên ngoài ứng dụng bằng Trình duyệt để bảo mật tốt hơn, được giải thích thêm bên dưới: https: //developers.googleblog.com/2016/08/moderizing-oauth-interaction-in-native-apps.html