OAuth 2.0 cho ứng dụng dành cho thiết bị di động và máy tính

Tài liệu này giải thích cách các ứng dụng được cài đặt trên các thiết bị như điện thoại, máy tính bảng và máy tính sử dụng các điểm cuối OAuth 2.0 của Google để uỷ quyền truy cập vào API Dữ liệu YouTube.

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 có thể sử dụng OAuth 2.0 để xin phép tải video lên kênh YouTube của người dùng.

Các ứng dụng đã cài đặt được phân phối cho từng thiết bị và giả định rằng các ứng dụng này 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.

Quy trình uỷ quyền này tương tự như quy trình được dùng cho ứng dụng máy chủ web. Điểm khác biệt chính là các ứng dụng đã cài đặt phải mở trình duyệt hệ thống và cung cấp URI chuyển hướng cục bộ để xử lý các phản hồi từ máy chủ uỷ quyền của Google.

Các phương án thay thế

Đối với ứng dụng di động, bạn nên sử dụng tính năng Đăng nhập bằng Google cho Android hoặc iOS. Thư viện ứng dụng Đăng nhập bằng Google xử lý việc xác thực và uỷ quyền người dùng, đồng thời có thể dễ triển khai hơn so với giao thức cấp thấp được mô tả ở đây.

Đối với các ứng dụng chạy trên các thiết bị không hỗ trợ trình duyệt hệ thống hoặc có chức năng đầu vào hạn chế, chẳng hạn như TV, máy chơi trò chơi, máy ảnh hoặc máy in, hãy xem phần OAuth 2.0 cho TV và thiết bị hoặc Đăng nhập trên TV và thiết bị đầu vào có giới hạn.

Thư viện và mẫu

Bạn nên sử dụng các thư viện và mẫu sau đây để triển khai luồng OAuth 2.0 được mô tả trong tài liệu này:

Đ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 .
  2. Sử dụng trang Thư viện để tìm và bật API dữ liệu YouTube. Tìm mọi API khác mà ứng dụng của bạn sẽ sử dụng và bật các API đó.

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

  1. Nhấp vào Tạo thông tin xác thực > Mã ứng dụng khách OAuth.
  2. Các phần sau đây mô tả các loại ứng dụng mà máy chủ uỷ quyền của Google hỗ trợ. Chọn loại ứng dụng khách được đề xuất cho ứng dụng của bạn, đặt tên cho ứng dụng khách OAuth và đặt các trường khác trong biểu mẫu sao cho phù hợp.
Android
  1. Chọn loại ứng dụng Android.
  2. Nhập tên cho ứng dụng OAuth. Tên này sẽ xuất hiện trên của dự án để xác định ứng dụng khách.
  3. Nhập tên gói của ứng dụng Android. Giá trị này được xác định trong thuộc tính package của phần tử <manifest> trong tệp kê khai ứng dụng.
  4. Nhập vân tay số của chứng chỉ ký SHA-1 cho bản phân phối ứng dụng.
    • Nếu ứng dụng của bạn sử dụng tính năng ký ứng dụng của Google Play, hãy sao chép vân tay số SHA-1 từ trang ký ứng dụng của Play Console.
    • Nếu bạn quản lý kho khoá và khoá ký của riêng mình, hãy sử dụng tiện ích keytool đi kèm với Java để in thông tin chứng chỉ ở định dạng mà con người có thể đọc được. Sao chép giá trị SHA1 trong phần Certificate fingerprints của đầu ra keytool. Hãy xem phần Xác thực ứng dụng trong tài liệu về API của Google cho Android để biết thêm thông tin.
  5. (Không bắt buộc) Xác minh quyền sở hữu ứng dụng Android.
  6. Nhấp vào Tạo.
iOS
  1. Chọn loại ứng dụng iOS.
  2. Nhập tên cho ứng dụng OAuth. Tên này sẽ xuất hiện trên của dự án để xác định ứng dụng khách.
  3. Nhập giá trị nhận dạng gói cho ứng dụng. Giá trị nhận dạng gói là giá trị của khoá CFBundleIdentifier trong tệp tài nguyên danh sách thuộc tính thông tin của ứng dụng (info.plist). Giá trị này thường hiển thị trong ngăn General (Chung) hoặc Signing & Capabilities (Ký và chức năng) của trình chỉnh sửa dự án Xcode. Mã gói cũng xuất hiện trong mục Thông tin chung của trang Thông tin ứng dụng cho ứng dụng trên trang web App Store Connect của Apple.

    Xác nhận rằng bạn đang sử dụng đúng mã gói cho ứng dụng của mình, vì bạn sẽ không thể thay đổi mã gói nếu đang sử dụng tính năng Kiểm tra ứng dụng.

  4. (Không bắt buộc)

    Nhập mã App Store của ứng dụng nếu ứng dụng được phát hành trong App Store của Apple. Mã cửa hàng là một chuỗi số có trong mọi URL của Apple App Store.

    1. Mở ứng dụng Apple App Store trên thiết bị iOS hoặc iPadOS.
    2. Tìm kiếm ứng dụng của bạn.
    3. Chọn nút Chia sẻ (biểu tượng hình vuông và mũi tên lên).
    4. Chọn Sao chép đường liên kết.
    5. Dán đường liên kết đó vào một trình chỉnh sửa văn bản. Mã App Store là phần cuối cùng của URL.

      Ví dụ: https://apps.apple.com/app/google/id284815942

  5. (Không bắt buộc)

    Nhập mã nhóm của bạn. Hãy xem phần Tìm mã nhận dạng nhóm trong tài liệu về Tài khoản nhà phát triển của Apple để biết thêm thông tin.

    Lưu ý: Bạn phải điền vào trường Mã nhóm nếu đang bật tính năng Kiểm tra ứng dụng cho khách hàng.
  6. (Không bắt buộc)

    Bật tính năng Kiểm tra ứng dụng cho ứng dụng iOS. Khi bạn bật tính năng Kiểm tra ứng dụng, dịch vụ Chứng thực ứng dụng của Apple sẽ được dùng để xác minh rằng các yêu cầu OAuth 2.0 bắt nguồn từ ứng dụng OAuth của bạn là chính xác và đến từ ứng dụng của bạn. Điều này giúp giảm nguy cơ mạo danh ứng dụng. Tìm hiểu thêm về cách bật tính năng Kiểm tra ứng dụng cho ứng dụng iOS.

  7. Nhấp vào Tạo.
