Sử dụng OAuth 2.0 cho ứng dụng từ máy chủ đến máy chủ

Hệ thống OAuth 2.0 của Google hỗ trợ các hoạt động tương tác giữa máy chủ với máy chủ, chẳng hạn như giữa một ứng dụng web và một dịch vụ của Google. Đối với trường hợp này, bạn cần có một tài khoản dịch vụ. Đây là tài khoản thuộc về ứng dụng của bạn thay vì thuộc về một người dùng cuối cá nhân. Ứng dụng của bạn thay mặt tài khoản dịch vụ gọi API của Google, vì vậy, người dùng không trực tiếp tham gia. Tình huống này đôi khi được gọi là "OAuth hai bên" hoặc "2LO". (Thuật ngữ liên quan "OAuth ba bên" đề cập đến các trường hợp ứng dụng của bạn gọi API của Google thay mặt cho người dùng cuối và đôi khi cần có sự đồng ý của người dùng.)

Thông thường, ứng dụng sử dụng tài khoản dịch vụ khi ứng dụng sử dụng API của Google để xử lý dữ liệu của chính ứng dụng thay vì dữ liệu của người dùng. Ví dụ: một ứng dụng sử dụng Google Cloud Datastore để lưu trữ dữ liệu sẽ sử dụng tài khoản dịch vụ để xác thực các lệnh gọi đến API Google Cloud Datastore.

Quản trị viên miền Google Workspace cũng có thể cấp cho tài khoản dịch vụ quyền trên toàn miền để thay mặt người dùng trong miền truy cập vào dữ liệu của người dùng.

Tài liệu này mô tả cách một ứng dụng có thể hoàn tất luồng OAuth 2.0 từ máy chủ đến máy chủ bằng cách sử dụng thư viện ứng dụng API của Google (nên dùng) hoặc HTTP.

Tổng quan

Để hỗ trợ các hoạt động tương tác giữa các máy chủ, trước tiên, hãy tạo một tài khoản dịch vụ cho dự án của bạn trong . Nếu bạn muốn truy cập vào dữ liệu người dùng cho người dùng trong tài khoản Google Workspace, hãy uỷ quyền quyền truy cập trên toàn miền cho tài khoản dịch vụ.

Sau đó, ứng dụng của bạn sẽ chuẩn bị thực hiện các lệnh gọi API được uỷ quyền bằng cách sử dụng thông tin xác thực của tài khoản dịch vụ để yêu cầu mã truy cập từ máy chủ xác thực OAuth 2.0.

Cuối cùng, ứng dụng của bạn có thể sử dụng mã thông báo truy cập để gọi các API của Google.

Tạo một tài khoản dịch vụ

Thông tin xác thực của tài khoản dịch vụ bao gồm một địa chỉ email được tạo duy nhất và ít nhất một cặp khoá công khai/riêng tư. Nếu bạn bật tính năng uỷ quyền trên toàn miền, thì mã ứng dụng cũng là một phần của thông tin xác thực của tài khoản dịch vụ.

Nếu ứng dụng của bạn chạy trên Google App Engine, thì tài khoản dịch vụ sẽ được thiết lập tự động khi bạn tạo dự án.

Nếu ứng dụng của bạn chạy trên Google Compute Engine, thì tài khoản dịch vụ cũng sẽ được thiết lập tự động khi bạn tạo dự án, nhưng bạn phải chỉ định các phạm vi mà ứng dụng của bạn cần quyền truy cập khi tạo một phiên bản Google Compute Engine. Để biết thêm thông tin, hãy xem phần Chuẩn bị thực thể để sử dụng tài khoản dịch vụ.

Nếu ứng dụng của bạn không chạy trên Google App Engine hoặc Google Compute Engine, bạn phải lấy các thông tin xác thực này trong . Để tạo thông tin xác thực tài khoản dịch vụ hoặc để xem thông tin xác thực công khai mà bạn đã tạo, hãy làm như sau:

