Quy trình OAuth 2.0 phù hợp cho ứng dụng di động là gì

Tôi đang cố gắng triển khai ủy quyền được ủy quyền trong API Web dành cho ứng dụng di động bằng OAuth 2.0. Theo đặc điểm kỹ thuật, quy trình cấp ngầm không hỗ trợ mã thông báo làm mới, có nghĩa là sau khi mã thông báo truy cập được cấp trong một khoảng thời gian cụ thể, người dùng phải cấp lại quyền cho ứng dụng sau khi mã thông báo hết hạn hoặc bị thu hồi.

Tôi đoán đây là một kịch bản tốt cho một số mã javascript chạy trên trình duyệt vì nó được đề cập trong đặc tả. Tôi đang cố gắng giảm thiểu thời gian người dùng phải cấp quyền cho ứng dụng để lấy mã thông báo, vì vậy có vẻ như quy trình Mã ủy quyền là một lựa chọn tốt vì nó hỗ trợ mã thông báo làm mới.

Tuy nhiên, luồng này dường như phụ thuộc nhiều vào trình duyệt web để thực hiện chuyển hướng. Tôi đang tự hỏi liệu luồng này có còn là một lựa chọn tốt cho ứng dụng dành cho thiết bị di động hay không nếu sử dụng trình duyệt web nhúng. Hay tôi nên đi với dòng chảy ngầm?

Làm rõ: Mobile App = Ứng dụng gốc

Như đã nêu trong các nhận xét khác và một số nguồn trực tuyến, ngầm có vẻ như là một sự phù hợp tự nhiên cho các ứng dụng dành cho thiết bị di động, tuy nhiên giải pháp tốt nhất không phải lúc nào cũng rõ ràng (và trên thực tế, ẩn không được khuyến khích vì những lý do được thảo luận bên dưới).

Các phương pháp hay nhất về OAuth2 cho ứng dụng gốc

Dù bạn chọn cách tiếp cận nào (có một vài điểm cần cân nhắc), bạn nên chú ý đến các phương pháp hay nhất được nêu ở đây cho Ứng dụng gốc sử dụng OAuth2: https://tools.ietf.org/html/rfc8252

Xem xét các tùy chọn sau

Ngầm hiểu

Tôi có nên sử dụng ẩn?

Trích dẫn từ Phần 8.2 https://tools.ietf.org/html/rfc8252#section-8.2

Luồng ủy quyền cấp phép ngầm định của OAuth 2.0 (được định nghĩa trong Mục 4.2 của OAuth 2.0 [RFC6749]) thường hoạt động với thông lệ thực hiện yêu cầu ủy quyền trong trình duyệt và nhận phản hồi ủy quyền thông qua giao tiếp liên ứng dụng dựa trên URI.
Tuy nhiên, vì quy trình ngầm định không thể được bảo vệ bởi PKCE [RFC7636] (bắt buộc trong Phần 8.1), việc sử dụng Quy trình ngầm định với các ứng dụng gốc KHÔNG ĐƯỢC KHUYẾN CÁO .

Mã thông báo truy cập được cấp thông qua quy trình ngầm định cũng không thể được làm mới nếu không có sự tương tác của người dùng, làm cho quy trình cấp mã ủy quyền - có thể phát hành mã thông báo làm mới - tùy chọn thiết thực hơn cho các ủy quyền ứng dụng gốc yêu cầu làm mới mã thông báo truy cập.

Mã ủy quyền

Nếu bạn sử dụng Mã ủy quyền, thì một cách tiếp cận sẽ là ủy quyền thông qua thành phần máy chủ web của riêng bạn, giúp làm phong phú thêm các yêu cầu mã thông báo với bí mật của ứng dụng khách để tránh lưu trữ nó trên ứng dụng phân phối trên thiết bị.

Trích dưới đây từ: https://dev.fitbit.com/docs/oauth2/

Quy trình Cấp mã ủy quyền được khuyến nghị cho các ứng dụng có dịch vụ web. Luồng này yêu cầu giao tiếp giữa máy chủ với máy chủ bằng cách sử dụng bí mật máy khách của ứng dụng.

Lưu ý: Không bao giờ đặt bí mật máy khách của bạn trong mã được phân phối, chẳng hạn như các ứng dụng được tải xuống qua cửa hàng ứng dụng hoặc JavaScript phía máy khách.

Các ứng dụng không có dịch vụ web nên sử dụng quy trình Cấp quyền ngầm.

Phần kết luận

Quyết định cuối cùng phải phụ thuộc vào trải nghiệm người dùng mong muốn của bạn nhưng cũng là sự thèm muốn rủi ro của bạn sau khi thực hiện đánh giá rủi ro thích hợp về các phương pháp tiếp cận trong danh sách rút gọn của bạn và hiểu rõ hơn các tác động.

