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. Hãy cân nhắc những phương pháp hay nhất này 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. Bạn cũng nên tham khảo lời khuyên để chuẩn bị ứng dụng cho quá trình 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 nên xử lý 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 mã hoá cứng thông tin đăng nhập, cam kết thông tin đăng nhập với 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 hoạt độ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 của bạn.
Ngoài ra, hãy cân nhắc những 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 hoạt độ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 gốc dành cho máy tính, 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.
Sử dụng tham số trạng thái
Trước khi xử lý phản hồi OAuth 2.0, hãy xác nhận rằng state nhận được từ
Google khớp với state được gửi trong yêu cầu uỷ quyền của bạn. Tham số
state phải là một giá trị duy nhất, không thể đoán được do ứng dụng của bạn tạo.
Việc sử dụng tham số state giúp đảm bảo rằng người dùng (chứ không phải tập lệnh độc hại) đang thực hiện yêu cầu và giảm nguy cơ tấn công Giả mạo yêu cầu trên nhiều trang web
(CSRF).
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 refresh để 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ệ trên 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 điều 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 để 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 bối cảnh để 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 người dùng một lần nữa sau khi họ đã cho biết 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 có liên quan và lý do chính đáng 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 ứ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 để lại các ứng dụng không dùng đến đã đị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 đợi hệ thống tự động xoá 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 vệ sinh bảo mật tốt.