Google cam kết nâng cao công bằng chủng tộc cho các cộng đồng Da đen. Xem làm thế nào.

OAuth 2.0 cho TV và các ứng dụng thiết bị đầu vào có giới hạn

Tài liệu này giải thích cách triển khai ủy quyền OAuth 2.0 để truy cập các API của Google thông qua các ứng dụng chạy trên các thiết bị như TV, bảng điều khiển trò chơi và máy in. Cụ thể hơn, quy trình này được thiết kế cho các thiết bị không có quyền truy cập vào trình duyệt hoặc có khả năng nhập liệu hạn chế.

OAuth 2.0 cho phép người dùng chia sẻ dữ liệu cụ thể với một ứng dụng trong khi vẫn giữ bí mật tên người dùng, mật khẩu và thông tin khác của họ. Ví dụ: một ứng dụng TV có thể sử dụng OAuth 2.0 để có quyền chọn tệp được lưu trữ trên Google Drive.

Vì các ứng dụng sử dụng luồng này được phân phối cho các thiết bị riêng lẻ, nên người ta cho rằng các ứng dụng đó không thể giữ bí mật. Họ có thể truy cập các API của Google trong khi người dùng có mặt tại ứng dụng hoặc khi ứng dụng đang chạy trong nền.

Giải pháp thay thế

Nếu bạn đang viết ứng dụng cho một nền tảng như Android, iOS, macOS, Linux hoặc Windows (bao gồm cả Nền tảng Windows chung), có quyền truy cập vào trình duyệt và khả năng nhập liệu đầy đủ, hãy sử dụng quy trình OAuth 2.0 cho các ứng dụng dành cho thiết bị di động và máy tính để bàn . (Bạn nên sử dụng quy trình đó ngay cả khi ứng dụng của bạn là một công cụ dòng lệnh không có giao diện đồ họa.)

Điều kiện tiên quyết

Bật API cho dự án của bạn

Bất kỳ ứng dụng nào gọi API Google đều cần bật các API đó trong API Console.

Để kích hoạt một API cho dự án của bạn:

  1. Open the API Library trong Google API Console.
  2. If prompted, select a project, or create a new one.
  3. API Library liệt kê tất cả các API có sẵn, được nhóm theo họ sản phẩm và mức độ phổ biến. Nếu API bạn muốn bật không hiển thị trong danh sách, hãy sử dụng tìm kiếm để tìm nó hoặc nhấp vào Xem tất cả trong họ sản phẩm mà nó thuộc về.
  4. Chọn API bạn muốn bật, sau đó nhấp vào nút Bật .
  5. If prompted, enable billing.
  6. If prompted, read and accept the API's Terms of Service.

Tạo thông tin xác thực ủy quyền

Bất kỳ ứng dụng nào sử dụng OAuth 2.0 để truy cập Google API đều phải có thông tin xác thực ủy quyền xác định ứng dụng đó với máy chủ OAuth 2.0 của Google. Các bước sau giải thích cách tạo thông tin xác thực cho dự án của bạn. Các ứng dụng của bạn sau đó có thể sử dụng thông tin đăng nhập để truy cập các API mà bạn đã bật cho dự án đó.

  1. Go to the Credentials page.
  2. Nhấp vào Tạo thông tin xác thực> ID ứng dụng khách OAuth .
  3. Chọn TV và loại ứng dụng Thiết bị đầu vào hạn chế .
  4. Đặt tên cho ứng dụng khách OAuth 2.0 của bạn và nhấp vào Tạo .

Xác định phạm vi truy cập

Phạm vi cho phép ứng dụng của bạn chỉ yêu cầu quyền truy cập vào các tài nguyên mà nó cần đồng thời cho phép người dùng kiểm soát lượng truy cập mà họ cấp cho ứng dụng của bạn. Do đó, có thể có mối quan hệ nghịch đảo giữa số phạm vi được yêu cầu và khả năng nhận được sự đồng ý của người dùng.

Trước khi bắt đầu triển khai ủy quyền OAuth 2.0, chúng tôi khuyên bạn nên xác định các phạm vi mà ứng dụng của bạn sẽ cần quyền truy cập.

Xem danh sách Phạm vi được phép cho các ứng dụng hoặc thiết bị đã cài đặt.

Nhận mã thông báo truy cập OAuth 2.0