Một bài đọc tuyệt vời ở đây https://auth0.com/blog/oauth-2-best-practices-for-native-apps/

Một địa chỉ khác là https://www.oauth.com/oauth2-servers/oauth-native-apps/ cho biết

Phương pháp hay nhất trong ngành hiện tại là sử dụng Quy trình cấp phép trong khi bỏ qua bí mật của ứng dụng khách và sử dụng tác nhân người dùng bên ngoài để hoàn thành quy trình. Tác nhân người dùng bên ngoài thường là trình duyệt gốc của thiết bị, (với miền bảo mật riêng biệt với ứng dụng gốc,) để ứng dụng không thể truy cập vào kho lưu trữ cookie hoặc kiểm tra hoặc sửa đổi nội dung trang bên trong trình duyệt.

Cân nhắc PKCE

Bạn cũng nên xem xét PKCE được mô tả ở đây https://www.oauth.com/oauth2-servers/pkce/

Cụ thể, nếu bạn cũng đang triển khai Máy chủ ủy quyền thì https://www.oauth.com/oauth2-servers/oauth-native-apps/checklist-server-support-native-apps/ tuyên bố rằng bạn nên

• Cho phép khách hàng đăng ký lược đồ URL tùy chỉnh cho các URL chuyển hướng của họ.
• Hỗ trợ các URL chuyển hướng IP lặp lại với số cổng tùy ý để hỗ trợ các ứng dụng dành cho máy tính để bàn.
• Đừng cho rằng các ứng dụng gốc có thể giữ bí mật. Yêu cầu tất cả các ứng dụng khai báo chúng là công khai hay bí mật và chỉ cấp bí mật của ứng dụng cho các ứng dụng bí mật.
• Hỗ trợ tiện ích mở rộng PKCE và yêu cầu khách hàng công khai sử dụng nó.
• Cố gắng phát hiện khi nào giao diện ủy quyền được nhúng trong chế độ xem web của ứng dụng gốc, thay vì khởi chạy trong trình duyệt hệ thống và từ chối những yêu cầu đó.

Xem xét lượt xem web

Có rất nhiều ví dụ về việc sử dụng Chế độ xem web tức là tác nhân người dùng được nhúng nhưng nên tránh cách tiếp cận này (đặc biệt khi ứng dụng không phải là bên thứ nhất) và trong một số trường hợp có thể dẫn đến việc bạn bị cấm sử dụng API dưới dạng đoạn trích bên dưới từ đây minh họa

Bất kỳ nỗ lực nào để nhúng trang xác thực OAuth 2.0 sẽ dẫn đến ứng dụng của bạn bị cấm khỏi API Fitbit.

Để xem xét bảo mật, trang ủy quyền OAuth 2.0 phải được hiển thị trong chế độ xem trình duyệt chuyên dụng. Người dùng Fitbit chỉ có thể xác nhận họ đang xác thực với trang Fitbit.com chính hãng nếu họ có các công cụ do trình duyệt cung cấp, chẳng hạn như thanh URL và thông tin chứng chỉ Bảo mật lớp truyền tải (TLS).

Đối với các ứng dụng gốc, điều này có nghĩa là trang ủy quyền phải mở trong trình duyệt mặc định. Các ứng dụng gốc có thể sử dụng lược đồ URL tùy chỉnh làm URI chuyển hướng để chuyển hướng người dùng trở lại từ trình duyệt đến ứng dụng yêu cầu quyền.

Các ứng dụng iOS có thể sử dụng lớp SFSafariViewController thay vì chuyển ứng dụng sang Safari. Việc sử dụng lớp WKWebView hoặc UIWebView bị cấm.

Các ứng dụng Android có thể sử dụng Tab tùy chỉnh của Chrome thay vì ứng dụng chuyển sang trình duyệt mặc định. Sử dụng WebView bị cấm.

Để làm rõ thêm, đây là trích dẫn từ phần này của bản nháp trước đó của liên kết phương pháp hay nhất được cung cấp ở trên

Tác nhân người dùng được nhúng, thường được triển khai với chế độ xem web, là một phương pháp thay thế để cấp phép cho các ứng dụng gốc. Tuy nhiên, chúng không an toàn cho các bên thứ ba sử dụng theo định nghĩa. Chúng liên quan đến việc người dùng đăng nhập bằng thông tin đăng nhập đầy đủ của họ, chỉ để họ giảm bớt thông tin đăng nhập OAuth kém mạnh mẽ hơn.

Ngay cả khi được sử dụng bởi các ứng dụng của bên thứ nhất đáng tin cậy, các tác nhân người dùng được nhúng vẫn vi phạm nguyên tắc ít đặc quyền nhất bằng cách có được thông tin xác thực mạnh hơn mức họ cần, có khả năng làm tăng nguy cơ tấn công.

