OAuth 2.0 dành cho TV và ứng dụng thiết bị đầu vào hạn chế

Tài liệu này giải thích cách triển khai quy trình uỷ quyền OAuth 2.0 để truy cập vào 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, máy chơi 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 bị 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ữ tên người dùng, mật khẩu và các thông tin khác ở chế độ riêng tư. Ví dụ: một ứng dụng TV có thể sử dụng OAuth 2.0 để được cấp quyền chọn một tệp được lưu trữ trên Google Drive.

Vì các ứng dụng sử dụng quy trình này được phân phối cho từng thiết bị, nên giả định rằng các ứng dụng không thể giữ bí mật. Các ứng dụng này có thể truy cập vào API của Google trong khi người dùng đang sử dụng ứng dụng hoặc khi ứng dụng đang chạy ở chế độ nền.

Các phương án 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 phổ biến), có quyền truy cập vào trình duyệt và đầy đủ chức năng nhập, hãy sử dụng quy trình OAuth 2.0 cho ứng dụng dành cho thiết bị di động và máy tính. (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 đồ hoạ.)

Nếu bạn chỉ muốn người dùng đăng nhập bằng Tài khoản Google và sử dụng mã nhận dạng JWT để lấy thông tin cơ bản về hồ sơ người dùng, hãy xem phần Đăng nhập trên TV và thiết bị đầu vào có giới hạn.

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

Bật API cho dự án

Mọi ứng dụng gọi API của Google đều cần bật các API đó trong .

Cách bật API cho dự án:

1. trong .
3. liệt kê tất cả những API có sẵn, được nhóm theo nhóm sản phẩm và mức độ phổ biến. Nếu API bạn muốn bật không xuất hiện trong danh sách, hãy sử dụng tính năng tìm kiếm để tìm API đó hoặc nhấp vào Xem tất cả trong nhóm sản phẩm mà API đó thuộc về.
4. Chọn API bạn muốn bật, sau đó nhấp vào nút Bật.

Tạo thông tin xác thực uỷ quyền

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

2. Nhấp vào Tạo thông tin xác thực > Mã ứng dụng khách OAuth.
3. Chọn loại ứng dụng TV và thiết bị đầu vào có giới hạn.
4. Đặt tên cho ứng dụng OAuth 2.0 rồi 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à ứng dụng cần, đồng thời cho phép người dùng kiểm soát mức độ 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ố 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.

Trước khi bắt đầu triển khai quy trình uỷ quyền OAuth 2.0, bạn nên xác định các phạm vi mà ứng dụng của bạn cần có quyền truy cập.

Lưu ý: Tính năng uỷ quyền gia tăng không được hỗ trợ cho các ứng dụng hoặc thiết bị đã cài đặt.

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

Nếu ứng dụng công khai của bạn sử dụng các phạm vi cho phép truy cập vào một số dữ liệu người dùng nhất định, thì ứng dụng đó phải hoàn tất quy trình xác minh. Nếu thấy ứng dụng chưa xác minh trên màn hình khi kiểm thử ứng dụng, bạn phải gửi yêu cầu xác minh để xoá ứng dụng đó. Tìm hiểu thêm về ứng dụng chưa được xác minh và xem câu trả lời cho các câu hỏi thường gặp về việc xác minh ứng dụng trong Trung tâm trợ giúp.

Lấy mã truy cập OAuth 2.0

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

1. Ứng dụng của bạn gửi một yêu cầu đến máy chủ uỷ 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ủ sẽ phản hồi bằng một số thông tin được 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 để uỷ quyền cho ứng dụng của bạn.
4. Ứng dụng của bạn bắt đầu thăm dò ý kiến máy chủ uỷ quyền của Google để xác định xem người dùng có uỷ quyền cho ứng dụng của bạn hay không.
5. Người dùng chuyển sang một thiết bị có nhiều chức năng nhập hơn, chạy một trình duyệt web, chuyển đến URL hiển thị ở bước 3 và nhập một mã cũng 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ò ý kiến của bạn chứa các mã thông báo mà ứng dụng của bạn cần để uỷ quyền cho các yêu cầu thay mặt cho người dùng. (Nếu người dùng từ chối quyền truy cập vào ứng dụng của bạn, thì phản hồi sẽ không chứa mã thông báo.)