Mặc dù ứng dụng của bạn chạy trên thiết bị có khả năng nhập hạn chế, người dùng phải có quyền truy cập riêng vào thiết bị có khả năng nhập phong phú hơn để hoàn thành quy trình cấp quyền này. Quy trình có các bước sau:

  1. Ứng dụng của bạn sẽ gửi một yêu cầu đến máy chủ ủy quyền của Google để xác định các phạm vi mà ứng dụng của bạn sẽ yêu cầu quyền truy cập.
  2. Máy chủ phản hồi với một số phần thông tin được sử dụng trong các bước tiếp theo, chẳng hạn như mã thiết bị và mã người dùng.
  3. Bạn hiển thị thông tin mà người dùng có thể nhập trên một thiết bị riêng biệt để cấp phép ứng dụng của bạn.
  4. Ứng dụng của bạn bắt đầu thăm dò máy chủ ủy quyền của Google để xác định xem người dùng có ủy quyền ứng dụng của bạn hay không.
  5. Người dùng chuyển sang thiết bị có khả năng nhập liệu phong phú hơn, khởi chạy trình duyệt web, điều hướng đến URL hiển thị ở bước 3 và nhập mã cũng được hiển thị ở bước 3. Sau đó, người dùng có thể cấp (hoặc từ chối) quyền truy cập vào ứng dụng của bạn.
  6. Phản hồi tiếp theo cho yêu cầu thăm dò của bạn chứa các mã thông báo mà ứng dụng của bạn cần để thay mặt người dùng ủy quyền yêu cầu. (Nếu người dùng từ chối quyền truy cập vào ứng dụng của bạn, phản hồi không chứa mã thông báo.)

Hình ảnh dưới đây minh họa quá trình này:

Người dùng đăng nhập trên một thiết bị riêng có trình duyệt

Các phần sau đây giải thích chi tiết các bước này. Với phạm vi khả năng và môi trường thời gian chạy mà thiết bị có thể có, các ví dụ được hiển thị trong tài liệu này sử dụng tiện ích dòng lệnh curl . Những ví dụ này sẽ dễ dàng chuyển sang các ngôn ngữ và thời gian chạy khác nhau.

Bước 1: Yêu cầu thiết bị và mã người dùng

Trong bước này, thiết bị của bạn sẽ gửi một yêu cầu HTTP POST đến máy chủ ủy quyền của Google, tại https://oauth2.googleapis.com/device/code , xác định ứng dụng của bạn cũng như phạm vi truy cập mà ứng dụng của bạn muốn truy cập trên người dùng thay mặt. Bạn nên truy xuất URL này từ tài liệu Khám phá bằng giá trị siêu dữ liệu device_authorization_endpoint . Bao gồm các tham số yêu cầu HTTP sau:

Thông số
client_id Cần thiết

ID khách hàng cho ứng dụng của bạn. Bạn có thể tìm thấy giá trị này trong API Console Credentials page.

scope Cần thiết

Danh sách các phạm vi được phân tách bằng dấu cách xác định các tài nguyên mà ứng dụng của bạn có thể truy cập thay mặt cho người dùng. Các giá trị này thông báo cho màn hình chấp thuận mà Google hiển thị cho người dùng. Xem danh sách Phạm vi được phép cho các ứng dụng hoặc thiết bị đã cài đặt.

Phạm vi cho phép ứng dụng của bạn chỉ yêu cầu quyền truy cập vào các tài nguyên mà nó cần đồng thời cho phép người dùng kiểm soát lượng truy cập mà họ cấp cho ứng dụng của bạn. Do đó, có một mối quan hệ nghịch đảo giữa số lượng phạm vi được yêu cầu và khả năng nhận được sự đồng ý của người dùng.

Các ví dụ

Đoạn mã sau đây cho thấy một yêu cầu mẫu:

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

client_id=client_id&scope=email%20profile

Ví dụ này cho thấy một lệnh curl để gửi cùng một yêu cầu:

curl -d "client_id=client_id&scope=email%20profile" \
     https://oauth2.googleapis.com/device/code

Bước 2: Xử lý phản hồi của máy chủ ủy quyền

Máy chủ ủy quyền sẽ trả về một trong các phản hồi sau:

Phản hồi thành công

Nếu yêu cầu hợp lệ, phản hồi của bạn sẽ là một đối tượng JSON chứa các thuộc tính sau:

Tính chất
device_code Một giá trị mà Google chỉ định duy nhất để xác định thiết bị chạy ứng dụng yêu cầu ủy quyền. Người dùng sẽ cấp quyền cho thiết bị đó từ một thiết bị khác với khả năng nhập liệu phong phú hơn. Ví dụ: người dùng có thể sử dụng máy tính xách tay hoặc điện thoại di động để cấp phép một ứng dụng đang chạy trên TV. Trong trường hợp này, device_code nhận dạng TV.

Mã này cho phép thiết bị chạy ứng dụng xác định an toàn xem người dùng đã cấp hay từ chối quyền truy cập.

expires_in Khoảng thời gian, tính bằng giây, mã device_codeuser_code người dùng hợp lệ. Nếu trong thời gian đó, người dùng không hoàn thành quy trình cấp quyền và thiết bị của bạn cũng không thăm dò ý kiến ​​để truy xuất thông tin về quyết định của người dùng, bạn có thể cần phải khởi động lại quy trình này từ bước 1.
interval Khoảng thời gian, tính bằng giây, thiết bị của bạn sẽ đợi giữa các yêu cầu thăm dò. Ví dụ: nếu giá trị là 5 , thiết bị của bạn sẽ gửi yêu cầu thăm dò ý kiến ​​đến máy chủ ủy quyền của Google sau mỗi năm giây. Xem bước 3 để biết thêm chi tiết.
user_code Giá trị phân biệt chữ hoa chữ thường xác định cho Google phạm vi mà ứng dụng đang yêu cầu quyền truy cập. Giao diện người dùng của bạn sẽ hướng dẫn người dùng nhập giá trị này trên một thiết bị riêng biệt với khả năng nhập phong phú hơn. Sau đó, Google sử dụng giá trị để hiển thị tập hợp phạm vi chính xác khi nhắc người dùng cấp quyền truy cập vào ứng dụng của bạn.
verification_url Một URL mà người dùng phải điều hướng đến, trên một thiết bị riêng biệt, để nhập user_code và cấp hoặc từ chối quyền truy cập vào ứng dụng của bạn. Giao diện người dùng của bạn cũng sẽ hiển thị giá trị này.

Đoạn mã sau đây cho thấy một phản hồi mẫu:

{
  "device_code": "4/4-GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8",
  "user_code": "GQVQ-JKEC",
  "verification_url": "https://www.google.com/device",
  "expires_in": 1800,
  "interval": 5
}

Đã vượt quá hạn ngạch phản hồi

Nếu yêu cầu mã thiết bị của bạn đã vượt quá hạn ngạch được liên kết với ID khách hàng của bạn, bạn sẽ nhận được phản hồi 403, có lỗi sau:

{
  "error_code": "rate_limit_exceeded"
}

Trong trường hợp đó, hãy sử dụng chiến lược dự phòng để giảm tỷ lệ yêu cầu.

Bước 3: Hiển thị mã người dùng

Hiển thị verification_urluser_code thu được ở bước 2 cho người dùng. Cả hai giá trị đều có thể chứa bất kỳ ký tự có thể in nào từ bộ ký tự US-ASCII. Các nội dung mà bạn hiển thị cho người dùng nên hướng dẫn người sử dụng để điều hướng đến verification_url trên một thiết bị riêng biệt và nhập user_code .

