Trang này trình bày một số phương pháp hay nhất nói 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. Ngoài ra, hãy tham khảo lời khuyên để chuẩn bị ứng dụng cho giai đoạn phát hành công khai 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ữ những thông tin đăng nhập này trong bộ nhớ an toàn, chẳng hạn như sử dụng một trình quản lý bí mật như Google Cloud Secret Manager. Đừng mã hoá cứng thông tin đăng nhập, xác nhận thông tin đăng nhập vào kho lưu trữ mã hoặc xuất bản thông tin đăng nhập công khai.
Xử lý mã thông báo người dùng một cách an toàn
Mã thông báo người dùng bao gồm cả mã làm mới và mã truy cập mà ứ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ưới 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ư Kho khoá 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 bạn không cần dùng nữa 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á các mã thông báo đó khi không hoạt động và đảm bảo rằng kho 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, 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.
Mã thông báo ràng buộc người gửi bằng DPoP
Để bảo vệ ứng dụng của bạn khỏi hành vi đánh cắp mã thông báo và các cuộc tấn công phát lại, hãy cân nhắc việc hạn chế người gửi mã thông báo bằng cách sử dụng DPoP (Chứng minh quyền sở hữu). Mặc dù mọi bên chặn được mã thông báo Bearer tiêu chuẩn đều có thể sử dụng mã thông báo này, nhưng mã thông báo DPoP được liên kết bằng mật mã với một cặp khoá duy nhất do máy khách tạo và giữ.
Khi sử dụng DPoP, ứng dụng khách sẽ xuất trình bằng chứng (Mã thông báo web JSON đã ký) cho điểm cuối mã thông báo khi yêu cầu hoặc làm mới mã thông báo. Bằng chứng này cho thấy rằng ứng dụng khách đang sở hữu khoá riêng tư tương ứng với khoá công khai được liên kết với mã thông báo. Nếu mã làm mới được liên kết với DPoP bị rò rỉ, kẻ tấn công không thể phát lại mã đó nếu không có khoá riêng tư.
DPoP hoạt động cùng với PKCE để mang đến khả năng bảo vệ toàn diện:
- PKCE bảo vệ mã uỷ quyền trong quy trình chuyển hướng ban đầu.
- DPoP bảo vệ mã làm mới có thời hạn sử dụng dài, ngăn chặn các cuộc tấn công phát lại nếu mã này bị xâm phạm.
Bạn nên áp dụng DPoP nếu ứng dụng của bạn:
- Hoạt động như một ứng dụng khách công khai (chẳng hạn như ứng dụng trang đơn hoặc ứng dụng cần cài đặt) trong đó mã làm mới có thể dễ bị đánh cắp hơn.
- Truy cập vào dữ liệu nhạy cảm cao hoặc các API có giá trị cao, trong đó tác động của việc rò rỉ mã thông báo là đáng kể.
- Cần đáp ứng các tiêu chuẩn nghiêm ngặt về việc tuân thủ hoặc bảo mật, bắt buộc phải có mã thông báo bị giới hạn đối với người gửi.
Để biết hướng dẫn chi tiết về cách tạo bằng chứng DPoP và yêu cầu mã thông báo liên kết với DPoP, hãy tham khảo tài liệu về DPoP.
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 đ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 một tập lệnh độc hại) đang đưa ra 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 để truy cập khi không có mạng, bạn cũng phải xử lý việc mã này bị vô hiệu hoá hoặc hết hạn. 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 đã hết hạn hoặc người dùng hoặc một quy trình tự động đã thu hồi quyền truy cập của ứng dụng. 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 ở lần đăng nhập tiếp theo hoặc dọn dẹp dữ liệu của họ. Để nhận 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 gia tăng
Sử dụng uỷ quyền gia tăng để 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 đó, hãy chỉ yêu cầu các phạm vi cụ thể cần thiết cho một tác vụ, theo nguyên tắc chọn 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 rõ 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 yêu cầu thêm phạm vi nào khác. Ứ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 cần có 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 (bắt buộc đối với 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 cho nhiều phạm vi.
- 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 cấp quyền 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 phải 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ọ đã cho thấy 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 phải cung cấp cho người dùng bối cảnh và lý do chính đáng có liên quan 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 uỷ quyền gia tăng để yêu cầu các phạm vi trong ngữ 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, bạn chỉ được đưa ra yêu cầu uỷ quyền OAuth 2.0 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 các 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 được đề xuất hoặc Đă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 khách OAuth theo cách thủ công
Để ngăn chặn hành vi sai trái, bạn không thể tạo hoặc sửa đổi ứng dụng OAuth theo cách lập trình. Bạn phải sử dụng bảng điều khiển Cloud để 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 tự động, hãy cân nhắc sử dụng tài khoản dịch vụ.
Xoá các ứ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 đã lỗi thời. Việc để lại 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 ứng dụng của bạn bị xâm phạm.
Để giảm thiểu hơn nữa rủi ro từ các ứng dụng không dùng đến, những ứng dụng OAuth 2.0 không hoạt động trong 6 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.