Các phương pháp hay nhất

Xử lý thông tin đăng nhập của ứng dụng khách một cách an toàn

Thông tin xác thực ứng dụng OAuth xác định danh tính của ứng dụng và cần được xử lý cẩn thận. Chỉ lưu trữ những thông tin đăng nhập này trong bộ nhớ bảo mật, chẳng hạn như sử dụng trình quản lý bí mật như Trình quản lý bí mật của Google Cloud. Đừng cố định giá trị thông tin xác thực trong mã, đừng đưa thông tin xác thực vào kho lưu trữ mã hoặc công bố công khai.

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 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 ở trạng thái tĩnh và không bao giờ truyền mã thông báo dưới dạng văn bản thuần túy. 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 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 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á 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 qua Internet.
• Đối với ứ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ể đổ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à tấn công phát lại, hãy cân nhắc việc ràng buộc 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ù bất kỳ bên nào chặn được mã thông báo truy cập tiêu chuẩn đều có thể sử dụng mã thông báo đó, 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 ứng dụng tạo và lưu giữ.

Khi sử dụng DPoP, ứng dụng khách sẽ cung cấp 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ã làm mới. Bằng chứng này cho thấy ứng dụng khách 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 liên kết với DPoP bị rò rỉ, thì 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 để cung cấp 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 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 đã cài đặt hoặc ứng dụng dành cho máy tính (hoặc một ứng dụng trang đơn được ghép nối với máy chủ Backend-for-Frontend), trong đó mã làm mới có thể dễ bị rò rỉ hơn.
• Truy cập vào dữ liệu có độ nhạy cảm cao hoặc API có giá trị cao, nơi mà việc rò rỉ mã thông báo có tác động đáng kể.
• Cần đáp ứng các tiêu chuẩn nghiêm ngặt về bảo mật hoặc tuân thủ, trong đó bắt buộc phải có mã thông báo do người gửi ràng buộc.

Để 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 Hướng dẫn sử dụng DPoP.

Sử dụng tham số state

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 ra.

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 đưa ra yêu cầu, đồng thời giảm nguy cơ xảy ra các cuộ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 để xem không cần mạng, thì bạn cũng phải xử lý trường hợp mã này không hợp lệ hoặc hết hạn. Mã thông báo có thể bị vô hiệu hoá vì nhiều lý do, ví dụ: 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 một 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 phản hồi, bao gồm cả việc nhắc người dùng trong 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 quy trình uỷ quyền gia tăng

Sử dụng tính năng uỷ quyền gia tăng để yêu cầu 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ụ, theo nguyên tắc chọn phạm vi nhỏ nhất, 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 sau:

1. Người dùng xác thực bằng ứng dụng của bạn
   1. Không yêu cầu thêm phạm vi nào. Ứ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 thêm dữ liệu hoặc quyền truy cập.
2. 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
   1. Ứng dụng của bạn gửi yêu cầu uỷ quyền cho phạm vi OAuth cụ thể 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 cho nhiều phạm vi.
   2. 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ông tin bổ sung để 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ả 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 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 sau khi họ đã thể hiện rõ ý định sử dụng tính năng cụ thể cần có 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 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 yêu cầu cùng một lúc. Thay vào đó, hãy sử dụng quy trình uỷ quyền gia tăng để 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, bạn chỉ được gửi 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 sao 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 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 hoặc Đăng nhập bằng Google được đề xuất 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 sai trái, 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 Cloud 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 tự động, hãy cân nhắc sử dụng tài khoản dịch vụ.

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 mà ứng dụng của bạn không còn cần đến hoặc đã lỗi thời. Việc để các ứng dụng khách không dùng đến ở trạng thái đã định cấu hình có thể gây ra rủi ro bảo mật vì ứng dụng khách có thể bị sử dụng sai mục đích nếu thông tin đăng nhập của ứng dụng khách bị xâm phạm.

Để giảm thiểu rủi ro từ các ứng dụng khách không dùng đến, những ứng dụng khách 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. Cách 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.