Hình ảnh dưới đây minh hoạ quy trình này:

Phần sau đây giải thích chi tiết các bước này. Do phạm vi chức năng và môi trường thời gian chạy mà thiết bị có thể có, các ví dụ trong tài liệu này sử dụng tiện ích dòng lệnh curl. Bạn có thể dễ dàng chuyển các ví dụ này sang nhiều ngôn ngữ và môi trường thời gian chạy.

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

Tham số
client_id	Bắt buộc Mã ứng dụng khách cho ứng dụng của bạn. Bạn có thể tìm thấy giá trị này trong .
scope	Bắt buộc Một danh sách các phạm vi được phân tách bằng dấu cách xác định những 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 sẽ cung cấp thông tin cho màn hình yêu cầu đồng ý 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à ứng dụng cần, đồng thời cho phép người dùng kiểm soát mức độ truy cập mà họ cấp cho ứng dụng. Do đó, có 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.

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 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ủ uỷ quyền

Máy chủ uỷ 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:

Thuộc tính
device_code	Một giá trị mà Google chỉ định riêng để xác định thiết bị chạy ứng dụng yêu cầu uỷ quyền. Người dùng sẽ uỷ quyền cho thiết bị đó từ một thiết bị khác có nhiều tính năng nhập 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 để uỷ quyền cho một ứng dụng chạy trên TV. Trong trường hợp này, device_code xác định TV. Mã này cho phép thiết bị đang chạy ứng dụng xác định một cách 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_code và user_code hợp lệ. Nếu trong khoảng thời gian đó, người dùng không hoàn tất quy trình uỷ 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, thì bạn có thể cần phải bắt đầu lại quy trình này từ bước 1.
interval	Khoảng thời gian (tính bằng giây) mà thiết bị của bạn phải đợi giữa các yêu cầu thăm dò ý kiến. Ví dụ: nếu giá trị là 5, thì thiết bị của bạn sẽ gửi một yêu cầu thăm dò ý kiến đến máy chủ uỷ quyền của Google mỗi 5 giây. Hãy xem bước 3 để biết thêm thông tin chi tiết.
user_code	Giá trị có phân biệt chữ hoa chữ thường giúp Google xác định các phạm vi mà ứng dụng đang yêu cầu quyền truy cập. Giao diện người dùng 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 có nhiều chức năng nhập hơn. Sau đó, Google sẽ sử dụng giá trị này để hiển thị đúng nhóm phạm vi 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 vào 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
}

Phản hồi khi vượt quá hạn mức

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

{
  "error_code": "rate_limit_exceeded"
}

Trong trường hợp đó, hãy sử dụng chiến lược thời gian đợi để giảm tốc độ yêu cầu.

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

Hiển thị verification_url và user_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ự in được nào trong bộ ký tự US-ASCII. Nội dung mà bạn hiển thị cho người dùng phải hướng dẫn người dùng chuyển đến verification_url trên một thiết bị riêng biệt và nhập user_code.

Hãy thiết kế giao diện người dùng (UI) theo các quy tắc sau:

• user_code
  • user_code phải hiển thị trong một trường có thể xử lý 15 ký tự kích thước "W". Nói cách khác, nếu bạn có thể hiển thị mã WWWWWWWWWWWWWWW đúng cách, thì giao diện người dùng của bạn là hợp lệ và bạn nên sử dụng giá trị chuỗi đó khi kiểm thử cách user_code hiển thị trong giao diện người dùng.
  • 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 chữ thường hoặc chèn các ký tự định dạng khác.
• verification_url
  • Không gian mà bạn hiển thị verification_url phải đủ rộng để xử lý một 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ừ việc tuỳ ý xoá giao thức hiển thị. Nếu bạn dự định xoá 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ả biến thể http và https.

Cảnh báo: Cả hai giá trị này đều có thể thay đổi và bạn không nên mã hoá cứng bất kỳ giá trị nào trong mã của mình. Tương tự, bạn không nên sửa đổi các giá trị theo bất kỳ cách nào ngoại trừ việc xoá tuỳ ý giao thức khỏi verification_url.

