Liên kết Tài khoản Google với OAuth

Các tài khoản được liên kết bằng các quy trình ngầm ẩn và mã uỷ quyền OAuth 2.0 theo tiêu chuẩn ngành. Dịch vụ của bạn phải hỗ trợ các điểm cuối uỷ quyền và trao đổi mã thông báo tuân thủ OAuth 2.0.

In the implicit flow, Google opens your authorization endpoint in the user's browser. After successful sign in, you return a long-lived access token to Google. This access token is now included in every request sent from Google.

In the authorization code flow, you need two endpoints:

• The authorization endpoint, which presents the sign-in UI to your users that aren't already signed in. The authorization endpoint also creates a short-lived authorization code to record users' consent to the requested access.

• The token exchange endpoint, which is responsible for two types of exchanges:

  1. Exchanges an authorization code for a long-lived refresh token and a short-lived access token. This exchange happens when the user goes through the account linking flow.
  2. Exchanges a long-lived refresh token for a short-lived access token. This exchange happens when Google needs a new access token because the one it had expired.

Choose an OAuth 2.0 flow

Although the implicit flow is simpler to implement, Google recommends that access tokens issued by the implicit flow never expire. This is because the user is forced to link their account again after a token expires with the implicit flow. If you need token expiration for security reasons, we strongly recommend that you use the authorization code flow instead.

Design guidelines

This section describes the design requirements and recommendations for the user screen that you host for OAuth linking flows. After it's called by Google's app, your platform displays a sign in to Google page and account linking consent screen to the user. The user is directed back to Google's app after giving their consent to link accounts.

Requirements

1. You must communicate that the user’s account will be linked to Google, not a specific Google product like Google Home or Google Assistant.

Recommendations

We recommend that you do the following:

1. Display Google's Privacy Policy. Include a link to Google’s Privacy Policy on the consent screen.

2. Data to be shared. Use clear and concise language to tell the user what data of theirs Google requires and why.

3. Clear call-to-action. State a clear call-to-action on your consent screen, such as “Agree and link.” This is because users need to understand what data they're required to share with Google to link their accounts.

4. Ability to cancel. Provide a way for users to go back or cancel, if they choose not to link.

5. Clear sign-in process. Ensure that users have clear method for signing in to their Google account, such as fields for their username and password or Sign in with Google.

6. Ability to unlink. Offer a mechanism for users to unlink, such as a URL to their account settings on your platform. Alternatively, you can include a link to Google Account where users can manage their linked account.

7. Ability to change user account. Suggest a method for users to switch their account(s). This is especially beneficial if users tend to have multiple accounts.

   • If a user must close the consent screen to switch accounts, send a recoverable error to Google so the user can sign in to the desired account with OAuth linking and the implicit flow.

8. Include your logo. Display your company logo on the consent screen. Use your style guidelines to place your logo. If you wish to also display Google's logo, see Logos and trademarks.

Create the project

To create your project to use account linking:

1. Go to the Google API Console.
2. Nhấp vào Tạo dự án .
3. Nhập tên hoặc chấp nhận đề xuất được tạo.
4. Xác nhận hoặc chỉnh sửa bất kỳ trường nào còn lại.
5. Nhấp vào Tạo .

To view your project ID:

1. Go to the Google API Console.
2. Find your project in the table on the landing page. The project ID appears in the ID column.

Configure your OAuth Consent Screen

The Google Account Linking process includes a consent screen which tells users the application requesting access to their data, what kind of data they are asking for and the terms that apply. You will need to configure your OAuth consent screen before generating a Google API client ID.

1. Open the OAuth consent screen page of the Google APIs console.
2. If prompted, select the project you just created.