Trong các triển khai dựa trên chế độ xem web điển hình của tác nhân người dùng được nhúng, ứng dụng chủ có thể: ghi lại mọi lần gõ phím được nhập vào biểu mẫu để nắm bắt tên người dùng và mật khẩu; tự động gửi biểu mẫu và bỏ qua sự đồng ý của người dùng; sao chép cookie phiên và sử dụng chúng để thực hiện các hành động được xác thực với tư cách là người dùng.

Khuyến khích người dùng nhập thông tin đăng nhập trong chế độ xem web được nhúng mà không có thanh địa chỉ thông thường và các tính năng nhận dạng khác mà trình duyệt có khiến người dùng không thể biết liệu họ có đang đăng nhập vào trang web hợp pháp hay không và ngay cả khi họ đang đăng nhập, nó sẽ đào tạo họ rằng bạn có thể nhập thông tin đăng nhập mà không cần xác thực trang web trước.

Ngoài các lo ngại về bảo mật, chế độ xem web không chia sẻ trạng thái xác thực với các ứng dụng khác hoặc trình duyệt hệ thống, yêu cầu người dùng đăng nhập cho mọi yêu cầu cấp quyền và dẫn đến trải nghiệm người dùng kém.

Do những điều trên, việc sử dụng tác nhân người dùng được nhúng KHÔNG ĐƯỢC KHUYẾN NGHỊ, ngoại trừ trường hợp ứng dụng của bên thứ nhất đáng tin cậy hoạt động như tác nhân người dùng bên ngoài cho các ứng dụng khác hoặc cung cấp đăng nhập một lần cho nhiều ứng dụng của bên thứ nhất.

Máy chủ ủy quyền NÊN xem xét thực hiện các bước để phát hiện và chặn thông tin đăng nhập thông qua tác nhân người dùng được nhúng không phải của chính chúng, nếu có thể.

Một số điểm thú vị cũng được nêu ra ở đây: /security/179756/why-are-developers-using-embedded-user-agents-for-3rd-party-auth-what-are-the- a

Thật không may, tôi không nghĩ rằng có một câu trả lời rõ ràng cho câu hỏi này. Tuy nhiên, đây là các tùy chọn mà tôi đã xác định:

• Nếu có thể yêu cầu người dùng cung cấp thông tin đăng nhập của họ, thì hãy sử dụng Thông tin đăng nhập mật khẩu chủ sở hữu tài nguyên . Tuy nhiên, điều này có thể không thực hiện được vì một số lý do, cụ thể là

  • Các chính sách về khả năng sử dụng hoặc bảo mật nghiêm cấm việc nhập mật khẩu trực tiếp tại ứng dụng
  • Quy trình xác thực được ủy quyền trên Nhà cung cấp danh tính bên ngoài và phải được thực hiện qua luồng dựa trên chuyển hướng HTTP (ví dụ: OpenID, SAMLP hoặc WS-Federation)