Bước 4: Điều tra máy chủ uỷ quyền của Google

Vì người dùng sẽ sử dụng một thiết bị riêng để chuyển đến verification_url và cấp (hoặc từ chối) quyền truy cập, nên thiết bị yêu cầu sẽ không tự động được thông báo 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 máy chủ uỷ 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 phải tiếp tục gửi yêu cầu thăm dò cho đến khi nhận được phản hồi cho biết người dùng đã phản hồi yêu cầu truy cập hoặc cho đến khi device_code và user_code thu được ở bước 2 hết hạn. interval được trả về ở bước 2 chỉ định khoả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ò ý kiến chứa các tham số sau:

Tham số
client_id	Mã ứng dụng khách cho ứng dụng của bạn. Bạn có thể tìm thấy giá trị này trong .
client_secret	Mật khẩu ứng dụng khách cho client_id đã cung cấp. Bạn có thể tìm thấy giá trị này trong .
device_code	device_code do máy chủ uỷ quyền trả về trong bước 2.
grant_type	Đặt giá trị này thành urn:ietf:params:oauth:grant-type:device_code.

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 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" \
         https://oauth2.googleapis.com/token

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

Lưu ý: Ứng dụng của bạn không cần làm gì ở giai đoạn này ngoài việc thăm dò ý kiến máy chủ uỷ quyền như mô tả ở bước trước.

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

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

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

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