3. On the "OAuth consent screen" page, fill out the form and click the “Save” button.

   Application name: The name of the application asking for consent. The name should accurately reflect your application and be consistent with the application name users see elsewhere. The application name will be shown on the Account Linking consent screen.

   Application logo: An image on the consent screen that will help users recognize your app. The logo is shown on Account linking consent screen and on account settings

   Support email: For users to contact you with questions about their consent.

   Scopes for Google APIs: Scopes allow your application to access your user's private Google data. For the Google Account Linking use case, default scope (email, profile, openid) is sufficient, you don’t need to add any sensitive scopes. It is generally a best practice to request scopes incrementally, at the time access is required, rather than up front. Learn more.

   Authorized domains: To protect you and your users, Google only allows applications that authenticate using OAuth to use Authorized Domains. Your applications' links must be hosted on Authorized Domains. Learn more.

   Application Homepage link: Home page for your application. Must be hosted on an Authorized Domain.

   Application Privacy Policy link: Shown on Google Account Linking consent screen. Must be hosted on an Authorized Domain.

   Application Terms of Service link (Optional): Must be hosted on an Authorized Domain.

   

   Figure 1. Google Account Linking Consent Screen for a fictitious Application, Tunery

4. Check "Verification Status", if your application needs verification then click the "Submit For Verification" button to submit your application for verification. Refer to OAuth verification requirements for details.

Triển khai máy chủ OAuth

Quá trình triển khai máy chủ OAuth 2.0 của quy trình mã uỷ quyền bao gồm hai điểm cuối mà dịch vụ của bạn cung cấp qua HTTPS. Điểm cuối đầu tiên là điểm cuối uỷ quyền, chịu trách nhiệm tìm hoặc lấy sự đồng ý của người dùng về quyền truy cập dữ liệu. Điểm cuối uỷ quyền đưa ra giao diện người dùng đăng nhập cho những người dùng chưa đăng nhập và ghi lại sự đồng ý đối với quyền truy cập được yêu cầu. Điểm cuối thứ hai là điểm cuối trao đổi mã thông báo, được dùng để lấy các chuỗi đã mã hoá (được gọi là mã thông báo) cho phép người dùng truy cập vào dịch vụ của bạn.

Khi ứng dụng của Google cần gọi một trong các API của dịch vụ, Google sẽ sử dụng các điểm cuối này cùng nhau để yêu cầu người dùng cho phép gọi các API này thay mặt cho công ty.

Phiên quy trình mã uỷ quyền OAuth 2.0 do Google khởi tạo có quy trình sau:

1. Google sẽ mở điểm cuối uỷ quyền của bạn trong trình duyệt của người dùng. Nếu luồng bắt đầu trên một thiết bị chỉ dùng giọng nói cho một Hành động, thì Google sẽ chuyển thực thi trên điện thoại.
2. Người dùng này đăng nhập (nếu chưa đăng nhập) và cấp cho Google quyền truy cập vào dữ liệu của họ bằng API của bạn nếu họ chưa cấp quyền.
3. Dịch vụ của bạn sẽ tạo một mã uỷ quyền rồi trả lại mã này cho Google. Việc cần làm do đó, hãy chuyển hướng trình duyệt của người dùng trở lại Google bằng mã uỷ quyền được đính kèm vào yêu cầu.
4. Google sẽ gửi mã uỷ quyền đến điểm cuối trao đổi mã thông báo của bạn. Điểm cuối này xác minh tính xác thực của mã và trả về mã truy cập cũng như mã làm mới. Mã truy cập là một mã ngắn hạn mà dịch vụ của bạn chấp nhận làm thông tin đăng nhập để truy cập các API. Mã làm mới là mã tồn tại trong một thời gian dài mã thông báo mà Google có thể lưu trữ và sử dụng để thu nạp mã truy cập mới khi hết hạn.
5. Sau khi người dùng hoàn tất quy trình liên kết tài khoản, mỗi yêu cầu do Google gửi có chứa mã truy cập.

Xử lý yêu cầu uỷ quyền

Khi bạn cần liên kết tài khoản bằng mã uỷ quyền OAuth 2.0 quy trình này, Google sẽ chuyển người dùng đến điểm cuối uỷ quyền của bạn kèm theo yêu cầu bao gồm các thông số sau:

