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 xác thực, xác nhận thông tin đó vào kho lưu trữ mã hoặc xuất bản thông tin đó 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ư 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 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 trên Internet.
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ể không hợp lệ vì nhiều lý do, chẳng hạn như mã thông báo đã 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 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. Ứ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 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 cấp 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 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 các 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 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 đư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 khách 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 các thư viện OAuth gốc 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 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ụ.
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 để các ứng dụng không dùng đến ở trạng thái đã định cấu hình sẽ gây ra nguy cơ 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.
[[["Dễ hiểu","easyToUnderstand","thumb-up"],["Giúp tôi giải quyết được vấn đề","solvedMyProblem","thumb-up"],["Khác","otherUp","thumb-up"]],[["Thiếu thông tin tôi cần","missingTheInformationINeed","thumb-down"],["Quá phức tạp/quá nhiều bước","tooComplicatedTooManySteps","thumb-down"],["Đã lỗi thời","outOfDate","thumb-down"],["Vấn đề về bản dịch","translationIssue","thumb-down"],["Vấn đề về mẫu/mã","samplesCodeIssue","thumb-down"],["Khác","otherDown","thumb-down"]],["Cập nhật lần gần đây nhất: 2025-08-31 UTC."],[[["\u003cp\u003eSecurely store and manage OAuth client credentials, avoiding hardcoding or public exposure.\u003c/p\u003e\n"],["\u003cp\u003eProtect user tokens (refresh and access) by storing them securely and revoking them when no longer needed.\u003c/p\u003e\n"],["\u003cp\u003eImplement proper handling of refresh token revocation and expiration scenarios, including user notification and data cleanup.\u003c/p\u003e\n"],["\u003cp\u003eUtilize incremental authorization to request only necessary OAuth scopes in context, minimizing initial requests and enhancing user privacy.\u003c/p\u003e\n"],["\u003cp\u003eEmploy secure browsing environments for OAuth authorization requests, avoiding embedded browsers like webviews and opting for native libraries or Google Sign-in.\u003c/p\u003e\n"]]],[],null,["This page covers some general best practices for integrating with OAuth 2.0. Consider these best\npractices in addition to any specific guidance for your type of application and development\nplatform. Also refer to the\n[advice for getting\nyour app ready for production](/identity/protocols/oauth2/production-readiness/policy-compliance) and [Google's\nOAuth 2.0 policies](/identity/protocols/oauth2/policies).\n\nHandle client credentials securely\n\n\nThe OAuth client credentials identify your app's identity and should be handled carefully. Only\nstore these credentials in secure storage, for example using a secret manager such as\n[Google Cloud Secret Manager](https://cloud.google.com/secret-manager/docs/overview).\nDo not hardcode the credentials, commit them to a code repository or publish them publicly.\n\nHandle user tokens securely\n\n\nUser tokens include both refresh tokens and access tokens used by your application. Store\ntokens securely [at rest](https://wikipedia.org/wiki/Data_at_rest)\nand never transmit them in plain text. Use a secure storage system appropriate for your\nplatform, such as\n[Keystore](https://developer.android.com/training/articles/keystore) on Android,\nKeychain Services on iOS and macOS, or Credential Locker on Windows.\n\n\n[Revoke tokens](/identity/protocols/oauth2/web-server#tokenrevoke) as soon as they\nare no longer needed and delete them permanently from your systems.\n\n\nIn addition, also consider these best practices for your platform:\n\n- For [server-side](/identity/protocols/oauth2/web-server) applications that store tokens for many users, encrypt them at rest and ensure that your data store is not publicly accessible to the Internet.\n- For native desktop apps, using the [Proof Key for Code\n Exchange (PKCE) protocol](/identity/protocols/oauth2/native-app#obtainingaccesstokens) is strongly recommended to obtain authorization codes that can be exchanged for access tokens.\n\nHandle refresh token revocation and expiration\n\n\nIf your app has requested a [refresh\ntoken for offline access](/identity/protocols/oauth2/web-server#offline), you must also handle their invalidation or expiration. Tokens\ncould be [invalidated for different reasons](/identity/protocols/oauth2#expiration),\nfor example it could have expired or your apps' access could have been revoked by the user or\nan automated process. In this case, consider carefully how your application should respond,\nincluding prompting the user at their next log in or cleaning up their data. To be notified of\ntoken revocation, integrate with the [Cross-Account\nProtection](/identity/protocols/risc) service.\n\nUse incremental authorization\n\n\nUse [incremental\nauthorization](/identity/protocols/oauth2/web-server#incrementalAuth) to request appropriate OAuth scopes when the functionality is needed by your\napplication.\n\n\nYou should not request access to data when the user first authenticates, unless it is essential\nfor the core functionality of your app. Instead, request only the specific scopes that are\nneeded for a task, following the principle to\n[select the smallest, most limited scopes possible](/identity/protocols/oauth2/production-readiness/policy-compliance#only-request-needed-scopes).\n\n\nAlways request scopes in context to help your users understand why your app is requesting access\nand how the data will be used.\n\n\nFor example, your application may follow this model:\n\n1. The user authenticates with your app\n 1. No additional scopes are requested. The app provides basic functionality to let the user explore and use features that do not require any additional data or access.\n2. The user selects a feature that requires access to additional data\n 1. Your application makes an authorization request for this specific OAuth scope required for this feature. If this feature requires multiple scopes, follow [the best practices below](#multiple-scopes).\n 2. If the user denies the request, the app disables the feature and gives the user additional context to request access again.\n\nHandle consent for multiple scopes\n\n\nWhen requesting multiple scopes at once, users may not grant all OAuth scopes you have\nrequested. Your app should handle the denial of scopes by disabling relevant functionality.\n\n\nIf your app's basic functionality requires multiple scopes, explain this to the user before\nprompting for consent.\n\n\nYou may only prompt the user again once they have clearly indicated an intent to use the\nspecific feature that requires the scope. Your app should provide the user with relevant context\nand justification before requesting OAuth scopes.\n\n\nYou should minimize the number of scopes your app requests at once. Instead,\n[utilize incremental authorization](#use-incremental-authorization) to request scopes\nin context of features and functionality.\n\nUse secure browsers\n\n\nOn the web, OAuth 2.0 authorization requests must only be made from full-featured web browsers.\nOn other platforms, make sure to select the\n[correct OAuth client type](/identity/protocols/oauth2#basicsteps) and integrate\nOAuth as appropriate for your platform. Do not redirect the request through embedded browsing\nenvironments, including webviews on mobile platforms, such as WebView on Android or WKWebView on\niOS. Instead, utilize [native OAuth libraries](/identity/protocols/oauth2/native-app)\nor [Google Sign-in](/identity/authorization) for your platform.\n\nManual creation and configuration of OAuth clients\n\n\nIn order to prevent abuse, OAuth clients cannot be created or modified programmatically. You\nmust use the Google Developers console to explicitly acknowledge the terms of service, configure\nyour OAuth client and prepare for OAuth verification.\n\n\nFor automated workflows, consider using\n[service accounts](/identity/protocols/oauth2/service-account) instead.\n\nRemove unused OAuth clients\n\n\nRegularly audit your OAuth 2.0 clients and proactively delete any that are no longer required by\nyour application or have become obsolete. Leaving unused clients configured represents a\npotential security risk as the client can be misused if your client credentials are ever\ncompromised.\n\n\nTo further mitigate risks from unused clients, OAuth 2.0 clients that have been inactive for six\nmonths are [automatically deleted](https://support.google.com/cloud/answer/15549257#unused-client-deletion).\n\n\nThe recommended best practice is to not wait for automatic deletion but rather proactively\nremove unused clients. This practice minimizes your application's attack surface and ensures\ngood security hygiene."]]