Đã nhận được lợi ích mới

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ã truy cập và mã làm mới. Mã thông báo cho phép thiết bị của bạn truy cập vào các API của Google thay mặt cho người dùng. (Thuộc tính scope trong phản hồi xác định những 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:

Trường
access_token	Mã thông báo mà ứng dụng của bạn gửi để uỷ quyền cho một yêu cầu API của Google.
expires_in	Thời gian còn lại của mã truy cập tính bằng giây.
refresh_token	Mã thông báo mà bạn có thể dùng để lấy mã thông báo truy cập mới. Mã thông báo làm mới có hiệu lực cho đến khi người dùng thu hồi quyền truy cập. Xin lưu ý rằng mã thông báo làm mới luôn được trả về cho thiết bị.
scope	Phạm vi truy cập do access_token cấp được biểu thị dưới dạng danh sách các chuỗi phân tách 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ả về. 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 hạn sử dụng. Nếu cần quyền truy cập vào một API trong một khoảng thời gian dài, ứng dụng của bạn có thể sử dụng mã làm mới để lấy mã truy cập mới. Nếu cần loại quyền truy cập này, ứng dụng của bạn sẽ lưu trữ mã làm mới để sử dụng sau.

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ủ sẽ có mã trạng thái phản hồi HTTP 403 (Forbidden). Phản hồi này chứa lỗi sau:

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

Đang chờ uỷ quyền

Nếu người dùng chưa hoàn tất quy trình uỷ 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 sẽ chứa 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 này chứa lỗi sau:

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

Các lỗi khác

Máy chủ uỷ quyền cũng trả về lỗi nếu yêu cầu thăm dò ý kiến bị thiếu bất kỳ thông số bắt buộc nào hoặc có giá trị thông số không chính xác. Các 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	Mô tả
admin_policy_enforced	400	Tài khoản Google không thể uỷ quyền cho một hoặc nhiều phạm vi được yêu cầu do các chính sách của quản trị viên Google Workspace. Hãy xem bài viết trợ giúp dành cho Quản trị viên Google Workspace Kiểm soát ứng dụng nội bộ và ứng dụng bên thứ ba nào truy cập vào dữ liệu trong Google Workspace để biết thêm thông tin về cách quản trị viên có thể hạn chế quyền truy cập vào các phạm vi cho đến khi quyền truy cập được cấp rõ ràng cho mã ứng dụng OAuth của bạn.
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ệ. Loại ứng dụng OAuth không chính xác. Đảm bảo rằng bạn đặt loại ứng dụng cho mã ứng dụng thành TV và thiết bị đầu vào có giới hạn.
invalid_grant	400	Giá trị thông số code không hợp lệ, đã được xác nhận quyền sở hữu hoặc không thể phân tích cú pháp.
unsupported_grant_type	400	Giá trị tham số grant_type không hợp lệ.
org_internal	403	Mã ứng dụng khách OAuth trong yêu cầu là một phần của dự án giới hạn quyền truy cập vào Tài khoản Google trong một Tổ chức Google Cloud cụ thể. Xác nhận cấu hình loại người dùng cho ứng dụng OAuth của bạn.

Gọi API của Google

Sau khi ứng dụng của bạn nhận được mã thông báo truy cập, bạn có thể sử dụng mã thông báo đó để thay mặt một tài khoản người dùng nhất định thực hiện lệnh gọi đến API của Google nếu(các) phạm vi truy cập mà API yêu cầu đã được cấp. Để thực hiện việc này, hãy đưa mã truy cập vào yêu cầu gửi đến API bằng cách thêm tham số truy vấn access_token hoặc giá trị Bearer của tiêu đề HTTP Authorization. Khi có thể, bạn nên sử dụng tiêu đề HTTP vì chuỗi truy vấn thường xuất hiện 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 để thiết lập các lệnh gọi đến API của Google (ví dụ: khi gọi API Tệp trên Drive).

Bạn có thể dùng thử tất cả API của Google và xem phạm vi của các API đó tại OAuth 2.0 Playground.

Ví dụ về HTTP GET

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

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

Dưới đâ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ụ về curl

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

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

Hoặc tuỳ 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ã truy cập

Mã thông báo truy cập định kỳ sẽ hết hạn và trở thành thông tin xác thực không hợp lệ cho một yêu cầu API có liên quan. Bạn có thể làm mới mã 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 liên kết với mã truy cập.

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

Trường
client_id	Mã ứng dụng khách lấy được từ .
client_secret	Khoá bí mật của ứng dụng khách lấy được từ .
grant_type	Như được xác định trong quy cách OAuth 2.0, bạn phải đặt giá trị của trường này thành refresh_token.
refresh_token	Mã làm mới được trả về từ quá trình trao đổi mã uỷ 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 cấp cho ứng dụng, máy chủ mã thông báo sẽ trả về một đối tượng JSON 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 https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

Xin lưu ý rằng có giới hạn về số lượng mã thông báo làm mới sẽ được phát hành; một giới hạn cho mỗi tổ hợp ứng dụ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ả ứng dụng. Bạn nên lưu mã thông báo làm mới trong bộ nhớ dài hạn và tiếp tục sử dụng miễn là mã thông báo đó vẫn hợp lệ. Nếu ứng dụng của bạn yêu cầu quá nhiều mã thông báo làm mới, thì ứng dụng đó có thể gặp phải các giới hạn này. Trong trường hợp đó, các mã thông báo làm mới cũ 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ấ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 vào phần Cài đặt tài khoản. Hãy xem phần Xoá quyền truy cập vào trang web hoặc ứng dụng trong tài liệu hỗ trợ về Các trang web và ứng dụng của bên thứ ba có quyền truy cập vào 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 cho ứng dụng theo phương thức có lập trình. Việc thu hồi theo phương thức lập trình rất quan trọng trong trường hợp người dùng huỷ đăng ký, xoá một ứ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 quy trình xoá có thể bao gồm yêu cầu API để đảm bảo các quyền đã cấp cho ứng dụng trước đó sẽ bị xoá.

Để thu hồi mã thông báo theo phương thức lập trình, ứng dụng của bạn sẽ gửi yêu cầu đến https://oauth2.googleapis.com/revoke và đưa mã thông báo vào làm 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ã thông báo làm mới. Nếu mã thông báo là mã truy cập và có mã làm mới tương ứng, thì mã làm mới cũng sẽ bị thu hồi.

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

Lưu ý: Sau khi bạn gửi phản hồi thu hồi thành công, có thể mất một khoảng thời gian thì việc thu hồi mới có hiệu lực đầy đủ.

Phạm vi được phép

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

OpenID Connect, Đăng nhập bằng Google

• email
• openid
• profile

Drive API

• 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

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ó.