Bạn có thể quay lại bất cứ lúc nào để xem địa chỉ email, vân tay khoá công khai và thông tin khác hoặc để tạo thêm cặp khoá công khai/riêng tư. Để biết thêm thông tin chi tiết về thông tin xác thực tài khoản dịch vụ trong , hãy xem phần Tài khoản dịch vụ trong tệp trợ giúp .

Ghi lại địa chỉ email của tài khoản dịch vụ và lưu trữ tệp khoá riêng tư của tài khoản dịch vụ ở một vị trí mà ứng dụng của bạn có thể truy cập. Ứng dụng của bạn cần các mã này để thực hiện các lệnh gọi API được uỷ quyền.

Uỷ quyền quyền trên toàn miền cho tài khoản dịch vụ

Khi sử dụng tài khoản Google Workspace, quản trị viên Workspace của tổ chức có thể uỷ quyền cho một ứng dụng thay mặt người dùng trong miền Google Workspace truy cập vào dữ liệu người dùng Workspace. Ví dụ: một ứng dụng sử dụng API Lịch Google để thêm sự kiện vào lịch của tất cả người dùng trong một miền Google Workspace sẽ sử dụng tài khoản dịch vụ để thay mặt người dùng truy cập vào API Lịch Google. Việc uỷ quyền cho tài khoản dịch vụ thay mặt người dùng trong một miền truy cập vào dữ liệu đôi khi được gọi là "uỷ quyền quyền trên toàn miền" cho tài khoản dịch vụ.

Để uỷ quyền trên toàn miền cho một tài khoản dịch vụ, quản trị viên cấp cao của miền Google Workspace phải hoàn tất các bước sau:

1. Trong Bảng điều khiển dành cho quản trị viên của miền Google Workspace, hãy chuyển đến Trình đơn chính menu > Bảo mật > Kiểm soát quyền truy cập và dữ liệu > Chế độ kiểm soát API.
2. Trong ngăn Uỷ quyền trên toàn miền, hãy chọn Quản lý việc uỷ quyền trên toàn miền.
3. Nhấp vào Thêm mới.
4. Trong trường Mã ứng dụng khách, hãy nhập Mã ứng dụng khách của tài khoản dịch vụ. Bạn có thể tìm thấy mã ứng dụng khách của tài khoản dịch vụ trong .
5. Trong trường Phạm vi OAuth (phân tách bằng dấu phẩy), hãy nhập danh sách các phạm vi mà ứng dụng của bạn sẽ được cấp quyền truy cập. Ví dụ: nếu ứng dụng của bạn cần quyền truy cập toàn quyền trên toàn miền vào API Google Drive và API Lịch Google, hãy nhập: https://www.googleapis.com/auth/drive, https://www.googleapis.com/auth/calendar.
6. Nhấp vào Uỷ quyền.

Ứng dụng của bạn hiện có quyền thực hiện lệnh gọi API với tư cách là người dùng trong miền Workspace của bạn (để "mạo danh" người dùng). Khi chuẩn bị thực hiện các lệnh gọi API được uỷ quyền này, bạn sẽ chỉ định rõ người dùng để giả mạo.

Chuẩn bị thực hiện lệnh gọi API được uỷ quyền

Java

Sau khi bạn lấy địa chỉ email và khoá riêng tư của ứng dụng từ , hãy sử dụng Thư viện ứng dụng API của Google dành cho Java để tạo đối tượng GoogleCredential từ thông tin xác thực của tài khoản dịch vụ và các phạm vi mà ứng dụng của bạn cần quyền truy cập. Ví dụ:

import com.google.api.client.googleapis.auth.oauth2.GoogleCredential;
import com.google.api.services.sqladmin.SQLAdminScopes;

// ...

GoogleCredential credential = GoogleCredential.fromStream(new FileInputStream("MyProject-1234.json"))
    .createScoped(Collections.singleton(SQLAdminScopes.SQLSERVICE_ADMIN));