UWP
  1. Chọn loại ứng dụng Universal Windows Platform (Nền tảng Windows thống nhất).
  2. Nhập tên cho ứng dụng OAuth. Tên này sẽ xuất hiện trên của dự án để xác định ứng dụng khách.
  3. Nhập mã cửa hàng gồm 12 ký tự của ứng dụng trên Microsoft Store. Bạn có thể tìm thấy giá trị này trong Trung tâm đối tác Microsoft trên trang App identity (Giá trị nhận dạng ứng dụng) trong phần Quản lý ứng dụng.
  4. Nhấp vào Tạo.

Đối với ứng dụng UWP, giao thức URI tuỳ chỉnh không được dài hơn 39 ký tự.

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.

YouTube Data API phiên bản 3 sử dụng các phạm vi sau:

Kính ngắm
https://www.googleapis.com/auth/youtubeQuản lý tài khoản YouTube của bạn
https://www.googleapis.com/auth/youtube.channel-memberships.creatorXem danh sách các hội viên đang hoạt động trên kênh của bạn, cấp độ hiện tại của họ và thời điểm họ trở thành hội viên
https://www.googleapis.com/auth/youtube.force-sslXem, chỉnh sửa và xóa vĩnh viễn các video, mức xếp hạng, ý kiến nhận xét và phụ đề của bạn trên YouTube
https://www.googleapis.com/auth/youtube.readonlyXem tài khoản YouTube của bạn
https://www.googleapis.com/auth/youtube.uploadQuản lý video trên YouTube của bạn
https://www.googleapis.com/auth/youtubepartnerXem và quản lý tài sản cũng như nội dung được kết hợp của bạn trên YouTube
https://www.googleapis.com/auth/youtubepartner-channel-auditXem thông tin riêng tư trên kênh YouTube của bạn có liên quan trong quá trình kiểm tra với đối tác YouTube

Tài liệu Phạm vi API OAuth 2.0 chứa danh sách đầy đủ các phạm vi mà bạn có thể sử dụng để truy cập vào các API của Google.

Lấy mã truy cập OAuth 2.0

Các bước sau đây cho thấy cách ứng dụng của bạn tương tác với máy chủ OAuth 2.0 của Google để lấy sự đồng ý của người dùng nhằm thay mặt người dùng thực hiện yêu cầu API. Ứng dụng của bạn phải có sự đồng ý đó thì mới có thể thực thi yêu cầu API của Google yêu cầu người dùng uỷ quyền.

Bước 1: Tạo trình xác minh mã và thử thách

Google hỗ trợ giao thức Khoá bằng chứng để trao đổi mã (PKCE) nhằm giúp quy trình cài đặt ứng dụng trở nên an toàn hơn. Một trình xác minh mã duy nhất được tạo cho mọi yêu cầu uỷ quyền và giá trị đã chuyển đổi của trình xác minh này, được gọi là "code_challenge", sẽ được gửi đến máy chủ uỷ quyền để lấy mã uỷ quyền.

Tạo trình xác minh mã