Ví dụ: nếu điểm cuối uỷ quyền của bạn có tại https://myservice.example.com/auth, một yêu cầu có thể có dạng như sau:

GET https://myservice.example.com/auth?client_id=GOOGLE_CLIENT_ID&redirect_uri=REDIRECT_URI&state=STATE_STRING&scope=REQUESTED_SCOPES&response_type=code&user_locale=LOCALE

Để điểm cuối uỷ quyền của bạn có thể xử lý các yêu cầu đăng nhập, hãy làm như sau các bước:

1. Xác minh rằng client_id khớp với Mã ứng dụng khách mà bạn đã chỉ định cho Google, và redirect_uri khớp với URL chuyển hướng do Google cung cấp cho dịch vụ của bạn. Đây là những bước kiểm tra quan trọng để ngăn chặn việc cấp truy cập vào các ứng dụng khách ngoài ý muốn hoặc bị định cấu hình sai. Nếu bạn hỗ trợ nhiều Luồng OAuth 2.0, cũng xác nhận rằng response_type là code.
2. Kiểm tra xem người dùng đã đăng nhập vào dịch vụ của bạn chưa. Nếu người dùng chưa đăng nhập, hoàn tất quy trình đăng nhập hoặc đăng ký dịch vụ của bạn.
3. Tạo mã uỷ quyền cho Google dùng để truy cập vào API của bạn. Mã uỷ quyền có thể là bất kỳ giá trị chuỗi nào, nhưng phải là duy nhất đại diện cho người dùng, máy khách và thời gian hết hạn của mã và thông tin đó không phải ai cũng đoán được. Bạn thường cấp phép các mã sẽ hết hạn sau khoảng 10 phút.
4. Xác nhận rằng URL do tham số redirect_uri chỉ định có biểu mẫu sau:

     https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID
     https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
     

5. Chuyển hướng trình duyệt của người dùng tới URL được chỉ định Tham số redirect_uri. Bao gồm mã uỷ quyền mà bạn vừa được tạo và giá trị trạng thái ban đầu, chưa sửa đổi khi bạn chuyển hướng bằng cách thêm các tham số code và state. Sau đây là một ví dụ về URL kết quả:

   https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID?code=AUTHORIZATION_CODE&state=STATE_STRING

Xử lý các yêu cầu trao đổi mã thông báo

Điểm cuối trao đổi mã thông báo của dịch vụ của bạn chịu trách nhiệm về 2 loại mã thông báo sàn giao dịch:

• Trao đổi mã uỷ quyền để lấy mã truy cập và mã làm mới
• Mã làm mới trao đổi cho mã truy cập

Yêu cầu trao đổi mã thông báo bao gồm các tham số sau:

Trao đổi mã uỷ quyền để lấy mã truy cập và mã làm mới

Sau khi người dùng đăng nhập và điểm cuối uỷ quyền của bạn trả về một thông báo ngắn hạn mã uỷ quyền cho Google, Google sẽ gửi yêu cầu đến sàn giao dịch mã thông báo của bạn điểm cuối để trao đổi mã uỷ quyền lấy mã truy cập và làm mới mã thông báo.

Đối với các yêu cầu này, giá trị của grant_type là authorization_code và giá trị code là giá trị của mã uỷ quyền mà bạn đã cấp trước đó cho Google. Sau đây là ví dụ về yêu cầu trao đổi mã uỷ quyền cho mã truy cập và mã làm mới:

POST /token HTTP/1.1
Host: oauth2.example.com
Content-Type: application/x-www-form-urlencoded

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=REDIRECT_URI

Để đổi mã uỷ quyền lấy mã truy cập và mã làm mới, điểm cuối trao đổi mã thông báo phản hồi các yêu cầu POST bằng cách thực thi lệnh sau các bước:

1. Xác minh rằng client_id xác định nguồn gốc của yêu cầu là nguồn đã được uỷ quyền điểm gốc và client_secret khớp với giá trị dự kiến.
2. Xác minh rằng mã uỷ quyền là hợp lệ và chưa hết hạn, đồng thời client ID được chỉ định trong yêu cầu khớp với ID ứng dụng khách được liên kết với mã uỷ quyền.
3. Xác nhận rằng URL mà tham số redirect_uri chỉ định là giống hệt nhau thành giá trị được sử dụng trong yêu cầu uỷ quyền ban đầu.
4. Nếu bạn không thể xác minh tất cả các tiêu chí trên, hãy trả về một HTTP 400 Lỗi Yêu cầu không hợp lệ, trong đó {"error": "invalid_grant"} là phần nội dung.
5. Nếu không, hãy sử dụng mã nhận dạng người dùng trong mã uỷ quyền để tạo quy trình làm mới và mã truy cập. Các mã thông báo này có thể là giá trị chuỗi bất kỳ, nhưng phải đại diện riêng cho người dùng và khách hàng mà mã thông báo dành cho họ, đồng thời không được dễ đoán. Đối với mã truy cập, hãy ghi lại cả thời gian hết hạn của mã thông báo. Thời gian này thường là một giờ sau khi bạn cấp mã thông báo. Mã làm mới không hết hạn.
6. Trả về đối tượng JSON sau đây trong phần nội dung của phản hồi HTTPS:

   {
   "token_type": "Bearer",
   "access_token": "ACCESS_TOKEN",
   "refresh_token": "REFRESH_TOKEN",
   "expires_in": SECONDS_TO_EXPIRATION
   }

Google lưu trữ mã truy cập và mã làm mới cho người dùng và bản ghi mã truy cập đã hết hạn. Khi mã truy cập hết hạn, Google sẽ sử dụng mã làm mới để nhận mã truy cập mới từ điểm cuối trao đổi mã thông báo.

Mã làm mới trao đổi cho mã truy cập

Khi mã truy cập hết hạn, Google sẽ gửi yêu cầu đến sàn giao dịch mã thông báo của bạn để trao đổi mã làm mới lấy mã truy cập mới.

Đối với các yêu cầu này, giá trị của grant_type là refresh_token và giá trị refresh_token là giá trị của mã làm mới mà bạn đã cấp trước đó Google. Sau đây là ví dụ về yêu cầu trao đổi mã làm mới đối với mã truy cập:

POST /token HTTP/1.1
Host: oauth2.example.com
Content-Type: application/x-www-form-urlencoded

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=refresh_token&refresh_token=REFRESH_TOKEN

Để đổi mã làm mới lấy mã truy cập, điểm cuối trao đổi mã thông báo của bạn phản hồi các yêu cầu POST bằng cách thực thi các bước sau:

1. Xác minh rằng client_id xác định nguồn gốc của yêu cầu là Google, và client_secret khớp với giá trị dự kiến.
2. Xác minh rằng mã làm mới là hợp lệ và mã ứng dụng khách được chỉ định trong yêu cầu khớp với mã ứng dụng khách liên kết với mã làm mới.
3. Nếu bạn không thể xác minh tất cả các tiêu chí trên, hãy trả về HTTP 400 Lỗi Yêu cầu không hợp lệ, trong đó phần nội dung là {"error": "invalid_grant"}.
4. Nếu không, hãy sử dụng mã nhận dạng người dùng từ mã làm mới để tạo quyền truy cập mã thông báo. Các mã thông báo này có thể là bất kỳ giá trị chuỗi nào, nhưng phải là duy nhất đại diện cho người dùng và khách hàng mà mã thông báo dành cho họ, đồng thời không được có thể đoán được. Đối với mã truy cập, hãy ghi lại thời gian hết hạn của mã thông báo, thường là một giờ sau khi bạn phát hành mã thông báo.
5. Trả về đối tượng JSON sau trong phần nội dung của HTTPS trả lời:

   {
   "token_type": "Người mang",
   "access_token": "ACCESS_TOKEN",
   "expiry_in" (hết hạn): SECONDS_TO_EXPIRATION
   }

Handle userinfo requests