Nếu đang phát triển ứng dụng trên Google Cloud Platform, bạn có thể sử dụng thông tin xác thực mặc định của ứng dụng để đơn giản hoá quy trình.

Uỷ quyền quyền trên toàn miền

Nếu bạn đã uỷ quyền quyền truy cập trên toàn miền cho tài khoản dịch vụ và muốn mạo danh một tài khoản người dùng, hãy chỉ định địa chỉ email của tài khoản người dùng bằng phương thức createDelegated của đối tượng GoogleCredential. Ví dụ:

GoogleCredential credential = GoogleCredential.fromStream(new FileInputStream("MyProject-1234.json"))
    .createScoped(Collections.singleton(SQLAdminScopes.SQLSERVICE_ADMIN))
    .createDelegated("workspace-user@example.com");

Mã ở trên sử dụng đối tượng GoogleCredential để gọi phương thức createDelegated(). Đối số cho phương thức createDelegated() phải là một người dùng thuộc tài khoản Workspace của bạn. Mã tạo yêu cầu của bạn sẽ sử dụng thông tin xác thực này để gọi các API của Google bằng tài khoản dịch vụ của bạn.

Python

Sau khi bạn lấy địa chỉ email và khoá riêng tư của ứng dụng từ , hãy sử dụng Thư viện ứng dụng API của Google cho Python để hoàn tất các bước sau:

1. Tạo đối tượng Credentials từ thông tin xác thực của tài khoản dịch vụ và các phạm vi mà ứng dụng của bạn cần quyền truy cập. Ví dụ:

   from google.oauth2 import service_account
   
   SCOPES = ['https://www.googleapis.com/auth/sqlservice.admin']
   SERVICE_ACCOUNT_FILE = '/path/to/service.json'
   
   credentials = service_account.Credentials.from_service_account_file(
           SERVICE_ACCOUNT_FILE, scopes=SCOPES)

   Nếu đang phát triển ứng dụng trên Google Cloud Platform, bạn có thể sử dụng thông tin xác thực mặc định của ứng dụng để đơn giản hoá quy trình.

2. Uỷ quyền quyền trên toàn miền

   Nếu bạn đã uỷ quyền quyền truy cập trên toàn miền cho tài khoản dịch vụ và muốn giả mạo một tài khoản người dùng, hãy sử dụng phương thức with_subject của đối tượng ServiceAccountCredentials hiện có. Ví dụ:

   delegated_credentials = credentials.with_subject('user@example.org')

Sử dụng đối tượng Thông tin xác thực để gọi các API của Google trong ứng dụng.

HTTP/REST

Sau khi bạn lấy mã ứng dụng và khoá riêng tư từ , ứng dụng của bạn cần hoàn tất các bước sau:

1. Tạo một Mã thông báo web JSON (JWT, phát âm là "jot") bao gồm một tiêu đề, một tập hợp xác nhận quyền sở hữu và một chữ ký.
2. Yêu cầu mã thông báo truy cập từ Máy chủ uỷ quyền OAuth 2.0 của Google.
3. Xử lý phản hồi JSON mà Máy chủ uỷ quyền trả về.

Các phần sau đây mô tả cách hoàn tất các bước này.

Nếu phản hồi bao gồm mã truy cập, bạn có thể sử dụng mã truy cập đó để gọi một API của Google. (Nếu phản hồi không bao gồm mã truy cập, thì JWT và yêu cầu mã thông báo của bạn có thể không được tạo đúng cách hoặc tài khoản dịch vụ có thể không có quyền truy cập vào các phạm vi được yêu cầu.)

Khi mã thông báo truy cập hết hạn, ứng dụng của bạn sẽ tạo một JWT khác, ký mã đó và yêu cầu một mã thông báo truy cập khác.

Phần còn lại của phần này mô tả thông tin cụ thể về cách tạo JWT, ký JWT, tạo yêu cầu mã thông báo truy cập và xử lý phản hồi.

Tạo JWT