code_verifier là một chuỗi ngẫu nhiên mã hoá có độ hỗn loạn cao, sử dụng các ký tự chưa được đặt trước [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~", có độ dài tối thiểu là 43 ký tự và độ dài tối đa là 128 ký tự.

Trình xác minh mã phải có đủ độ hỗn loạn để không thể đoán được giá trị.

Tạo thử thách lập trình

Có hai phương thức tạo thử thách lập trình được hỗ trợ.

Phương thức tạo thử thách lập trình
S256 (nên dùng) Thử thách mã là hàm băm SHA256 được mã hoá Base64URL (không có khoảng đệm) của trình xác thực mã.
code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
plain Thử thách mã có cùng giá trị với trình xác minh mã được tạo ở trên.
code_challenge = code_verifier

Bước 2: Gửi yêu cầu đến máy chủ OAuth 2.0 của Google

Để được người dùng uỷ quyền, hãy gửi yêu cầu đến máy chủ uỷ quyền của Google tại https://accounts.google.com/o/oauth2/v2/auth. Điểm cuối này xử lý việc tra cứu phiên đang hoạt động, xác thực người dùng và lấy sự đồng ý của người dùng. Bạn chỉ có thể truy cập vào điểm cuối qua SSL và điểm cuối này sẽ từ chối các kết nối HTTP (không phải SSL).

Máy chủ uỷ quyền hỗ trợ các tham số chuỗi truy vấn sau đây cho các ứng dụng đã cài đặt:

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 .

redirect_uri Bắt buộc

Xác định cách máy chủ uỷ quyền của Google gửi phản hồi đến ứng dụng của bạn. Có một số tuỳ chọn chuyển hướng dành cho các ứng dụng đã cài đặt và bạn sẽ thiết lập thông tin xác thực uỷ quyền bằng một phương thức chuyển hướng cụ thể.

Giá trị này phải khớp chính xác với một trong các URI chuyển hướng được uỷ quyền cho ứng dụng OAuth 2.0 mà bạn đã định cấu hình trong của ứng dụng. Nếu giá trị này không khớp với URI được uỷ quyền, bạn sẽ gặp lỗi redirect_uri_mismatch.

Bảng dưới đây cho thấy giá trị tham số redirect_uri thích hợp cho từng phương thức:

Giá trị redirect_uri
Lược đồ URI tuỳ chỉnh com.example.app:redirect_uri_path

hoặc

com.googleusercontent.apps.123:redirect_uri_path
  • com.example.app là ký hiệu DNS ngược của một miền thuộc quyền kiểm soát của bạn. Lược đồ tuỳ chỉnh phải chứa dấu chấm để hợp lệ.
  • com.googleusercontent.apps.123 là ký hiệu DNS ngược của mã ứng dụng khách.
  • redirect_uri_path là một thành phần đường dẫn không bắt buộc, chẳng hạn như /oauth2redirect. Xin lưu ý rằng đường dẫn phải bắt đầu bằng một dấu gạch chéo, khác với URL HTTP thông thường.
Địa chỉ IP loopback http://127.0.0.1:port hoặc http://[::1]:port

Truy vấn nền tảng của bạn để biết địa chỉ IP loopback có liên quan và khởi động trình nghe HTTP trên một cổng ngẫu nhiên có sẵn. Thay thế port bằng số cổng thực tế mà ứng dụng của bạn nghe.

Xin lưu ý rằng tính năng hỗ trợ tuỳ chọn chuyển hướng địa chỉ IP vòng lặp trên ứng dụng di động đã ĐƯỢC NGHIÊN CỨU.

response_type Bắt buộc

Xác định xem điểm cuối OAuth 2.0 của Google có trả về mã uỷ quyền hay không.

Đặt giá trị tham số thành code cho các ứng dụng đã cài đặt.

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.

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.

YouTube Data API phiên bản 3 sử dụng các phạm vi sau:

Kính ngắm
https://www.googleapis.com/auth/youtubeQuản lý tài khoản YouTube của bạn
https://www.googleapis.com/auth/youtube.channel-memberships.creatorXem danh sách các hội viên đang hoạt động trên kênh của bạn, cấp độ hiện tại của họ và thời điểm họ trở thành hội viên
https://www.googleapis.com/auth/youtube.force-sslXem, chỉnh sửa và xóa vĩnh viễn các video, mức xếp hạng, ý kiến nhận xét và phụ đề của bạn trên YouTube
https://www.googleapis.com/auth/youtube.readonlyXem tài khoản YouTube của bạn
https://www.googleapis.com/auth/youtube.uploadQuản lý video trên YouTube của bạn
https://www.googleapis.com/auth/youtubepartnerXem và quản lý tài sản cũng như nội dung được kết hợp của bạn trên YouTube
https://www.googleapis.com/auth/youtubepartner-channel-auditXem thông tin riêng tư trên kênh YouTube của bạn có liên quan trong quá trình kiểm tra với đối tác YouTube

Tài liệu Phạm vi API OAuth 2.0 cung cấp danh sách đầy đủ các phạm vi mà bạn có thể sử dụng để truy cập vào các API của Google.

code_challenge Recommended (Nên dùng)

Chỉ định một code_verifier đã mã hoá sẽ được dùng làm thử thách phía máy chủ trong quá trình trao đổi mã uỷ quyền. Hãy xem phần thử thách tạo mã ở trên để biết thêm thông tin.

code_challenge_method Recommended (Nên dùng)

Chỉ định phương thức nào được dùng để mã hoá code_verifier sẽ được sử dụng trong quá trình trao đổi mã uỷ quyền. Bạn phải sử dụng thông số này với tham số code_challenge được mô tả ở trên. Giá trị của code_challenge_method mặc định là plain nếu không có trong yêu cầu chứa code_challenge. Giá trị duy nhất được hỗ trợ cho tham số này là S256 hoặc plain.

state Recommended (Nên dùng)

Chỉ định mọi giá trị chuỗi mà ứng dụng của bạn sử dụng để duy trì trạng thái giữa yêu cầu uỷ quyền và phản hồi của máy chủ uỷ quyền. Máy chủ trả về giá trị chính xác mà bạn gửi dưới dạng một cặp name=value trong giá trị nhận dạng mảnh URL (#) của redirect_uri sau khi người dùng đồng ý hoặc từ chối yêu cầu truy cập của ứng dụng.

Bạn có thể sử dụng thông số này cho một số mục đích, chẳng hạn như chuyển hướng người dùng đến tài nguyên chính xác trong ứng dụng, gửi số chỉ dùng một lần và giảm thiểu hành vi giả mạo yêu cầu trên nhiều trang web. Vì redirect_uri của bạn có thể bị đoán, nên việc sử dụng giá trị state có thể giúp bạn tăng độ tin cậy rằng một kết nối đến là kết quả của một yêu cầu xác thực. Nếu tạo một chuỗi ngẫu nhiên hoặc mã hoá hàm băm của một cookie hoặc một giá trị khác ghi lại trạng thái của ứng dụng, bạn có thể xác thực phản hồi để đảm bảo rằng yêu cầu và phản hồi bắt nguồn từ cùng một trình duyệt, giúp bảo vệ khỏi các cuộc tấn công như lừa đảo yêu cầu trên nhiều trang web. Hãy xem tài liệu về OpenID Connect để biết ví dụ về cách tạo và xác nhận mã thông báo state.

login_hint Không bắt buộc

Nếu biết người dùng nào đang cố gắng xác thực, ứng dụng của bạn có thể sử dụng thông số này để cung cấp gợi ý cho Máy chủ xác thực của Google. Máy chủ sử dụng gợi ý để đơn giản hoá quy trình đăng nhập bằng cách điền sẵn trường email trong biểu mẫu đăng nhập hoặc bằng cách chọn phiên đăng nhập nhiều người dùng thích hợp.

Đặt giá trị tham số thành địa chỉ email hoặc giá trị nhận dạng sub, tương đương với mã nhận dạng Google của người dùng.

URL uỷ quyền mẫu

Các thẻ bên dưới cho thấy URL uỷ quyền mẫu cho các tuỳ chọn URI chuyển hướng khác nhau.

Mỗi URL yêu cầu quyền truy cập vào một phạm vi cho phép truy cập để xem tài khoản YouTube của người dùng.

Các URL này giống hệt nhau ngoại trừ giá trị của tham số redirect_uri. Các URL này cũng chứa các tham số response_typeclient_id bắt buộc cũng như tham số state không bắt buộc. Mỗi URL chứa dấu ngắt dòng và dấu cách để dễ đọc.

Giao thức URI tuỳ chỉnh

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.readonly&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=com.example.app%3A/oauth2redirect&
 client_id=client_id

Địa chỉ IP loopback

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.readonly&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=http%3A//127.0.0.1%3A9004&
 client_id=client_id

Bước 3: Google nhắc người dùng đồng ý

Trong bước này, người dùng sẽ quyết định có cấp cho ứng dụng của bạn quyền truy cập đã yêu cầu hay không. Ở giai đoạn này, Google sẽ hiển thị một cửa sổ yêu cầu đồng ý cho biết tên ứng dụng và các dịch vụ API của Google mà ứng dụng đang yêu cầu quyền truy cập bằng thông tin xác thực uỷ quyền của người dùng, cũng như thông tin tóm tắt về phạm vi truy cập sẽ được cấp. Sau đó, người dùng có thể đồng ý cấp quyền truy cập vào một hoặc nhiều phạm vi mà ứng dụng của bạn yêu cầu hoặc từ chối yêu cầu.

Ứng dụng của bạn không cần làm gì ở giai đoạn này vì ứng dụng sẽ chờ phản hồi từ máy chủ OAuth 2.0 của Google cho biết liệu có cấp quyền truy cập nào hay không. Phản hồi đó được giải thích trong bước sau.

Lỗi

Các yêu cầu đến điểm cuối uỷ quyền OAuth 2.0 của Google có thể hiển thị thông báo lỗi mà người dùng nhìn thấy thay vì luồng xác thực và uỷ quyền dự kiến. Dưới đây là danh sách các mã lỗi thường gặp và giải pháp đề xuất.

admin_policy_enforced

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 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 việc những ứng dụng nội bộ và ứng dụng của bên thứ ba nào truy cập vào dữ liệu 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 tất cả phạm vi hoặc các phạm vi nhạy cảm và bị hạn chế cho đến khi quyền truy cập được cấp rõ ràng cho mã ứng dụng OAuth của bạn.

disallowed_useragent

Điểm cuối uỷ quyền hiển thị bên trong một tác nhân người dùng được nhúng mà Chính sách OAuth 2.0 của Google không cho phép.

Android

Nhà phát triển Android có thể gặp thông báo lỗi này khi mở các yêu cầu uỷ quyền trong android.webkit.WebView. Thay vào đó, nhà phát triển nên sử dụng các thư viện Android như Đăng nhập bằng Google cho Android hoặc AppAuth cho Android của OpenID Foundation.

Nhà phát triển web có thể gặp lỗi này khi một ứng dụng Android mở một đường liên kết web chung trong một tác nhân người dùng được nhúng và người dùng chuyển đến điểm cuối uỷ quyền OAuth 2.0 của Google từ trang web của bạn. Nhà phát triển nên cho phép các đường liên kết chung mở trong trình xử lý đường liên kết mặc định của hệ điều hành, bao gồm cả trình xử lý Đường liên kết trong ứng dụng Android hoặc ứng dụng trình duyệt mặc định. Thư viện Thẻ tuỳ chỉnh Android cũng là một tuỳ chọn được hỗ trợ.

iOS

Nhà phát triển iOS và macOS có thể gặp lỗi này khi mở yêu cầu uỷ quyền trong WKWebView. Thay vào đó, nhà phát triển nên sử dụng các thư viện iOS như Google Sign-In cho iOS hoặc AppAuth cho iOS của OpenID Foundation.

Nhà phát triển web có thể gặp lỗi này khi một ứng dụng iOS hoặc macOS mở một đường liên kết web chung trong một tác nhân người dùng được nhúng và người dùng chuyển đến điểm cuối uỷ quyền OAuth 2.0 của Google từ trang web của bạn. Nhà phát triển nên cho phép các đường liên kết chung mở trong trình xử lý đường liên kết mặc định của hệ điều hành, bao gồm cả trình xử lý Đường liên kết chung hoặc ứng dụng trình duyệt mặc định. Thư viện SFSafariViewController cũng là một tuỳ chọn được hỗ trợ.

org_internal

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ể. Để biết thêm thông tin về tuỳ chọn cấu hình này, hãy xem phần Loại người dùng trong bài viết trợ giúp về cách thiết lập màn hình xin phép bằng OAuth.

invalid_grant

Nếu bạn đang sử dụng trình xác minh mã và thử thách, tham số code_callenge sẽ không hợp lệ hoặc bị thiếu. Đảm bảo rằng bạn đã thiết lập đúng thông số code_challenge.

Khi làm mới mã thông báo truy cập, mã thông báo có thể đã hết hạn hoặc không hợp lệ. Xác thực lại người dùng và yêu cầu người dùng đồng ý để lấy mã thông báo mới. Nếu bạn vẫn gặp lỗi này, hãy đảm bảo rằng ứng dụng của bạn đã được định cấu hình chính xác và bạn đang sử dụng đúng mã thông báo và tham số trong yêu cầu. Nếu không, tài khoản người dùng có thể đã bị xoá hoặc bị vô hiệu hoá.

redirect_uri_mismatch

redirect_uri được truyền trong yêu cầu uỷ quyền không khớp với URI chuyển hướng được uỷ quyền cho mã ứng dụng OAuth. Xem xét các URI chuyển hướng được uỷ quyền trong .

redirect_uri đã truyền có thể không hợp lệ cho loại ứng dụng khách.

Tham số redirect_uri có thể tham chiếu đến luồng OAuth ngoài băng thông (OOB) đã ngừng hoạt động và không còn được hỗ trợ nữa. Hãy tham khảo hướng dẫn di chuyển để cập nhật tính năng tích hợp.

invalid_request

Yêu cầu mà bạn đưa ra có vấn đề. Điều này có thể là do một số lý do sau:

  • Yêu cầu không được định dạng đúng cách
  • Yêu cầu thiếu các tham số bắt buộc
  • Yêu cầu sử dụng một phương thức uỷ quyền mà Google không hỗ trợ. Xác minh việc tích hợp OAuth của bạn sử dụng phương thức tích hợp được đề xuất
  • Một giao thức tuỳ chỉnh được dùng cho uri chuyển hướng : Nếu bạn thấy thông báo lỗi Giao thức URI tuỳ chỉnh không được hỗ trợ trên các ứng dụng Chrome hoặc Giao thức URI tuỳ chỉnh không được bật cho ứng dụng Android, thì tức là bạn đang sử dụng một giao thức URI tuỳ chỉnh không được hỗ trợ trên các ứng dụng Chrome và bị tắt theo mặc định trên Android. Tìm hiểu thêm về các phương án thay thế lược đồ URI tuỳ chỉnh

Bước 4: Xử lý phản hồi của máy chủ OAuth 2.0

Cách ứng dụng của bạn nhận được phản hồi uỷ quyền phụ thuộc vào lược đồ URI chuyển hướng mà ứng dụng sử dụng. Bất kể lược đồ nào, phản hồi sẽ chứa mã uỷ quyền (code) hoặc lỗi (error). Ví dụ: error=access_denied cho biết người dùng đã từ chối yêu cầu.

Nếu người dùng cấp quyền truy cập vào ứng dụng của bạn, bạn có thể đổi mã uỷ quyền lấy mã truy cập và mã làm mới như mô tả trong bước tiếp theo.

Bước 5: Trao đổi mã uỷ quyền để làm mới và truy cập vào mã thông báo

Để trao đổi mã uỷ quyền lấy mã truy cập, hãy gọi điểm cuối https://oauth2.googleapis.com/token và đặt các thông 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 từ .
code Mã uỷ quyền được trả về từ yêu cầu ban đầu.
code_verifier Trình xác minh mã mà bạn đã tạo ở Bước 1.
grant_type Như đã 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 authorization_code.
redirect_uri Một trong các URI chuyển hướng được liệt kê cho dự án của bạn trong cho client_id đã cho.

Đ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

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your_client_id&
client_secret=your_client_secret&
redirect_uri=http://127.0.0.1:9004&
grant_type=authorization_code

Google phản hồi yêu cầu này bằng cách trả về một đối tượng JSON chứa mã truy cập ngắn hạn và mã làm mới.

Phản hồi 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.
id_token Lưu ý: Thuộc tính này chỉ được trả về nếu yêu cầu của bạn bao gồm một phạm vi nhận dạng, chẳng hạn như openid, profile hoặc email. Giá trị này là một Mã thông báo web JSON (JWT) chứa thông tin nhận dạng được ký bằng phương thức kỹ thuật số về người dùng.
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 các ứng dụng đã cài đặt.
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,
  "token_type": "Bearer",
  "scope": "https://www.googleapis.com/auth/youtube.force-ssl",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

Bước 6: Kiểm tra xem người dùng đã cấp những phạm vi nào

Khi bạn yêu cầu nhiều phạm vi cùng một lúc, người dùng có thể không cấp tất cả phạm vi mà ứng dụng của bạn yêu cầu. Ứng dụng của bạn phải luôn kiểm tra xem người dùng đã cấp những phạm vi nào và xử lý mọi trường hợp từ chối cấp phạm vi bằng cách tắt các tính năng có liên quan. Hãy xem bài viết Cách xử lý các quyền chi tiết để biết thêm thông tin.

Để kiểm tra xem người dùng đã cấp cho ứng dụng quyền truy cập vào một phạm vi cụ thể hay chưa, hãy kiểm tra trường scope trong phản hồi mã thông báo truy cập. 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.

Ví dụ: phản hồi mã thông báo truy cập mẫu sau đây cho biết rằng người dùng đã cấp cho ứng dụng của bạn quyền xem, chỉnh sửa và xoá vĩnh viễn các video, mức xếp hạng, bình luận và phụ đề của người dùng trên YouTube:

  {
    "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
    "expires_in": 3920,
    "token_type": "Bearer",
    "scope": "https://www.googleapis.com/auth/youtube.force-ssl",
    "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
  }

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 Dữ liệu YouTube).

Xin lưu ý rằng YouTube Data API chỉ hỗ trợ tài khoản dịch vụ cho những chủ sở hữu nội dung trên YouTube sở hữu và quản lý nhiều kênh YouTube, chẳng hạn như hãng thu âm và hãng phim.

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 youtube.channels (API Dữ liệu YouTube) 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 /youtube/v3/channels?part=snippet&mine=true 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/youtube/v3/channels?access_token=access_token&part=snippet&mine=true

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/youtube/v3/channels?part=snippet&mine=true

Hoặc tuỳ chọn tham số chuỗi truy vấn:

curl https://www.googleapis.com/youtube/v3/channels?access_token=access_token&part=snippet&mine=true

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ừ . (client_secret không áp dụng cho các yêu cầu của ứng dụng khách được đăng ký dưới dạng ứng dụng Android, iOS hoặc Chrome.)
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",
  "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.

Phương thức chuyển hướng ứng dụng

Lược đồ URI tuỳ chỉnh (Android, iOS, UWP)

Lược đồ URI tuỳ chỉnh là một dạng đường liên kết sâu sử dụng lược đồ do bạn xác định để mở ứng dụng.

Giải pháp thay thế cho việc sử dụng lược đồ URI tuỳ chỉnh trên Android

Sử dụng SDK Đăng nhập bằng Google cho Android để phân phối phản hồi OAuth 2.0 trực tiếp đến ứng dụng của bạn, nhờ đó không cần URI chuyển hướng.

Cách di chuyển sang SDK Đăng nhập bằng Google cho Android

Nếu sử dụng lược đồ tuỳ chỉnh để tích hợp OAuth trên Android, bạn cần hoàn tất các thao tác sau để di chuyển hoàn toàn sang sử dụng SDK Đăng nhập bằng Google được đề xuất cho Android:

  1. Cập nhật mã để sử dụng SDK Đăng nhập bằng Google.
  2. Tắt tính năng hỗ trợ giao thức tuỳ chỉnh trong Google API Console.

Hãy làm theo các bước bên dưới để di chuyển sang SDK Đăng nhập bằng Google dành cho Android:

  1. Cập nhật mã để sử dụng SDK Đăng nhập bằng Google dành cho Android:
    1. Kiểm tra mã của bạn để xác định vị trí bạn đang gửi yêu cầu đến máy chủ OAuth 2.0 của Google; nếu sử dụng giao thức tuỳ chỉnh, yêu cầu của bạn sẽ có dạng như sau:
        https://accounts.google.com/o/oauth2/v2/auth?
        scope=<SCOPES>&
        response_type=code&
        &state=<STATE>&
        redirect_uri=com.example.app:/oauth2redirect&
        client_id=<CLIENT_ID>
        
      com.example.app:/oauth2redirect là URI chuyển hướng theo lược đồ tuỳ chỉnh trong ví dụ trên. Xem định nghĩa tham số redirect_uri để biết thêm thông tin chi tiết về định dạng của giá trị giao thức URI tuỳ chỉnh.
    2. Ghi lại các thông số yêu cầu scopeclient_id mà bạn cần để định cấu hình SDK Đăng nhập bằng Google.
    3. Làm theo hướng dẫn Bắt đầu tích hợp tính năng Đăng nhập bằng Google vào ứng dụng Android để thiết lập SDK. Bạn có thể bỏ qua bước Lấy mã ứng dụng khách OAuth 2.0 của máy chủ phụ trợ vì bạn sẽ sử dụng lại client_id đã truy xuất từ bước trước.
    4. Làm theo hướng dẫn Bật quyền truy cập API phía máy chủ. Điều này bao gồm các bước sau:
      1. Sử dụng phương thức getServerAuthCode để truy xuất mã xác thực cho các phạm vi mà bạn đang yêu cầu quyền.
      2. Gửi mã xác thực đến phần phụ trợ của ứng dụng để trao đổi mã đó lấy mã truy cập và làm mới.
      3. Sử dụng mã thông báo truy cập đã truy xuất để thay mặt người dùng thực hiện lệnh gọi đến các API của Google.
  2. Tắt tính năng hỗ trợ giao thức tuỳ chỉnh trong Google API Console:
    1. Chuyển đến danh sách Thông tin xác thực OAuth 2.0 rồi chọn ứng dụng Android.
    2. Chuyển đến phần Cài đặt nâng cao, bỏ đánh dấu hộp đánh dấu Bật lược đồ URI tuỳ chỉnh rồi nhấp vào Lưu để tắt tính năng hỗ trợ lược đồ URI tuỳ chỉnh.

Bật lược đồ URI tuỳ chỉnh

Nếu giải pháp thay thế được đề xuất không phù hợp với bạn, bạn có thể bật lược đồ URI tuỳ chỉnh cho ứng dụng Android bằng cách làm theo hướng dẫn bên dưới:
  1. Chuyển đến danh sách Thông tin xác thực OAuth 2.0 rồi chọn ứng dụng Android.
  2. Chuyển đến phần Cài đặt nâng cao, đánh dấu vào hộp đánh dấu Bật giản đồ URI tuỳ chỉnh rồi nhấp vào Lưu để bật tính năng hỗ trợ giản đồ URI tuỳ chỉnh.

Giải pháp thay thế cho việc sử dụng lược đồ URI tuỳ chỉnh trên các ứng dụng Chrome

Sử dụng API nhận dạng của Chrome để phân phối phản hồi OAuth 2.0 trực tiếp đến ứng dụng của bạn, nhờ đó không cần URI chuyển hướng.

Địa chỉ IP loopback (macOS, Linux, máy tính để bàn Windows)

Để nhận mã uỷ quyền bằng URL này, ứng dụng của bạn phải đang nghe trên máy chủ web cục bộ. Bạn có thể làm việc này trên nhiều nền tảng, nhưng không phải tất cả. Tuy nhiên, nếu nền tảng của bạn hỗ trợ tính năng này, thì đây là cơ chế được đề xuất để lấy mã uỷ quyền.

Khi ứng dụng của bạn nhận được phản hồi uỷ quyền, để có khả năng hữu dụng tốt nhất, ứng dụng đó phải phản hồi bằng cách hiển thị một trang HTML hướng dẫn người dùng đóng trình duyệt và quay lại ứng dụng.

Cách sử dụng đề xuất Ứng dụng dành cho máy tính macOS, Linux và Windows (nhưng không phải ứng dụng dành cho Universal Windows Platform)
Giá trị biểu mẫu Đặt loại ứng dụng thành Ứng dụng dành cho máy tính.

Sao chép/dán theo cách thủ công (Không dùng nữa)

Bảo vệ ứng dụng

Xác minh quyền sở hữu ứng dụng (Android, Chrome)

Bạn có thể xác minh quyền sở hữu ứng dụng để giảm nguy cơ bị mạo danh ứng dụng.

Android

Để hoàn tất quy trình xác minh, bạn có thể sử dụng Tài khoản nhà phát triển Google Play nếu có và ứng dụng của bạn đã được đăng ký trên Google Play Console. Bạn phải đáp ứng các yêu cầu sau đây để xác minh thành công:

  • Bạn phải có một ứng dụng đã đăng ký trong Google Play Console có cùng tên gói và vân tay số của chứng chỉ ký SHA-1 với ứng dụng khách OAuth Android mà bạn đang hoàn tất quy trình xác minh.
  • Bạn phải có quyền Quản trị đối với ứng dụng trong Google Play Console. Tìm hiểu thêm về cách quản lý quyền truy cập trong Google Play Console.

Trong mục Xác minh quyền sở hữu ứng dụng của ứng dụng Android, hãy nhấp vào nút Xác minh quyền sở hữu để hoàn tất quy trình xác minh.

Nếu xác minh thành công, một thông báo sẽ xuất hiện để xác nhận quá trình xác minh đã thành công. Nếu không, một lời nhắc lỗi sẽ xuất hiện.

Để khắc phục trường hợp xác minh không thành công, hãy thử các cách sau:

  • Đảm bảo rằng ứng dụng bạn đang xác minh là ứng dụng đã đăng ký trong Google Play Console.
  • Đảm bảo bạn có quyền Quản trị đối với ứng dụng trong Google Play Console.
Chrome

Để hoàn tất quy trình xác minh, bạn sẽ sử dụng tài khoản Nhà phát triển trên Cửa hàng Chrome trực tuyến. Bạn phải đáp ứng các yêu cầu sau để xác minh thành công:

  • Bạn phải có một mặt hàng đã đăng ký trong Trang tổng quan dành cho nhà phát triển Cửa hàng Chrome trực tuyến có cùng mã mặt hàng với ứng dụng OAuth của tiện ích Chrome mà bạn đang hoàn tất quy trình xác minh.
  • Bạn phải là nhà xuất bản của mặt hàng trên Cửa hàng Chrome trực tuyến. Tìm hiểu thêm về cách quản lý quyền truy cập trong Trang tổng quan dành cho nhà phát triển Cửa hàng Chrome trực tuyến.

Trong mục Xác minh quyền sở hữu ứng dụng của ứng dụng Tiện ích Chrome, hãy nhấp vào nút Xác minh quyền sở hữu để hoàn tất quy trình xác minh.

Lưu ý: Hãy đợi vài phút trước khi hoàn tất quy trình xác minh sau khi cấp quyền truy cập vào tài khoản của bạn.

Nếu xác minh thành công, một thông báo sẽ xuất hiện để xác nhận quá trình xác minh đã thành công. Nếu không, một lời nhắc lỗi sẽ xuất hiện.

Để khắc phục trường hợp xác minh không thành công, hãy thử các cách sau:

  • Đảm bảo có một mặt hàng đã đăng ký trong Trang tổng quan dành cho nhà phát triển Cửa hàng Chrome trực tuyến có cùng mã mặt hàng với ứng dụng OAuth của tiện ích Chrome mà bạn đang hoàn tất quy trình xác minh.
  • Đảm bảo bạn là nhà xuất bản của ứng dụng, tức là bạn phải là nhà xuất bản cá nhân của ứng dụng hoặc là thành viên của nhà xuất bản nhóm của ứng dụng. Tìm hiểu thêm về cách quản lý quyền truy cập trong Trang tổng quan dành cho nhà phát triển của Cửa hàng Chrome trực tuyến.
  • Nếu bạn vừa cập nhật danh sách nhà xuất bản nhóm, hãy xác minh rằng danh sách thành viên nhà xuất bản nhóm đã được đồng bộ hoá trong Trang tổng quan dành cho nhà phát triển Cửa hàng Chrome trực tuyến. Tìm hiểu thêm về cách đồng bộ hoá danh sách gói thành viên của nhà xuất bản.

Kiểm tra ứng dụng (chỉ dành cho iOS)

Tính năng Kiểm tra ứng dụng giúp bảo vệ ứng dụng iOS của bạn khỏi bị sử dụng trái phép bằng cách sử dụng dịch vụ Chứng thực ứng dụng của Apple để xác minh rằng các yêu cầu được gửi đến điểm cuối OAuth 2.0 của Google bắt nguồn từ các ứng dụng chính thống của bạn. Điều này giúp giảm nguy cơ mạo danh ứng dụng.

Bật tính năng Kiểm tra ứng dụng cho ứng dụng iOS

Bạn phải đáp ứng các yêu cầu sau để bật thành công tính năng Kiểm tra ứng dụng cho ứng dụng iOS:
  • Bạn phải chỉ định mã nhận dạng nhóm cho ứng dụng iOS.
  • Bạn không được sử dụng ký tự đại diện trong mã gói vì mã này có thể phân giải đến nhiều ứng dụng. Điều này có nghĩa là mã gói không được chứa ký hiệu dấu hoa thị (*).
Để bật tính năng Kiểm tra ứng dụng, hãy bật nút bật/tắt Bảo vệ ứng dụng OAuth của bạn khỏi hành vi sử dụng sai trái bằng tính năng Kiểm tra ứng dụng Firebase trong chế độ xem chỉnh sửa của ứng dụng iOS.

Sau khi bật tính năng Kiểm tra ứng dụng, bạn sẽ bắt đầu thấy các chỉ số liên quan đến các yêu cầu OAuth từ ứng dụng trong chế độ xem chỉnh sửa của ứng dụng OAuth. Các yêu cầu từ các nguồn chưa được xác minh sẽ không bị chặn cho đến khi bạn thực thi tính năng Kiểm tra ứng dụng. Thông tin trong trang giám sát chỉ số có thể giúp bạn xác định thời điểm bắt đầu thực thi.

Bạn có thể thấy các lỗi liên quan đến tính năng Kiểm tra ứng dụng khi bật tính năng Kiểm tra ứng dụng cho ứng dụng iOS. Để khắc phục những lỗi này, hãy thử làm như sau:

  • Xác minh rằng mã nhận dạng gói và mã nhận dạng nhóm mà bạn chỉ định là hợp lệ.
  • Kiểm tra để đảm bảo bạn không sử dụng ký tự đại diện cho mã gói.

Thực thi tính năng Kiểm tra ứng dụng cho ứng dụng iOS

Việc bật tính năng Kiểm tra ứng dụng cho ứng dụng của bạn không tự động chặn các yêu cầu không được nhận dạng. Để thực thi biện pháp bảo vệ này, hãy chuyển đến chế độ xem chỉnh sửa của ứng dụng iOS. Tại đó, bạn sẽ thấy các chỉ số của App Check ở bên phải trang trong phần Google Identity for iOS (Danh tính của Google cho iOS). Các chỉ số này bao gồm những thông tin sau:
  • Số lượng yêu cầu đã xác minh – những yêu cầu có mã thông báo App Check hợp lệ. Sau khi bạn bật tính năng thực thi App Check, chỉ những yêu cầu thuộc danh mục này mới thành công.
  • Số lượng yêu cầu chưa xác minh: có thể là các yêu cầu của ứng dụng đã lỗi thời – các yêu cầu thiếu mã thông báo App Check; các yêu cầu này có thể là từ một phiên bản cũ của ứng dụng không bao gồm việc triển khai App Check.
  • Số yêu cầu chưa xác minh: yêu cầu có nguồn gốc không xác định – các yêu cầu thiếu mã thông báo của tính năng Kiểm tra ứng dụng và có vẻ như không đến từ ứng dụng của bạn.
  • Số yêu cầu chưa được xác minh: yêu cầu không hợp lệ – yêu cầu có mã thông báo App Check không hợp lệ, có thể là từ một ứng dụng không xác thực đang cố mạo danh ứng dụng của bạn hoặc từ môi trường được mô phỏng.
Hãy xem xét các chỉ số này để hiểu mức độ ảnh hưởng của việc thực thi tính năng Kiểm tra ứng dụng đối với người dùng.

Để thực thi tính năng Kiểm tra ứng dụng, hãy nhấp vào nút ENFORCE rồi xác nhận lựa chọn của bạn. Sau khi biện pháp thực thi có hiệu lực, tất cả yêu cầu chưa được xác minh của khách hàng sẽ bị từ chối.

Lưu ý: Sau khi bạn bật tính năng thực thi, có thể mất tới 15 phút thì các thay đổi mới có hiệu lực.

Không thực thi tính năng Kiểm tra ứng dụng cho ứng dụng iOS

Việc không thực thi tính năng Kiểm tra ứng dụng cho ứng dụng của bạn sẽ dừng tính năng thực thi và cho phép tất cả yêu cầu từ ứng dụng của bạn đến các điểm cuối OAuth 2.0 của Google, bao gồm cả các yêu cầu chưa được xác minh.

Để huỷ thực thi tính năng Kiểm tra ứng dụng cho ứng dụng iOS, hãy chuyển đến chế độ xem chỉnh sửa của ứng dụng iOS rồi nhấp vào nút HUỶ THỰC THI và xác nhận lựa chọn của bạn.

Lưu ý: sau khi bạn huỷ thực thi tính năng Kiểm tra ứng dụng, có thể mất tới 15 phút thì các thay đổi mới có hiệu lực.

Tắt tính năng Kiểm tra ứng dụng cho ứng dụng iOS

Việc tắt tính năng Kiểm tra ứng dụng cho ứng dụng của bạn sẽ dừng mọi hoạt động giám sát và thực thi của tính năng Kiểm tra ứng dụng. Thay vào đó, hãy cân nhắc việc ngừng thực thi tính năng Kiểm tra ứng dụng để bạn có thể tiếp tục theo dõi các chỉ số cho ứng dụng của khách hàng.

Để tắt tính năng Kiểm tra ứng dụng cho ứng dụng iOS, hãy chuyển đến chế độ xem chỉnh sửa của ứng dụng iOS rồi tắt nút bật/tắt Bảo vệ ứng dụng OAuth của bạn khỏi hành vi sử dụng sai trái bằng tính năng Kiểm tra ứng dụng Firebase.

Lưu ý: sau khi tắt tính năng Kiểm tra ứng dụng, có thể mất tới 15 phút thì các thay đổi mới có hiệu lực.

Tài liệu đọc thêm

Phương pháp hay nhất hiện tại của IETF OAuth 2.0 cho ứng dụng gốc thiết lập nhiều phương pháp hay nhất được ghi nhận tại đây.

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