Triển khai máy chủ OAuth 2.0

Mọi hoạt động tích hợp Cloud-to-cloud đều phải có một cơ chế xác thực người dùng.

Xác thực cho phép bạn liên kết Tài khoản Google của người dùng với tài khoản người dùng trong hệ thống xác thực của bạn. Điều này cho phép bạn xác định người dùng khi yêu cầu thực hiện nhận được một ý định nhà thông minh. Nhà thông minh của Google chỉ hỗ trợ OAuth bằng quy trình mã uỷ quyền.

Trang này mô tả cách thiết lập máy chủ OAuth 2.0 để máy chủ này hoạt động với chế độ tích hợp Cloud-to-cloud.

Liên kết Tài khoản Google bằng OAuth

Trong quy trình mã uỷ quyền, bạn cần có 2 điểm cuối:

• Điểm cuối uỷ quyền, trình bày giao diện người dùng đăng nhập cho những người dùng chưa đăng nhập. Điểm cuối uỷ quyền cũng tạo mã uỷ quyền có thời hạn ngắn để ghi lại sự đồng ý của người dùng đối với quyền truy cập được yêu cầu.

• Điểm cuối trao đổi mã thông báo, chịu trách nhiệm cho 2 loại trao đổi:

  1. Trao đổi mã uỷ quyền để lấy mã làm mới dài hạn và mã truy cập ngắn hạn. Quá trình trao đổi này diễn ra khi người dùng thực hiện quy trình liên kết tài khoản.
  2. Đổi mã làm mới dài hạn thành mã truy cập ngắn hạn. Quá trình trao đổi này diễn ra khi Google cần mã thông báo truy cập mới vì mã thông báo hiện tại đã hết hạn.

Hướng dẫn thiết kế

Phần này mô tả các yêu cầu và đề xuất về thiết kế cho màn hình người dùng mà bạn lưu trữ cho quy trình liên kết OAuth. Sau khi được ứng dụng của Google gọi, nền tảng của bạn sẽ hiển thị cho người dùng trang đăng nhập vào Google và màn hình đồng ý liên kết tài khoản. Người dùng sẽ được chuyển hướng trở lại ứng dụng của Google sau khi đồng ý liên kết tài khoản.

Yêu cầu

1. Bạn phải thông báo rằng tài khoản của người dùng sẽ được liên kết với Google, chứ không phải một sản phẩm cụ thể của Google như Google Home hoặc Trợ lý Google.
2. Bạn phải có một tuyên bố uỷ quyền của Google, chẳng hạn như "Khi đăng nhập, bạn đang uỷ quyền cho Google kiểm soát các thiết bị của bạn". Hãy xem phần Uỷ quyền kiểm soát thiết bị của Google trong Chính sách dành cho nhà phát triển của Google Home.
3. Bạn phải mở trang liên kết Web OAuth và đảm bảo người dùng có một phương thức rõ ràng để đăng nhập vào Tài khoản Google của họ, chẳng hạn như các trường dành cho tên người dùng và mật khẩu. Đừng sử dụng phương thức Đăng nhập bằng Google (GSI) cho phép người dùng liên kết mà không cần chuyển đến trang Liên kết OAuth trên web. Đây là hành vi vi phạm chính sách của Google.
4. Bạn phải thêm ít nhất một trong các mục sau vào trang liên kết OAuth để cho biết chế độ tích hợp mà người dùng đang liên kết:
   • Biểu trưng công ty
   • Tên công ty
   • Tên liên kết tích hợp
   • Biểu tượng ứng dụng

Đề xuất

Bạn nên thực hiện những điều sau:

1. Hiển thị Chính sách quyền riêng tư của Google. Thêm đường liên kết đến Chính sách quyền riêng tư của Google trên màn hình xin phép.

2. Dữ liệu sẽ được chia sẻ. Dùng ngôn ngữ rõ ràng và súc tích để cho người dùng biết Google yêu cầu dữ liệu nào của họ và lý do.

3. Lời kêu gọi hành động rõ ràng. Nêu rõ lời kêu gọi hành động trên màn hình đồng ý, chẳng hạn như "Đồng ý và liên kết". Điều này là do người dùng cần hiểu rõ những dữ liệu mà họ bắt buộc phải chia sẻ với Google để liên kết tài khoản.

