Nếu không, trước khi thêm uỷ quyền OAuth 2.0 vào dịch vụ của mình, hãy chuẩn bị thông tin sau và liên hệ với người đại diện về quan hệ nhà phát triển hoặc phát triển kinh doanh:
URL điểm cuối uỷ quyền.
Đây là URL cho điểm cuối uỷ quyền mà bạn lưu trữ và Google sẽ gọi đến. Chỉ chấp nhận lưu lượng truy cập qua HTTPS. Ví dụ: https://myservice.example.com/auth.
Thông thường, bạn có thể điều chỉnh một trang đăng nhập hiện có để đóng vai trò là điểm cuối uỷ quyền.
redirect_uri được gửi dưới dạng một tham số đến điểm cuối uỷ quyền của bạn sẽ có dạng như sau:
redirect_uri phải có tên trong danh sách cho phép đối với client_id mà bạn chỉ định cho Google.
URL điểm cuối của mã thông báo.
Đây là URL cho điểm cuối mã thông báo mà bạn lưu trữ và Google gọi đến. Lưu lượng truy cập phải được chấp nhận qua HTTPS và chỉ từ các dịch vụ đã biết khác (chẳng hạn như của Google).
Ví dụ: https://oauth2.example.com/token.
Các điểm cuối uỷ quyền và mã thông báo có thể được lưu trữ trên các miền khác nhau.
URL điểm cuối thu hồi mã thông báo không bắt buộc.
Đây là URL cho điểm cuối thu hồi mà bạn lưu trữ và Google gọi đến. Lưu lượng truy cập phải được chấp nhận qua HTTPS và chỉ từ các dịch vụ đã biết khác (chẳng hạn như của Google).
Ví dụ: https://oauth2.example.com/revoke.
Các điểm cuối uỷ quyền, mã thông báo và thu hồi của bạn có thể được lưu trữ trên các miền khác nhau.
URL bảo vệ trên nhiều tài khoản (RISC) (không bắt buộc).
Đây là một URL mà bạn lưu trữ và Google thực hiện các lệnh gọi đến URL đó. Bạn có thể chọn giá trị.
Mã ứng dụng khách và khoá bí mật của ứng dụng khách cho Google.
Bạn phải chỉ định cho Google một mã ứng dụng khách (được dùng trong các yêu cầu OAuth 2.0 để xác định nguồn gốc của yêu cầu) và một khoá bí mật của ứng dụng (được dùng để ngăn chặn hành vi giả mạo yêu cầu). Mã ứng dụng khách và khoá bí mật của ứng dụng khách Google có thể là bất kỳ giá trị chuỗi nào an toàn với URL mà bạn chọn. Bạn phải đảm bảo rằng chỉ Google và dịch vụ của bạn mới nhìn thấy mật khẩu ứng dụng khách.
Chuỗi phạm vi không bắt buộc.
Tuỳ thuộc vào lượng và loại dữ liệu người dùng mà API của bạn cung cấp, bạn có thể muốn xác định các phạm vi đại diện cho nhiều danh mục dữ liệu người dùng. Bằng cách này, các bên có thể yêu cầu người dùng cấp quyền truy cập vào một số loại dữ liệu nhất định và hạn chế dữ liệu mà khách hàng có thể truy cập chỉ trong các phạm vi được uỷ quyền. Cụ thể, nếu dịch vụ của bạn cung cấp nhiều dữ liệu hơn mức cần thiết để tích hợp với Google, thì bạn có thể sử dụng các phạm vi để chỉ cấp quyền truy cập vào một số dữ liệu.
Mã dự án API của Google
Cách xem mã dự án:
Tìm dự án của bạn trong bảng trên trang đích. Mã dự án xuất hiện trong cột Mã.
[null,null,["Cập nhật lần gần đây nhất: 2025-07-29 UTC."],[[["\u003cp\u003eBefore integrating with Google services (excluding Google Assistant), gather necessary information like authorization and token endpoint URLs and contact your developer relations representative.\u003c/p\u003e\n"],["\u003cp\u003eYou need to provide Google with a client ID and secret, which can be any URL-safe string, and ensure the client secret remains confidential.\u003c/p\u003e\n"],["\u003cp\u003eWhen setting up your authorization endpoint, allowlist the provided \u003ccode\u003eredirect_uri\u003c/code\u003e for Google's client ID.\u003c/p\u003e\n"],["\u003cp\u003eOptionally, you can enhance security by implementing a token revocation endpoint, Cross-Account Protection, and defining scopes to limit data access for Google.\u003c/p\u003e\n"],["\u003cp\u003eTo initiate the process, locate your Google API Project ID within the Google API Console.\u003c/p\u003e\n"]]],[],null,["If you plan to integrate with the Google Assistant, see\n[Actions on Google Console](https://console.actions.google.com/).\n\nOtherwise, before you add OAuth 2.0 authorization to your service, prepare the\nfollowing information and contact your developer relations or business\ndevelopment representative:\n\n- **Authorization endpoint URL** .\n This is the URL for the\n [authorization endpoint](https://tools.ietf.org/html/rfc6749#section-3.1)\n which you host and that Google makes calls to. Traffic should be accepted\n over HTTPS only. For example, `https://myservice.example.com/auth`.\n Oftentimes an existing sign-in page can be adapted to serve as the\n authorization endpoint.\n\n The `redirect_uri` sent as a parameter to your authorization endpoint will have the following form: \n\n ```\n https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID\n https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID\n ```\n\n \u003cbr /\u003e\n\n The`redirect_uri` should be allowlisted for the `client_id` you assign to Google.\n- **Token endpoint URL** .\n This is the URL for the\n [token endpoint](https://tools.ietf.org/html/rfc6749#section-3.2)\n which you host and Google makes calls to. Traffic should be accepted over\n HTTPS and only from other known services (such as Google's).\n For example, `https://oauth2.example.com/token`.\n The authorization and token endpoints may be hosted on different domains.\n\n- **Optional token revocation endpoint URL** .\n This is the URL for the\n [revocation endpoint](https://tools.ietf.org/html/rfc7009)\n which you host and Google makes calls to. Traffic should be accepted over\n HTTPS and only from other known services (such as Google's).\n For example, `https://oauth2.example.com/revoke`.\n Your authorization, token and revocation endpoints may be hosted on different\n domains.\n\n- **Optional Cross-Account Protection (RISC) URL**.\n This is a URL you host and Google makes calls to. You may chose the value.\n\n- **Client ID and client secret for Google**.\n You must assign Google a client ID, which is used in OAuth 2.0 requests to\n identify the request's origin, and a client secret, which is used to prevent\n request forgery. The Google client ID and client secret can be any URL-safe\n string values of your choice. You must ensure that the client secret is\n visible to only Google and your service.\n\n- **Optional scope strings**.\n Depending on how much and what kind of user data your API makes available,\n you might want to define scopes that represent different categories of user\n data. By doing so, parties can ask permission from your users to access only\n certain kinds of data, and restrict the data available to clients to only the\n authorized scopes. In particular, if your service makes more data available\n than necessary for integration with Google, you might use scopes to grant\n access to only some of the data.\n\n\u003c!-- --\u003e\n\n- **Your Google API Project ID**\n\n To view your project ID:\n 1. Go to the [Google API Console](https://console.developers.google.com/project).\n 2. Find your project in the table on the landing page. The project ID appears in the **ID** column.\n\n| **Note:** Requests to your OAuth endpoints can come from any number of Google IP Address. We do not recommend maintaining a list of allowed IPs and Google does not publish such a list. This is because the list is dynamic and subject to change at any time. Such a list will become outdated and lead to outages and a poor experience for users. Instead, a reverse lookup to confirm requests originate from Google can be used. See [Verifying Googlebot](https://developers.google.com/search/docs/advanced/crawling/verifying-googlebot?visit_id=637552176006795991-2252054900&rd=1) for details on how to identify Google requests."]]
