Trang này trình bày một số phương pháp hay nhất chung để tích hợp với OAuth 2.0. Ngoài mọi hướng dẫn cụ thể cho loại ứng dụng và nền tảng phát triển của bạn, hãy cân nhắc các phương pháp hay nhất này. Bạn cũng nên tham khảo lời khuyên để chuẩn bị ứng dụng cho giai đoạn sản xuất và chính sách về OAuth 2.0 của Google.
Xử lý thông tin đăng nhập của ứng dụng một cách an toàn
Thông tin đăng nhập của ứng dụng OAuth xác định danh tính của ứng dụng và bạn cần xử lý thông tin này một cách cẩn thận. Chỉ lưu trữ thông tin đăng nhập này trong bộ nhớ an toàn, chẳng hạn như sử dụng trình quản lý thông tin bí mật như Google Cloud Secret Manager. Không cố định giá trị trong mã thông tin đăng nhập, tải thông tin đăng nhập lên kho lưu trữ mã hoặc công bố công khai thông tin đăng nhập.
Xử lý mã thông báo của người dùng một cách an toàn
Mã thông báo của người dùng bao gồm cả mã làm mới và mã truy cập do ứng dụng của bạn sử dụng. Lưu trữ mã thông báo một cách an toàn khi không sử dụng và không bao giờ truyền mã thông báo ở dạng văn bản thuần tuý. Sử dụng hệ thống lưu trữ an toàn phù hợp với nền tảng của bạn, chẳng hạn như Keystore trên Android, Dịch vụ chuỗi khoá trên iOS và macOS hoặc Credential Locker trên Windows.
Thu hồi mã thông báo ngay khi không còn cần thiết và xoá vĩnh viễn mã thông báo khỏi hệ thống.
Ngoài ra, hãy cân nhắc các phương pháp hay nhất sau đây cho nền tảng của bạn:
- Đối với các ứng dụng phía máy chủ lưu trữ mã thông báo cho nhiều người dùng, hãy mã hoá mã thông báo khi không sử dụng và đảm bảo rằng kho lưu trữ dữ liệu của bạn không thể truy cập công khai vào Internet.
- Đối với các ứng dụng dành cho máy tính gốc, bạn nên sử dụng giao thức Khoá bằng chứng để trao đổi mã (PKCE) để lấy mã uỷ quyền có thể được trao đổi để lấy mã truy cập.
Xử lý việc thu hồi và hết hạn mã làm mới
Nếu ứng dụng của bạn đã yêu cầu mã làm mới để truy cập khi không có mạng, thì bạn cũng phải xử lý việc vô hiệu hoá hoặc hết hạn mã làm mới. Mã thông báo có thể bị vô hiệu hoá vì nhiều lý do, chẳng hạn như mã thông báo có thể đã hết hạn hoặc quyền truy cập của ứng dụng có thể đã bị người dùng hoặc quy trình tự động thu hồi. Trong trường hợp này, hãy cân nhắc kỹ cách ứng dụng của bạn nên phản hồi, bao gồm cả việc nhắc người dùng đăng nhập vào lần tiếp theo hoặc dọn dẹp dữ liệu của họ. Để được thông báo về việc thu hồi mã thông báo, hãy tích hợp với dịch vụ Bảo vệ nhiều tài khoản.
Sử dụng tính năng uỷ quyền từng phần
Sử dụng tính năng uỷ quyền từng phần để yêu cầu các phạm vi OAuth thích hợp khi ứng dụng của bạn cần chức năng này.
Bạn không nên yêu cầu quyền truy cập vào dữ liệu khi người dùng xác thực lần đầu, trừ phi việc này là cần thiết cho chức năng cốt lõi của ứng dụng. Thay vào đó, chỉ yêu cầu các phạm vi cụ thể cần thiết cho một tác vụ, tuân theo nguyên tắc chọn các phạm vi nhỏ nhất và hạn chế nhất có thể.
Luôn yêu cầu phạm vi trong bối cảnh để giúp người dùng hiểu lý do ứng dụng của bạn yêu cầu quyền truy cập và cách dữ liệu sẽ được sử dụng.
Ví dụ: ứng dụng của bạn có thể tuân theo mô hình này:
- Người dùng xác thực bằng ứng dụng của bạn
- Không có phạm vi bổ sung nào được yêu cầu. Ứng dụng cung cấp chức năng cơ bản để cho phép người dùng khám phá và sử dụng các tính năng không yêu cầu bất kỳ dữ liệu hoặc quyền truy cập bổ sung nào.
- Người dùng chọn một tính năng yêu cầu quyền truy cập vào dữ liệu bổ sung
- Ứng dụng của bạn đưa ra yêu cầu uỷ quyền cho phạm vi OAuth cụ thể này cần thiết cho tính năng này. Nếu tính năng này yêu cầu nhiều phạm vi, hãy làm theo các phương pháp hay nhất bên dưới.
- Nếu người dùng từ chối yêu cầu, ứng dụng sẽ tắt tính năng này và cung cấp cho người dùng thêm thông tin để yêu cầu quyền truy cập lại.
Xử lý sự đồng ý cho nhiều phạm vi
Khi yêu cầu nhiều phạm vi cùng một lúc, người dùng có thể không cấp tất cả các phạm vi OAuth mà bạn đã yêu cầu. Ứng dụng của bạn nên xử lý việc từ chối phạm vi bằng cách tắt chức năng có liên quan.
Nếu chức năng cơ bản của ứng dụng yêu cầu nhiều phạm vi, hãy giải thích điều này cho người dùng trước khi nhắc họ đồng ý.
Bạn chỉ có thể nhắc lại người dùng khi họ đã nêu rõ ý định sử dụng tính năng cụ thể yêu cầu phạm vi đó. Ứng dụng của bạn nên cung cấp cho người dùng bối cảnh liên quan và lý do trước khi yêu cầu phạm vi OAuth.
Bạn nên giảm thiểu số lượng phạm vi mà ứng dụng của bạn yêu cầu cùng một lúc. Thay vào đó, hãy sử dụng tính năng uỷ quyền từng phần để yêu cầu phạm vi trong bối cảnh của các tính năng và chức năng.
Sử dụng trình duyệt an toàn
Trên web, các yêu cầu uỷ quyền OAuth 2.0 chỉ được thực hiện từ các trình duyệt web có đầy đủ tính năng. Trên các nền tảng khác, hãy nhớ chọn đúng loại ứng dụng OAuth và tích hợp OAuth cho phù hợp với nền tảng của bạn. Không chuyển hướng yêu cầu thông qua môi trường duyệt web được nhúng bao gồm cả WebView trên các nền tảng di động, chẳng hạn như WebView trên Android hoặc WKWebView trên iOS. Thay vào đó, hãy sử dụng thư viện OAuth gốc hoặc tính năng Đăng nhập bằng Google cho nền tảng của bạn.
Tạo và định cấu hình ứng dụng OAuth theo cách thủ công
Để ngăn chặn hành vi lạm dụng, bạn không thể tạo hoặc sửa đổi ứng dụng OAuth theo phương thức lập trình. Bạn phải sử dụng Google Developers Console để xác nhận rõ ràng các điều khoản dịch vụ, định cấu hình ứng dụng OAuth và chuẩn bị cho quy trình xác minh OAuth.
Đối với quy trình làm việc tự động, hãy cân nhắc sử dụng tài khoản dịch vụ thay thế.
Xoá ứng dụng OAuth không dùng đến
Thường xuyên kiểm tra các ứng dụng OAuth 2.0 và chủ động xoá mọi ứng dụng không còn cần thiết cho ứng dụng của bạn hoặc đã trở nên lỗi thời. Việc để các ứng dụng không dùng đến được định cấu hình sẽ gây ra rủi ro bảo mật tiềm ẩn vì ứng dụng có thể bị sử dụng sai nếu thông tin đăng nhập của ứng dụng bị xâm phạm.
Để giảm thiểu thêm rủi ro từ các ứng dụng không dùng đến, các ứng dụng OAuth 2.0 không hoạt động trong sáu tháng sẽ tự động bị xoá.
Phương pháp hay nhất được đề xuất là không chờ xoá tự động mà chủ động xoá các ứng dụng không dùng đến. Phương pháp này giúp giảm thiểu bề mặt tấn công của ứng dụng và đảm bảo tính bảo mật tốt.