4. Có thể huỷ. Cung cấp cho người dùng một cách để quay lại hoặc huỷ nếu họ chọn không liên kết.

5. Quy trình đăng nhập rõ ràng. Đảm bảo rằng người dùng có một phương thức rõ ràng để đăng nhập vào Tài khoản Google của họ, chẳng hạn như các trường dành cho tên người dùng và mật khẩu hoặc tính năng Đăng nhập bằng Google.

6. Có thể huỷ liên kết. Cung cấp một cơ chế để người dùng huỷ liên kết, chẳng hạn như một URL đến phần cài đặt tài khoản của họ trên nền tảng của bạn. Ngoài ra, bạn có thể thêm một đường liên kết đến Tài khoản Google để người dùng có thể quản lý tài khoản được liên kết của họ.

7. Có thể thay đổi tài khoản người dùng. Đề xuất một phương thức để người dùng chuyển đổi(các) tài khoản của họ. Điều này đặc biệt có lợi nếu người dùng có xu hướng có nhiều tài khoản.

   • Nếu người dùng phải đóng màn hình đồng ý để chuyển đổi tài khoản, hãy gửi một lỗi có thể khôi phục đến Google để người dùng có thể đăng nhập vào tài khoản mong muốn bằng tính năng liên kết OAuth.

8. Thêm biểu trưng của bạn. Hiển thị biểu trưng công ty của bạn trên màn hình đồng ý. Sử dụng nguyên tắc về phong cách để đặt biểu trưng. Nếu bạn cũng muốn hiển thị biểu trưng của Google, hãy xem phần Biểu trưng và nhãn hiệu.

Quy trình sử dụng mã uỷ quyền