JWT bao gồm 3 phần: tiêu đề, tập hợp thông báo xác nhận quyền và chữ ký. Tiêu đề và tập hợp xác nhận quyền sở hữu là các đối tượng JSON. Các đối tượng JSON này được chuyển đổi tuần tự thành các byte UTF-8, sau đó được mã hoá bằng cách sử dụng phương thức mã hoá Base64url. Phương thức mã hoá này giúp tăng khả năng chống chịu đối với các thay đổi về mã hoá do các thao tác mã hoá lặp lại. Tiêu đề, tập hợp thông báo xác nhận quyền sở hữu và chữ ký được nối với nhau bằng ký tự dấu chấm (.).

JWT được tạo như sau:

{Base64url encoded header}.{Base64url encoded claim set}.{Base64url encoded signature}

Chuỗi cơ sở cho chữ ký như sau:

{Base64url encoded header}.{Base64url encoded claim set}

Tạo tiêu đề JWT

Tiêu đề bao gồm 3 trường cho biết thuật toán ký, định dạng của câu nhận định và [mã khoá của khoá tài khoản dịch vụ](https://cloud.google.com/iam/docs/reference/rest/v1/projects.serviceAccounts.keys) được dùng để ký JWT. Bạn bắt buộc phải cung cấp thuật toán và định dạng, đồng thời mỗi trường chỉ có một giá trị. Khi các thuật toán và định dạng bổ sung được giới thiệu, tiêu đề này sẽ thay đổi tương ứng. Mã khoá là không bắt buộc và nếu bạn chỉ định Mã khoá không chính xác, GCP sẽ thử tất cả khoá liên kết với tài khoản dịch vụ để xác minh mã thông báo và từ chối mã thông báo nếu không tìm thấy khoá hợp lệ. Google có quyền từ chối các mã thông báo có mã khoá không chính xác trong tương lai.

Tài khoản dịch vụ dựa vào thuật toán RSA SHA-256 và định dạng mã thông báo JWT. Do đó, nội dung biểu diễn JSON của tiêu đề sẽ như sau:

{"alg":"RS256","typ":"JWT", "kid":"370ab79b4513eb9bad7c9bd16a95cb76b5b2a56a"}

Dưới đây là cách biểu thị Base64url của URL này:

          eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsICJraWQiOiIzNzBhYjc5YjQ1MTNlYjliYWQ3YzliZDE2YTk1Y2I3NmI1YjJhNTZhIn0=

Tạo bộ thông báo xác nhận quyền sở hữu JWT

Tập hợp thông báo xác nhận quyền sở hữu JWT chứa thông tin về JWT, bao gồm cả các quyền đang được yêu cầu (phạm vi), mục tiêu của mã thông báo, bên phát hành, thời gian phát hành mã thông báo và thời gian tồn tại của mã thông báo. Hầu hết các trường đều là bắt buộc. Giống như tiêu đề JWT, tập hợp thông báo xác nhận JWT là một đối tượng JSON và được dùng trong quá trình tính toán chữ ký.

Thông báo xác nhận quyền sở hữu bắt buộc

Dưới đây là các thông tin xác nhận bắt buộc trong tập hợp thông tin xác nhận JWT. Các quyền đó có thể xuất hiện theo thứ tự bất kỳ trong nhóm quyền sở hữu.

Tên	Mô tả
iss	Địa chỉ email của tài khoản dịch vụ.
scope	Danh sách các quyền mà ứng dụng yêu cầu, được phân tách bằng dấu cách.
aud	Phần mô tả mục tiêu dự kiến của câu nhận định. Khi tạo yêu cầu mã thông báo truy cập, giá trị này luôn là https://oauth2.googleapis.com/token.
exp	Thời gian hết hạn của câu nhận định, được chỉ định bằng giây kể từ 00:00:00 giờ UTC, ngày 1 tháng 1 năm 1970. Giá trị này có thời gian tối đa là 1 giờ sau thời gian phát hành.
iat	Thời gian phát hành câu nhận định, được chỉ định bằng giây kể từ 00:00:00 giờ UTC, ngày 1 tháng 1 năm 1970.

Dưới đây là nội dung biểu diễn JSON của các trường bắt buộc trong tập hợp thông báo xác nhận JWT:

{
  "iss": "761326798069-r5mljlln1rd4lrbhg75efgigp36m78j5@developer.gserviceaccount.com",
  "scope": "https://www.googleapis.com/auth/devstorage.read_only",
  "aud": "https://oauth2.googleapis.com/token",
  "exp": 1328554385,
  "iat": 1328550785
}

Thông báo xác nhận quyền sở hữu khác

Trong một số trường hợp doanh nghiệp, ứng dụng có thể sử dụng tính năng uỷ quyền trên toàn miền để thay mặt một người dùng cụ thể trong tổ chức. Bạn phải cấp quyền thực hiện loại hành vi mạo danh này trước khi ứng dụng có thể mạo danh người dùng và quyền này thường do quản trị viên cấp cao xử lý. Để biết thêm thông tin, hãy xem phần Kiểm soát quyền truy cập API bằng tính năng uỷ quyền trên toàn miền.

Để lấy mã truy cập cấp cho ứng dụng quyền truy cập được uỷ quyền vào một tài nguyên, hãy thêm địa chỉ email của người dùng vào thông báo xác nhận JWT được đặt làm giá trị của trường sub.

Tên	Mô tả
sub	Địa chỉ email của người dùng mà ứng dụng đang yêu cầu quyền truy cập được uỷ quyền.

Nếu một ứng dụng không có quyền mạo danh người dùng, thì phản hồi cho yêu cầu mã truy cập có chứa trường sub sẽ là một lỗi.

Dưới đây là ví dụ về một tập hợp thông báo xác nhận JWT có chứa trường sub:

{
  "iss": "761326798069-r5mljlln1rd4lrbhg75efgigp36m78j5@developer.gserviceaccount.com",
  "sub": "some.user@example.com",
  "scope": "https://www.googleapis.com/auth/prediction",
  "aud": "https://oauth2.googleapis.com/token",
  "exp": 1328554385,
  "iat": 1328550785
}

Mã hoá tập hợp thông báo xác nhận quyền sở hữu JWT

Giống như tiêu đề JWT, tập hợp thông báo xác nhận JWT phải được chuyển đổi tuần tự thành UTF-8 và được mã hoá theo cách an toàn cho Base64url. Dưới đây là ví dụ về cách trình bày JSON của một tập hợp JWT Claim:

{
  "iss": "761326798069-r5mljlln1rd4lrbhg75efgigp36m78j5@developer.gserviceaccount.com",
  "scope": "https://www.googleapis.com/auth/prediction",
  "aud": "https://oauth2.googleapis.com/token",
  "exp": 1328554385,
  "iat": 1328550785
}

Tính toán chữ ký

Chữ ký web JSON (JWS) là thông số kỹ thuật hướng dẫn cơ chế tạo chữ ký cho JWT. Dữ liệu đầu vào cho chữ ký là mảng byte của nội dung sau:

{Base64url encoded header}.{Base64url encoded claim set}

Bạn phải sử dụng thuật toán ký trong tiêu đề JWT khi tính toán chữ ký. Thuật toán ký duy nhất mà Máy chủ uỷ quyền OAuth 2.0 của Google hỗ trợ là RSA sử dụng thuật toán băm SHA-256. Giá trị này được biểu thị dưới dạng RS256 trong trường alg trong tiêu đề JWT.

Ký bản trình bày UTF-8 của dữ liệu đầu vào bằng SHA256withRSA (còn gọi là RSASSA-PKCS1-V1_5-SIGN với hàm băm SHA-256) bằng khoá riêng tư lấy từ . Kết quả sẽ là một mảng byte.

Sau đó, chữ ký phải được mã hoá Base64url. Tiêu đề, tập hợp thông báo xác nhận quyền sở hữu và chữ ký được nối với nhau bằng ký tự dấu chấm (.). Kết quả là JWT. Mã này phải như sau (đã thêm dấu ngắt dòng để rõ ràng):

{Base64url encoded header}.
{Base64url encoded claim set}.
{Base64url encoded signature}

Dưới đây là ví dụ về JWT trước khi mã hoá Base64url:

{"alg":"RS256","typ":"JWT"}.
{
"iss":"761326798069-r5mljlln1rd4lrbhg75efgigp36m78j5@developer.gserviceaccount.com",
"scope":"https://www.googleapis.com/auth/prediction",
"aud":"https://oauth2.googleapis.com/token",
"exp":1328554385,
"iat":1328550785
}.
[signature bytes]

Dưới đây là ví dụ về một JWT đã được ký và sẵn sàng truyền:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiI3NjEzMjY3OTgwNjktcjVtbGpsbG4xcmQ0bHJiaGc3NWVmZ2lncDM2bTc4ajVAZGV2ZWxvcGVyLmdzZXJ2aWNlYWNjb3VudC5jb20iLCJzY29wZSI6Imh0dHBzOi8vd3d3Lmdvb2dsZWFwaXMuY29tL2F1dGgvcHJlZGljdGlvbiIsImF1ZCI6Imh0dHBzOi8vd3d3Lmdvb2dsZWFwaXMuY29tL29hdXRoMi92NC90b2tlbiIsImV4cCI6MTMyODU1NDM4NSwiaWF0IjoxMzI4NTUwNzg1fQ.UFUt59SUM2_AW4cRU8Y0BYVQsNTo4n7AFsNrqOpYiICDu37vVt-tw38UKzjmUKtcRsLLjrR3gFW3dNDMx_pL9DVjgVHDdYirtrCekUHOYoa1CMR66nxep5q5cBQ4y4u2kIgSvChCTc9pmLLNoIem-ruCecAJYgI9Ks7pTnW1gkOKs0x3YpiLpzplVHAkkHztaXiJdtpBcY1OXyo6jTQCa3Lk2Q3va1dPkh_d--GU2M5flgd8xNBPYw4vxyt0mP59XZlHMpztZt0soSgObf7G3GXArreF_6tpbFsS3z2t5zkEiHuWJXpzcYr5zWTRPDEHsejeBSG8EgpLDce2380ROQ

Tạo yêu cầu mã truy cập

Sau khi tạo JWT đã ký, ứng dụng có thể sử dụng JWT đó để yêu cầu mã truy cập. Yêu cầu mã thông báo truy cập này là một yêu cầu POST HTTPS và nội dung được mã hoá theo URL. URL được hiển thị bên dưới:

https://oauth2.googleapis.com/token

Các thông số sau đây là bắt buộc trong yêu cầu POST HTTPS:

Tên	Mô tả
grant_type	Sử dụng chuỗi sau, được mã hoá URL nếu cần: urn:ietf:params:oauth:grant-type:jwt-bearer
assertion	JWT, bao gồm cả chữ ký.

Dưới đây là tệp báo lỗi thô của yêu cầu POST HTTPS được dùng trong yêu cầu mã thông báo truy cập:

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

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiI3NjEzMjY3OTgwNjktcjVtbGpsbG4xcmQ0bHJiaGc3NWVmZ2lncDM2bTc4ajVAZGV2ZWxvcGVyLmdzZXJ2aWNlYWNjb3VudC5jb20iLCJzY29wZSI6Imh0dHBzOi8vd3d3Lmdvb2dsZWFwaXMuY29tL2F1dGgvcHJlZGljdGlvbiIsImF1ZCI6Imh0dHBzOi8vYWNjb3VudHMuZ29vZ2xlLmNvbS9vL29hdXRoMi90b2tlbiIsImV4cCI6MTMyODU3MzM4MSwiaWF0IjoxMzI4NTY5NzgxfQ.ixOUGehweEVX_UKXv5BbbwVEdcz6AYS-6uQV6fGorGKrHf3LIJnyREw9evE-gs2bmMaQI5_UbabvI4k-mQE4kBqtmSpTzxYBL1TCd7Kv5nTZoUC1CmwmWCFqT9RE6D7XSgPUh_jF1qskLa2w0rxMSjwruNKbysgRNctZPln7cqQ

Dưới đây là cùng một yêu cầu, sử dụng curl:

curl -d 'grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiI3NjEzMjY3OTgwNjktcjVtbGpsbG4xcmQ0bHJiaGc3NWVmZ2lncDM2bTc4ajVAZGV2ZWxvcGVyLmdzZXJ2aWNlYWNjb3VudC5jb20iLCJzY29wZSI6Imh0dHBzOi8vd3d3Lmdvb2dsZWFwaXMuY29tL2F1dGgvcHJlZGljdGlvbiIsImF1ZCI6Imh0dHBzOi8vYWNjb3VudHMuZ29vZ2xlLmNvbS9vL29hdXRoMi90b2tlbiIsImV4cCI6MTMyODU3MzM4MSwiaWF0IjoxMzI4NTY5NzgxfQ.RZVpzWygMLuL-n3GwjW1_yhQhrqDacyvaXkuf8HcJl8EtXYjGjMaW5oiM5cgAaIorrqgYlp4DPF_GuncFqg9uDZrx7pMmCZ_yHfxhSCXru3gbXrZvAIicNQZMFxrEEn4REVuq7DjkTMyCMGCY1dpMa8aWfTQFt3Eh7smLchaZsU
' https://oauth2.googleapis.com/token

Xử lý phản hồi

Nếu JWT và yêu cầu mã truy cập được tạo đúng cách và tài khoản dịch vụ có quyền thực hiện thao tác, thì phản hồi JSON từ Máy chủ uỷ quyền sẽ bao gồm một mã truy cập. Sau đây là ví dụ về phản hồi:

{
  "access_token": "1/8xbJqaOZXSUZbHLl5EOtu1pxz3fmmetKx9W8CV4t79M",
  "scope": "https://www.googleapis.com/auth/prediction"
  "token_type": "Bearer",
  "expires_in": 3600
}

Bạn có thể sử dụng lại mã thông báo truy cập trong khoảng thời gian do giá trị expires_in chỉ định.

Gọi API của Google

GET /drive/v2/files HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

GET https://www.googleapis.com/drive/v2/files?access_token=access_token

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

curl https://www.googleapis.com/drive/v2/files?access_token=access_token

Mã lỗi JWT

Phụ lục: Uỷ quyền tài khoản dịch vụ mà không cần OAuth

Với một số API của Google, bạn có thể thực hiện các lệnh gọi API được uỷ quyền bằng cách sử dụng JWT đã ký trực tiếp dưới dạng mã thông báo mang theo, thay vì mã thông báo truy cập OAuth 2.0. Khi có thể, bạn có thể tránh phải gửi yêu cầu mạng đến máy chủ uỷ quyền của Google trước khi thực hiện lệnh gọi API.

Nếu API mà bạn muốn gọi có định nghĩa dịch vụ được xuất bản trong kho lưu trữ GitHub của API Google, thì bạn có thể thực hiện các lệnh gọi API được uỷ quyền bằng JWT thay vì mã truy cập. Cách làm như sau:

1. Tạo một tài khoản dịch vụ như mô tả ở trên. Hãy nhớ giữ lại tệp JSON mà bạn nhận được khi tạo tài khoản.
2. Sử dụng bất kỳ thư viện JWT tiêu chuẩn nào, chẳng hạn như thư viện có tại jwt.io, hãy tạo một JWT có tiêu đề và tải trọng như ví dụ sau:

   {
     "alg": "RS256",
     "typ": "JWT",
     "kid": "abcdef1234567890"
   }
   .
   {
     "iss": "123456-compute@developer.gserviceaccount.com",
     "sub": "123456-compute@developer.gserviceaccount.com",
     "aud": "https://firestore.googleapis.com/",
     "iat": 1511900000,
     "exp": 1511903600
   }

• Đối với trường kid trong tiêu đề, hãy chỉ định mã nhận dạng khoá riêng tư của tài khoản dịch vụ. Bạn có thể tìm thấy giá trị này trong trường private_key_id của tệp JSON của tài khoản dịch vụ.
• Đối với các trường iss và sub, hãy chỉ định địa chỉ email của tài khoản dịch vụ. Bạn có thể tìm thấy giá trị này trong trường client_email của tệp JSON của tài khoản dịch vụ.
• Đối với trường aud, hãy chỉ định điểm cuối API. Ví dụ: https://SERVICE.googleapis.com/.
• Đối với trường iat, hãy chỉ định thời gian Unix hiện tại và đối với trường exp, hãy chỉ định thời gian chính xác 3600 giây sau, khi JWT hết hạn.

Ký JWT bằng RSA-256 bằng khoá riêng tư có trong tệp JSON của tài khoản dịch vụ.

Ví dụ:

GoogleCredential credential =
        GoogleCredential.fromStream(new FileInputStream("MyProject-1234.json"));
PrivateKey privateKey = credential.getServiceAccountPrivateKey();
String privateKeyId = credential.getServiceAccountPrivateKeyId();

long now = System.currentTimeMillis();

try {
    Algorithm algorithm = Algorithm.RSA256(null, privateKey);
    String signedJwt = JWT.create()
        .withKeyId(privateKeyId)
        .withIssuer("123456-compute@developer.gserviceaccount.com")
        .withSubject("123456-compute@developer.gserviceaccount.com")
        .withAudience("https://firestore.googleapis.com/")
        .withIssuedAt(new Date(now))
        .withExpiresAt(new Date(now + 3600 * 1000L))
        .sign(algorithm);
} catch ...

iat = time.time()
exp = iat + 3600
payload = {'iss': '123456-compute@developer.gserviceaccount.com',
           'sub': '123456-compute@developer.gserviceaccount.com',
           'aud': 'https://firestore.googleapis.com/',
           'iat': iat,
           'exp': exp}
additional_headers = {'kid': PRIVATE_KEY_ID_FROM_JSON}
signed_jwt = jwt.encode(payload, PRIVATE_KEY_FROM_JSON, headers=additional_headers,
                       algorithm='RS256')

1. Gọi API, sử dụng JWT đã ký làm mã thông báo người mang:

   GET /v1/projects/abc/databases/123/indexes HTTP/1.1
   Authorization: Bearer SIGNED_JWT
   Host: firestore.googleapis.com

Triển khai tính năng Bảo vệ nhiều tài khoản

Bạn nên thực hiện thêm một bước để bảo vệ tài khoản của người dùng, đó là triển khai tính năng Bảo vệ nhiều tài khoản bằng cách sử dụng Dịch vụ bảo vệ nhiều tài khoản của Google. Dịch vụ này cho phép bạn đăng ký nhận thông báo về sự kiện bảo mật. Thông báo này cung cấp thông tin cho ứng dụng của bạn về những thay đổi lớn đối với tài khoản người dùng. Sau đó, bạn có thể sử dụng thông tin này để hành động tuỳ thuộc vào cách bạn quyết định phản hồi các sự kiện.

Sau đây là một số ví dụ về loại sự kiện mà Dịch vụ bảo vệ nhiều tài khoản của Google gửi đến ứng dụng của bạn:

• https://schemas.openid.net/secevent/risc/event-type/sessions-revoked
• https://schemas.openid.net/secevent/oauth/event-type/token-revoked
• https://schemas.openid.net/secevent/risc/event-type/account-disabled

Hãy xem trang Bảo vệ tài khoản người dùng bằng tính năng Bảo vệ nhiều tài khoản để biết thêm thông tin về cách triển khai tính năng Bảo vệ nhiều tài khoản và danh sách đầy đủ các sự kiện hiện có.