The userinfo endpoint is an OAuth 2.0 protected resource that return claims about the linked user. Implementing and hosting the userinfo endpoint is optional, except for the following use cases:

• Linked Account Sign-In with Google One Tap.
• Frictionless subscription on AndroidTV.

After the access token has been successfully retrieved from your token endpoint, Google sends a request to your userinfo endpoint to retrieve basic profile information about the linked user.

For example, if your userinfo endpoint is available at https://myservice.example.com/userinfo, a request might look like the following:

GET /userinfo HTTP/1.1
Host: myservice.example.com
Authorization: Bearer ACCESS_TOKEN

For your userinfo endpoint to handle requests, do the following steps:

1. Extract access token from the Authorization header and return information for the user associated with the access token.
2. If the access token is invalid, return an HTTP 401 Unauthorized error with using the WWW-Authenticate Response Header. Below is an example of a userinfo error response:

   HTTP/1.1 401 Unauthorized
   WWW-Authenticate: error="invalid_token",
   error_description="The Access Token expired"
   

   If a 401 Unauthorized, or any other unsuccessful error response is returned during the linking process, the error will be non-recoverable, the retrieved token will be discarded and the user will have to initiate the linking process again.

3. If the access token is valid, return and HTTP 200 response with the following JSON object in the body of the HTTPS response:

   {
   "sub": "USER_UUID",
   "email": "EMAIL_ADDRESS",
   "given_name": "FIRST_NAME",
   "family_name": "LAST_NAME",
   "name": "FULL_NAME",
   "picture": "PROFILE_PICTURE",
   }

   If your userinfo endpoint returns an HTTP 200 success response, the retrieved token and claims are registered against the user's Google account.

   userinfo endpoint response
   sub	A unique ID that identifies the user in your system.
   email	Email address of the user.
   given_name	Optional: First name of the user.
   family_name	Optional: Last name of the user.
   name	Optional: Full name of the user.
   picture	Optional: Profile picture of the user.

Xác thực quá trình triển khai

Bạn có thể xác thực phương thức triển khai bằng cách sử dụng công cụ OAuth 2.0 Playground.

Trong công cụ này, hãy làm theo các bước sau:

1. Nhấp vào biểu tượng Configuration (Cấu hình) settings để mở cửa sổ OAuth 2.0 Configuration (Cấu hình OAuth 2.0).
2. Trong trường Quy trình OAuth, hãy chọn Phía máy khách.
3. Trong trường OAuth Endpoints (Điểm cuối OAuth), hãy chọn Custom (Tuỳ chỉnh).
4. Chỉ định điểm cuối OAuth 2.0 và mã ứng dụng khách mà bạn đã chỉ định cho Google trong các trường tương ứng.
5. Trong phần Bước 1, đừng chọn bất kỳ phạm vi nào của Google. Thay vào đó, hãy để trống trường này hoặc nhập một phạm vi hợp lệ cho máy chủ của bạn (hoặc một chuỗi tuỳ ý nếu bạn không sử dụng phạm vi OAuth). Khi bạn hoàn tất, hãy nhấp vào Uỷ quyền cho API.
6. Trong các mục Bước 2 và Bước 3, hãy thực hiện quy trình OAuth 2.0 và xác minh rằng mỗi bước hoạt động như dự kiến.

Bạn có thể xác thực việc triển khai của mình bằng cách sử dụng công cụ Bản minh hoạ về cách liên kết Tài khoản Google.

Trong công cụ này, hãy làm theo các bước sau:

1. Nhấp vào nút Đăng nhập bằng Google.
2. Chọn tài khoản mà bạn muốn liên kết.
3. Nhập mã dịch vụ.
4. Bạn có thể nhập một hoặc nhiều phạm vi mà bạn sẽ yêu cầu quyền truy cập.
5. Nhấp vào Bắt đầu bản minh hoạ.
6. Khi được nhắc, hãy xác nhận rằng bạn có thể đồng ý và từ chối yêu cầu liên kết.
7. Xác nhận rằng bạn được chuyển hướng đến nền tảng của mình.