Việc triển khai máy chủ OAuth 2.0 của quy trình mã uỷ quyền bao gồm 2 điểm cuối mà dịch vụ của bạn cung cấp bằng 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 để truy cập vào dữ liệu. Điểm cuối uỷ quyền trình bày một 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. Điểm cuối này được dùng để lấy các chuỗi được mã hoá (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 một ứng dụng 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 để nhận được sự cho phép của người dùng để thay mặt họ gọi các API này.

Một phiên quy trình mã uỷ quyền OAuth 2.0 do Google khởi tạo có quy trình 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 quy trình bắt đầu trên một thiết bị chỉ có giọng nói cho một Thao tác, thì Google sẽ chuyển việc thực thi sang điện thoại.
2. Người dùng đă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 tạo một mã uỷ quyền và trả mã đó về cho Google. Để làm như vậy, hãy chuyển hướng trình duyệt của người dùng trở lại Google với mã uỷ quyền được đính kèm vào yêu cầu.
4. Google 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ột mã truy cập và một 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 vào các API. Mã làm mới là một mã thông báo có thời hạn sử dụng dài mà Google có thể lưu trữ và sử dụng để lấy mã truy cập mới khi mã truy cập 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 tiếp theo được gửi từ Google đều chứa mã truy cập.

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

Khi bạn cần thực hiện quy trình liên kết tài khoản bằng quy trình mã uỷ quyền OAuth 2.0, Google sẽ gửi người dùng đến điểm cuối uỷ quyền của bạn bằng một yêu cầu bao gồm các tham 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, thì yêu cầu có thể trô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

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

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. Các bước kiểm tra này rất quan trọng để ngăn việc cấp quyền truy cập cho các ứng dụng khách không mong muốn hoặc được định cấu hình sai. Nếu bạn hỗ trợ nhiều luồng OAuth 2.0, hãy xác nhận rằng response_type cũng là code.
2. Kiểm tra xem người dùng đã đăng nhập vào dịch vụ của bạn hay chưa. Nếu người dùng chưa đăng nhập, hãy hoàn tất quy trình đăng nhập hoặc đăng ký của dịch vụ.
3. Tạo mã uỷ quyền để Google sử dụng nhằm 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 đại diện duy nhất cho người dùng, ứng dụng mà mã thông báo dành cho và thời gian hết hạn của mã, đồng thời không được phép đoán được. Bạn thường cấp mã uỷ quyền 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ó dạng như 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 đến URL do tham số redirect_uri chỉ định. Thêm mã uỷ quyền mà bạn vừa tạo và giá trị trạng thái ban đầu, chưa được sửa đổi khi bạn chuyển hướng bằng cách nối các tham số code và state. Sau đây là ví dụ về URL kết quả:

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

Xử lý 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ụ chịu trách nhiệm về hai loại trao đổi mã thông báo:

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

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

Định cấu hình cách Google gửi thông tin xác thực đến máy chủ của bạn

Tuỳ thuộc vào cách triển khai, máy chủ uỷ quyền của bạn dự kiến sẽ nhận được thông tin đăng nhập của ứng dụng trong nội dung yêu cầu hoặc trong tiêu đề yêu cầu.

Theo mặc định, Google sẽ gửi thông tin đăng nhập trong phần nội dung yêu cầu. Nếu máy chủ uỷ quyền của bạn yêu cầu thông tin đăng nhập của ứng dụng nằm trong tiêu đề yêu cầu, thì bạn phải định cấu hình chế độ tích hợp Cloud-to-cloud cho phù hợp:

Chuyển đến Developer Console

1. Trong danh sách dự án, hãy nhấp vào Mở bên cạnh dự án mà bạn muốn làm việc.

2. Trong mục Cloud-to-Cloud, hãy chọn Develop (Phát triển).

3. Nhấp vào Mở bên cạnh công cụ tích hợp của bạn.

4. Di chuyển xuống phần Quyền (không bắt buộc) rồi chọn hộp đánh dấu Cho phép Google truyền Mã ứng dụng khách và khoá bí mật thông qua tiêu đề xác thực cơ bản HTTP.

5. Nhấp vào Lưu để lưu các thay đổi.

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 mã uỷ quyền ngắn hạn cho Google, Google sẽ gửi một yêu cầu đến điểm cuối trao đổi mã thông báo của bạn để trao đổi mã uỷ quyền lấy mã truy cập và mã làm mới.

Đối với những yêu cầu này, giá trị của grant_type là authorization_code và giá trị của code là giá trị của mã uỷ quyền mà bạn đã cấp cho Google trước đó. Sau đây là ví dụ về yêu cầu trao đổi mã uỷ quyền để lấy 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

Để trao đổ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 của bạn sẽ phản hồi các yêu cầu POST bằng cách thực hiện 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à một nguồn gốc được uỷ quyền và client_secret khớp với giá trị dự kiến.
2. Xác minh để đảm bảo mã uỷ quyền hợp lệ và chưa hết hạn, đồng thời mã ứng dụng được chỉ định trong yêu cầu khớp với mã ứng dụng được liên kết với mã uỷ quyền.
3. Xác nhận rằng URL do tham số redirect_uri chỉ định giống hệt với giá trị được 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í nêu trên, hãy trả về lỗi HTTP 400 Bad Request với {"error": "invalid_grant"} làm nội dung.
5. Nếu không, hãy sử dụng mã nhận dạng người dùng từ mã uỷ quyền để tạo mã làm mới và mã truy cập. 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 đại diện riêng biệt cho người dùng và ứng dụng mà mã thông báo dành cho, đồng thời không được đ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ời gian này thường là một giờ sau khi bạn phát hành 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 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, đồng thời ghi lại thời gian hết hạn của mã truy cập. Khi mã truy cập hết hạn, Google sẽ sử dụng mã làm mới để lấy mã truy cập mới từ điểm cuối trao đổi mã thông báo của bạn.

Đổi mã làm mới thành mã truy cập

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

Đối với những yêu cầu này, giá trị của grant_type là refresh_token và giá trị của refresh_token là giá trị của mã làm mới mà bạn đã cấp cho Google trước đó. Sau đây là ví dụ về yêu cầu trao đổi mã làm mới để lấy 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

Để trao đổ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 sẽ phản hồi các yêu cầu POST bằng cách thực hiện 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 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 được 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í nêu trên, hãy trả về lỗi HTTP 400 Bad Request với {"error": "invalid_grant"} làm nội dung.
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 mã truy cập. 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 đại diện riêng biệt cho người dùng và ứng dụng mà mã thông báo dành cho, đồng thời không được đ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 đây trong nội dung phản hồi HTTPS:

   {
   "token_type": "Bearer",
   "access_token": "ACCESS_TOKEN",
   "expires_in": 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.