• Nếu bắt buộc phải sử dụng luồng dựa trên trình duyệt, thì hãy sử dụng Luồng mã ủy quyền . Ở đây, định nghĩa của redirect_urilà một thách thức lớn, có các tùy chọn sau:

  • Sử dụng kỹ thuật được mô tả trong https://developers.google.com/accounts/docs/OAuth2InstalledApp , nơi đặc biệt redirect_uri(ví dụ:urn:ietf:wg:oauth:2.0:oob ) báo hiệu điểm cuối ủy quyền để hiển thị mã ủy quyền thay vì chuyển hướng trở lại ứng dụng khách. Người dùng có thể sao chép mã này theo cách thủ công hoặc ứng dụng có thể cố gắng lấy nó từ tiêu đề tài liệu HTML.
  • Sử dụng localhostmáy chủ tại thiết bị (việc quản lý cổng có thể không dễ dàng).
  • Sử dụng lược đồ URI tùy chỉnh (ví dụ myapp://...) mà khi được tham chiếu đến sẽ kích hoạt "trình xử lý" đã đăng ký (chi tiết tùy thuộc vào nền tảng di động).
  • Nếu có, hãy sử dụng "chế độ xem web" đặc biệt, chẳng hạn như WebAuthenticationBroker trên Windows 8, để kiểm soát và truy cập các phản hồi chuyển hướng HTTP.

Hi vọng điêu nay co ich

Pedro

TL; DR: Sử dụng Cấp mã ủy quyền với PKCE

1. Loại tài trợ ngầm định

Loại tài trợ ngầm khá phổ biến với các ứng dụng di động. Nhưng nó không được sử dụng như thế này. Có những lo ngại về bảo mật xung quanh chuyển hướng. Justin Richer tuyên bố :

Vấn đề xảy ra khi bạn nhận ra rằng không giống như với URL máy chủ từ xa, không có cách nào đáng tin cậy để đảm bảo rằng ràng buộc giữa một URI chuyển hướng nhất định và một ứng dụng di động cụ thể được tuân thủ. Bất kỳ ứng dụng nào trên thiết bị cũng có thể cố gắng chèn chính nó vào quá trình chuyển hướng và khiến nó phân phát URI chuyển hướng. Và hãy đoán xem: nếu bạn đã sử dụng luồng ngầm trong ứng dụng gốc của mình, thì bạn vừa giao cho kẻ tấn công mã thông báo truy cập của mình. Không có sự phục hồi nào từ thời điểm đó - họ đã có mã thông báo và họ có thể sử dụng nó.

Và cùng với thực tế là nó không cho phép bạn làm mới mã thông báo truy cập, tốt hơn là hãy tránh nó.

2. Loại tài trợ mã ủy quyền

Việc cấp mã ủy quyền yêu cầu một bí mật của khách hàng. Nhưng bạn không nên lưu trữ thông tin nhạy cảm trong mã nguồn của ứng dụng dành cho thiết bị di động của mình. Mọi người có thể giải nén chúng. Để không tiết lộ bí mật của khách hàng, bạn phải chạy một máy chủ với tư cách là người trung gian Facebook viết :

Chúng tôi khuyên bạn chỉ nên sử dụng Mã truy cập ứng dụng trực tiếp từ máy chủ của ứng dụng của bạn để cung cấp bảo mật tốt nhất. Đối với các ứng dụng gốc, chúng tôi khuyên bạn nên giao tiếp ứng dụng với máy chủ của riêng bạn và sau đó máy chủ thực hiện các yêu cầu API tới Facebook bằng Mã truy cập ứng dụng.

Không phải là giải pháp lý tưởng nhưng có một cách mới, cách tốt hơn để thực hiện OAuth trên thiết bị di động: Proof Key cho Code Exchange

3. Loại cấp mã ủy quyền với PKCE (Khóa bằng chứng để trao đổi mã)

Ngoài những hạn chế, một kỹ thuật mới đã được tạo ra cho phép bạn sử dụng Mã ủy quyền mà không có bí mật khách hàng. Bạn có thể đọc RFC 7636 đầy đủ hoặc phần giới thiệu ngắn này .

PKCE (RFC 7636) là một kỹ thuật để bảo mật các máy khách công khai không sử dụng bí mật của máy khách.

Nó chủ yếu được sử dụng bởi các ứng dụng gốc và thiết bị di động, nhưng kỹ thuật này cũng có thể được áp dụng cho bất kỳ khách hàng công cộng nào. Nó yêu cầu hỗ trợ thêm bởi máy chủ ủy quyền, vì vậy nó chỉ được hỗ trợ trên một số nhà cung cấp nhất định.

từ https://oauth.net/2/pkce/

Sử dụng chế độ xem web trong ứng dụng di động của bạn sẽ là một cách hợp lý để triển khai giao thức OAuth2.0 trên nền tảng Android.

Đối với trường redirect_uri, tôi nghĩ http://localhostlà một lựa chọn tốt và bạn không phải chuyển máy chủ HTTP bên trong ứng dụng của mình, vì bạn có thể ghi đè việc triển khai onPageStartedchức năng trong WebViewClientlớp và ngừng tải trang web http://localhostsau khi bạn kiểm tra urltham số.

public void onPageStarted(final WebView webView, final String url,
        final Bitmap favicon) {}

Trải nghiệm người dùng mượt mà nhất để xác thực và dễ triển khai nhất là nhúng chế độ xem web vào ứng dụng của bạn. Xử lý phản hồi mà webview nhận được từ điểm xác thực và phát hiện lỗi (người dùng hủy) hoặc phê duyệt (và trích xuất mã thông báo từ các tham số truy vấn url). Và tôi nghĩ rằng bạn thực sự có thể làm điều đó trên tất cả các nền tảng. Tôi đã thực hiện thành công việc này cho những thứ sau: ứng dụng ios, android, mac, windows store 8.1, ứng dụng windows phone 8.1. Tôi đã làm điều này cho các dịch vụ sau: dropbox, google drive, onedrive, box, basecamp. Đối với các nền tảng không phải windows, tôi đang sử dụng Xamarin được cho là không hiển thị toàn bộ các API cụ thể của nền tảng, nhưng nó đã đủ để làm điều này trở nên khả thi. Vì vậy, nó là một giải pháp khá dễ tiếp cận, ngay cả từ góc độ đa nền tảng và bạn không