Thiết kế giao diện người dùng (UI) của bạn với các quy tắc sau:

  • user_code
    • user_code phải được hiển thị trong trường có thể xử lý các ký tự kích thước 15 'W'. Nói cách khác, nếu bạn có thể hiển thị đúng mã WWWWWWWWWWWWWWW , giao diện người dùng của bạn hợp lệ và chúng tôi khuyên bạn nên sử dụng giá trị chuỗi đó khi thử nghiệm cách hiển thị user_code trong giao diện người dùng của bạn.
    • user_code có phân biệt chữ hoa chữ thường và không được sửa đổi theo bất kỳ cách nào, chẳng hạn như thay đổi chữ hoa và chèn các ký tự định dạng khác.
  • verification_url
    • Không gian nơi bạn hiển thị verification_url phải đủ rộng để xử lý chuỗi URL dài 40 ký tự.
    • Bạn không nên sửa đổi verification_url theo bất kỳ cách nào, ngoại trừ tùy chọn loại bỏ lược đồ để hiển thị. Nếu bạn định loại bỏ lược đồ (ví dụ: https:// ) khỏi URL vì lý do hiển thị, hãy đảm bảo ứng dụng của bạn có thể xử lý cả hai biến thể httphttps .

Bước 4: Thăm dò ý kiến ​​máy chủ ủy quyền của Google

Vì người dùng sẽ sử dụng một thiết bị riêng biệt để điều hướng đến verification_url và cấp (hoặc từ chối) quyền truy cập, thiết bị yêu cầu không được thông báo tự động khi người dùng phản hồi yêu cầu truy cập. Vì lý do đó, thiết bị yêu cầu cần thăm dò ý kiến ​​của máy chủ ủy quyền của Google để xác định thời điểm người dùng đã phản hồi yêu cầu.

Thiết bị yêu cầu sẽ tiếp tục gửi các yêu cầu thăm dò cho đến khi nhận được phản hồi cho biết rằng người dùng đã phản hồi yêu cầu truy cập hoặc cho đến khi mã device_codeuser_code lấy được ở bước 2 đã hết hạn. interval trả về trong bước 2 chỉ định lượng thời gian, tính bằng giây, để chờ giữa các yêu cầu.

URL của điểm cuối để thăm dò ý kiến ​​là https://oauth2.googleapis.com/token . Yêu cầu thăm dò chứa các thông số sau:

Thông số
client_id ID khách hàng cho ứng dụng của bạn. Bạn có thể tìm thấy giá trị này trong API Console Credentials page.
client_secret Bí mật khách hàng cho client_id đã cung cấp. Bạn có thể tìm thấy giá trị này trong API Console Credentials page.
device_code device_code được máy chủ ủy quyền trả về ở bước 2 .
grant_type Đặt giá trị này thành urn:ietf:params:oauth:grant-type:device_code .

Các ví dụ

Đoạn mã sau đây cho thấy một yêu cầu mẫu:

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

client_id=client_id&
client_secret=client_secret&
device_code=device_code&
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code

Ví dụ này cho thấy một lệnh curl để gửi cùng một yêu cầu:

curl -d "client_id=client_id&client_secret=client_secret& \
         device_code=device_code& \
         grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code" \
         -H "Content-Type: application/x-www-form-urlencoded" \
         /token

Bước 5: Người dùng phản hồi yêu cầu truy cập

Hình ảnh sau đây hiển thị một trang tương tự như những gì người dùng nhìn thấy khi họ điều hướng đến verification_url mà bạn đã hiển thị ở bước 3 :

Kết nối thiết bị bằng cách nhập mã

Sau khi nhập user_code và, nếu chưa đăng nhập, đăng nhập vào Google, người dùng sẽ thấy màn hình đồng ý như hình dưới đây:

Ví dụ về màn hình đồng ý cho ứng dụng khách thiết bị

Bước 6: Xử lý phản hồi cho các yêu cầu thăm dò

Máy chủ ủy quyền của Google phản hồi từng yêu cầu thăm dò bằng một trong các phản hồi sau:

Chấp thuận quyền truy cập

Nếu người dùng đã cấp quyền truy cập vào thiết bị (bằng cách nhấp vào Allow trên màn hình đồng ý), thì phản hồi sẽ chứa mã thông báo truy cập và mã làm mới. Các mã thông báo cho phép thiết bị của bạn thay mặt người dùng truy cập các API của Google . (Thuộc tính scope trong phản hồi xác định API mà thiết bị có thể truy cập.)

Trong trường hợp này, phản hồi API chứa các trường sau:

Lĩnh vực
access_token Mã thông báo mà ứng dụng của bạn gửi để cho phép một yêu cầu API của Google.
expires_in Thời gian tồn tại còn lại của mã thông báo truy cập tính bằng giây.
refresh_token Mã thông báo mà bạn có thể sử dụng để lấy mã thông báo truy cập mới. Làm mới mã thông báo có giá trị cho đến khi người dùng thu hồi quyền truy cập. Lưu ý rằng mã thông báo làm mới luôn được trả lại cho các thiết bị.
scope Các phạm vi truy cập được cấp bởi access_token biểu thị dưới dạng danh sách các chuỗi phân biệt bằng dấu cách, phân biệt chữ hoa chữ thường.
token_type Loại mã thông báo được trả lại. Tại thời điểm này, giá trị của trường này luôn được đặt thành Bearer .

Đoạn mã sau đây cho thấy một phản hồi mẫu:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "openid https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email",
  "token_type": "Bearer",
  "refresh_token": "1/xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

Mã thông báo truy cập có thời gian tồn tại hạn chế. Nếu ứng dụng của bạn cần quyền truy cập vào một API trong một khoảng thời gian dài, nó có thể sử dụng mã làm mới để lấy mã thông báo truy cập mới. Nếu ứng dụng của bạn cần loại quyền truy cập này, thì ứng dụng sẽ lưu trữ mã thông báo làm mới để sử dụng sau này.

Quyền truy cập bị từ chối

Nếu người dùng từ chối cấp quyền truy cập vào thiết bị, thì phản hồi của máy chủ có mã trạng thái phản hồi HTTP 403 ( Forbidden ). Phản hồi có lỗi sau:

{
  "error": "access_denied",
  "error_description": "Forbidden"
}

Cấp phép đang chờ xử lý

Nếu người dùng chưa hoàn thành quy trình ủy quyền, thì máy chủ sẽ trả về mã trạng thái phản hồi HTTP 428 ( Precondition Required ). Phản hồi có lỗi sau:

{
  "error": "authorization_pending",
  "error_description": "Precondition Required"
}

Thăm dò ý kiến ​​quá thường xuyên

Nếu thiết bị gửi yêu cầu thăm dò quá thường xuyên, thì máy chủ sẽ trả về mã trạng thái phản hồi HTTP 403 ( Forbidden ). Phản hồi có lỗi sau:

{
  "error": "slow_down",
  "error_description": "Forbidden"
}

Các lỗi khác

Máy chủ ủy quyền cũng trả về lỗi nếu yêu cầu bỏ phiếu thiếu bất kỳ tham số bắt buộc nào hoặc có giá trị tham số không chính xác. Những yêu cầu này thường có mã trạng thái phản hồi HTTP 400 ( Bad Request ) hoặc 401 ( Unauthorized ). Những lỗi đó bao gồm:

lỗi Mã trạng thái HTTP Sự miêu tả
invalid_client 401 Không tìm thấy ứng dụng OAuth. Ví dụ: lỗi này xảy ra nếu giá trị tham số client_id không hợp lệ.
invalid_grant 400 Giá trị tham số code không hợp lệ.
unsupported_grant_type 400 Giá trị tham số grant_type không hợp lệ.

Gọi API Google

Sau khi ứng dụng của bạn có được mã thông báo truy cập, bạn có thể sử dụng mã này để thực hiện các cuộc gọi tới API Google thay mặt cho một tài khoản người dùng nhất định nếu (các) phạm vi truy cập mà API yêu cầu đã được cấp. Để làm điều này, bao gồm access token trong một yêu cầu đến API bằng cách bao gồm cả một access_token tham số truy vấn hoặc một Authorization tiêu đề HTTP Bearer giá trị. Khi có thể, tiêu đề HTTP được ưu tiên hơn, vì các chuỗi truy vấn có xu hướng hiển thị trong nhật ký máy chủ. Trong hầu hết các trường hợp, bạn có thể sử dụng thư viện ứng dụng khách để thiết lập lệnh gọi của mình tới API Google (ví dụ: khi gọi API tệp Drive ).

Bạn có thể thử tất cả các API của Google và xem phạm vi của chúng tại Sân chơi OAuth 2.0 .

Ví dụ về HTTP GET

Một lệnh gọi đến điểm cuối drive.files (API Tệp ​​Drive) bằng cách sử dụng tiêu đề HTTP Authorization: Bearer có thể trông giống như sau. Lưu ý rằng bạn cần chỉ định mã thông báo truy cập của riêng mình:

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

Đây là lệnh gọi đến cùng một API cho người dùng đã xác thực bằng cách sử dụng tham số chuỗi truy vấn access_token :

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

ví dụ curl

Bạn có thể kiểm tra các lệnh này bằng ứng dụng dòng lệnh curl . Dưới đây là một ví dụ sử dụng tùy chọn tiêu đề HTTP (ưu tiên):

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

Hoặc, cách khác, tùy chọn tham số chuỗi truy vấn:

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

Làm mới mã thông báo truy cập

Mã thông báo truy cập hết hạn định kỳ và trở thành thông tin xác thực không hợp lệ cho một yêu cầu API liên quan. Bạn có thể làm mới mã thông báo truy cập mà không cần nhắc người dùng cấp quyền (kể cả khi người dùng không có mặt) nếu bạn yêu cầu quyền truy cập ngoại tuyến vào các phạm vi được liên kết với mã thông báo.

Để làm mới mã thông báo truy cập, ứng dụng của bạn sẽ gửi yêu cầu HTTPS POST tới máy chủ ủy quyền của Google ( https://oauth2.googleapis.com/token ) bao gồm các thông số sau:

Lĩnh vực
client_id ID khách hàng lấy được từ API Console.
client_secret Bí mật khách hàng có được từ API Console.
grant_type Như đã định nghĩa trong đặc tả OAuth 2.0 , giá trị của trường này phải được đặt thành refresh_token .
refresh_token Mã làm mới được trả lại từ trao đổi mã ủy quyền.

Đoạn mã sau đây cho thấy một yêu cầu mẫu:

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

client_id=your_client_id&
client_secret=your_client_secret&
refresh_token=refresh_token&
grant_type=refresh_token

Miễn là người dùng chưa thu hồi quyền truy cập đã cấp cho ứng dụng, máy chủ mã thông báo sẽ trả về đối tượng JSON có chứa mã thông báo truy cập mới. Đoạn mã sau đây cho thấy một phản hồi mẫu:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
  "token_type": "Bearer"
}

Lưu ý rằng có giới hạn về số lượng mã làm mới sẽ được phát hành; một giới hạn cho mỗi kết hợp khách hàng / người dùng và một giới hạn khác cho mỗi người dùng trên tất cả các khách hàng. Bạn nên lưu mã thông báo làm mới trong bộ nhớ lâu dài và tiếp tục sử dụng chúng miễn là chúng vẫn còn hiệu lực. Nếu ứng dụng của bạn yêu cầu quá nhiều mã làm mới, nó có thể gặp phải những giới hạn này, trong trường hợp đó, các mã làm mới cũ hơn sẽ ngừng hoạt động.

Thu hồi mã thông báo

Trong một số trường hợp, người dùng có thể muốn thu hồi quyền truy cập được cấp cho một ứng dụng. Người dùng có thể thu hồi quyền truy cập bằng cách truy cập Cài đặt tài khoản . Xem phần Xóa trang web hoặc quyền truy cập ứng dụng của Trang web và ứng dụng của bên thứ ba có quyền truy cập vào tài liệu hỗ trợ tài khoản của bạn để biết thêm thông tin.

Ứng dụng cũng có thể thu hồi quyền truy cập được cấp theo chương trình. Việc thu hồi có lập trình rất quan trọng trong trường hợp người dùng hủy đăng ký, xóa ứng dụng hoặc tài nguyên API mà ứng dụng yêu cầu đã thay đổi đáng kể. Nói cách khác, một phần của quá trình xóa có thể bao gồm yêu cầu API để đảm bảo các quyền đã cấp trước đó cho ứng dụng bị xóa.

Để thu hồi mã thông báo theo chương trình, ứng dụng của bạn yêu cầu https://oauth2.googleapis.com/revoke và bao gồm mã thông báo dưới dạng tham số:

curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
        https://oauth2.googleapis.com/revoke?token={token}

Mã thông báo có thể là mã thông báo truy cập hoặc mã làm mới. Nếu mã thông báo là mã thông báo truy cập và nó có mã thông báo làm mới tương ứng, thì mã làm mới cũng sẽ bị thu hồi.

Nếu việc thu hồi được xử lý thành công, thì mã trạng thái HTTP của phản hồi là 200 . Đối với các điều kiện lỗi, mã trạng thái HTTP 400 được trả về cùng với mã lỗi.

Phạm vi được phép

Luồng OAuth 2.0 dành cho thiết bị chỉ được hỗ trợ cho các phạm vi sau:

Kết nối OpenID , Đăng nhập bằng Google

  • email
  • openid
  • profile

API ổ đĩa

  • https://www.googleapis.com/auth/drive.appdata
  • https://www.googleapis.com/auth/drive.file

API YouTube

  • https://www.googleapis.com/auth/youtube
  • https://www.googleapis.com/auth/youtube.readonly