Akun ditautkan menggunakan alur implisit dan kode otorisasi OAuth 2.0 standar industri. Layanan Anda harus mendukung endpoint otorisasi dan pertukaran token yang mematuhi OAuth 2.0.
Dalam alur implisit, Google akan membuka endpoint otorisasi Anda di browser pengguna. Setelah berhasil login, Anda akan menampilkan token akses dengan masa berlaku lama ke Google. Token akses ini kini disertakan dalam setiap permintaan yang dikirim dari Google.
Dalam alur kode otorisasi, Anda memerlukan dua endpoint:
Endpoint Authorization, yang menampilkan UI login kepada pengguna Anda yang belum login. Endpoint otorisasi juga membuat kode otorisasi berumur pendek untuk mencatat izin pengguna ke akses yang diminta.
Endpoint pertukaran token, yang bertanggung jawab atas dua jenis pertukaran:
- Menukar kode otorisasi dengan token refresh yang berumur panjang dan token akses yang berumur singkat. Pertukaran ini terjadi saat pengguna melalui alur penautan akun.
- Menukar token refresh yang memiliki masa aktif lama dengan token akses yang memiliki masa aktif singkat. Pertukaran ini terjadi saat Google memerlukan token akses baru karena token yang ada sudah tidak berlaku lagi.
Pilih alur OAuth 2.0
Meskipun alur implisit lebih mudah diterapkan, Google merekomendasikan agar token akses yang dikeluarkan oleh alur implisit tidak pernah berakhir masa berlakunya. Hal ini karena pengguna dipaksa untuk menautkan akunnya lagi setelah token berakhir masa berlakunya dengan alur implisit. Jika Anda memerlukan masa berlaku token karena alasan keamanan, sebaiknya gunakan alur kode otorisasi.
Panduan desain
Bagian ini menjelaskan persyaratan dan rekomendasi desain untuk layar pengguna yang Anda host untuk alur penautan OAuth. Setelah dipanggil oleh aplikasi Google, platform Anda akan menampilkan halaman login ke Google dan layar izin penautan akun ke pengguna. Pengguna akan diarahkan kembali ke aplikasi Google setelah memberikan izin untuk menautkan akun.
Persyaratan
- Anda harus menyampaikan bahwa akun pengguna akan ditautkan ke Google, bukan produk Google tertentu seperti Google Home atau Asisten Google.
Rekomendasi
Sebaiknya Anda melakukan hal berikut:
Menampilkan Kebijakan Privasi Google. Sertakan link ke Kebijakan Privasi Google di layar izin.
Data yang akan dibagikan. Gunakan bahasa yang jelas dan ringkas untuk memberi tahu pengguna data apa saja yang diperlukan Google dan alasannya.
Pesan ajakan (CTA) yang jelas. Nyatakan pesan ajakan yang jelas di layar izin, seperti “Setuju dan tautkan”. Hal ini karena pengguna perlu memahami data apa yang harus mereka bagikan kepada Google untuk menautkan akun mereka.
Kemampuan untuk membatalkan. Berikan cara bagi pengguna untuk kembali atau membatalkan, jika mereka memilih untuk tidak menautkan.
Proses login yang jelas. Pastikan pengguna memiliki metode yang jelas untuk login ke Akun Google mereka, seperti kolom untuk nama pengguna dan sandi mereka atau Login dengan Google.
Kemampuan untuk membatalkan tautan. Tawarkan mekanisme bagi pengguna untuk membatalkan tautan, seperti URL ke setelan akun mereka di platform Anda. Atau, Anda dapat menyertakan link ke Akun Google tempat pengguna dapat mengelola akun tertaut mereka.
Kemampuan untuk mengubah akun pengguna. Sarankan metode bagi pengguna untuk beralih akun. Hal ini sangat bermanfaat jika pengguna cenderung memiliki beberapa akun.
- Jika pengguna harus menutup layar izin untuk beralih akun, kirim error yang dapat dipulihkan ke Google sehingga pengguna dapat login ke akun yang diinginkan dengan penautan OAuth dan alur implisit.
Sertakan logo Anda. Menampilkan logo perusahaan Anda di layar izin. Gunakan panduan gaya untuk menempatkan logo. Jika Anda juga ingin menampilkan logo Google, lihat Logo dan merek dagang.
Membuat project
Untuk membuat project Anda agar dapat menggunakan penautan akun:
- Klik Buat proyek.
- Masukkan nama atau terima saran yang dibuat.
- Konfirmasi atau edit kolom yang tersisa.
- Klik Buat.
Untuk melihat project ID Anda:
- Cari project Anda di tabel pada halaman landing. Project ID muncul di kolom ID.
Mengonfigurasi Layar Izin OAuth Anda
Proses Penautan Akun Google mencakup layar izin yang memberi tahu pengguna aplikasi yang meminta akses ke data mereka, jenis data yang diminta, dan persyaratan yang berlaku. Anda harus mengonfigurasi layar izin OAuth sebelum membuat ID klien Google API.
- Buka halaman Layar izin OAuth di konsol API Google.
- Jika diminta, pilih project yang baru saja Anda buat.
Di halaman "Layar izin OAuth", isi formulir, lalu klik tombol “Simpan”.
Nama aplikasi: Nama aplikasi yang meminta izin. Nama harus mencerminkan aplikasi Anda secara akurat dan konsisten dengan nama aplikasi yang dilihat pengguna di tempat lain. Nama aplikasi akan ditampilkan di layar izin Penautan Akun.
Logo aplikasi: Gambar di layar izin yang akan membantu pengguna mengenali aplikasi Anda. Logo ditampilkan di layar izin Penautan akun dan di setelan akun
Email dukungan: Agar pengguna dapat menghubungi Anda untuk mengajukan pertanyaan tentang izin mereka.
Cakupan untuk Google API: Cakupan memungkinkan aplikasi Anda mengakses data Google pribadi pengguna Anda. Untuk kasus penggunaan Penautan Akun Google, cakupan default (email, profil, openid) sudah cukup, Anda tidak perlu menambahkan cakupan sensitif. Secara umum, praktik terbaiknya adalah meminta cakupan secara bertahap, pada saat akses diperlukan, bukan di awal. Pelajari lebih lanjut.
Domain yang diizinkan: Guna melindungi Anda dan pengguna Anda, Google hanya mengizinkan aplikasi yang melakukan autentikasi menggunakan OAuth untuk menggunakan Domain yang Diizinkan. Link aplikasi Anda harus dihosting di Domain yang Diotorisasi. Pelajari lebih lanjut.
Link Halaman Beranda Aplikasi: Halaman beranda untuk aplikasi Anda. Harus dihosting di Domain yang Diotorisasi.
Link Kebijakan Privasi Aplikasi: Ditampilkan di layar izin Penautan Akun Google. Harus dihosting di Domain yang Diotorisasi.
Link Persyaratan Layanan Aplikasi (Opsional): Harus dihosting di Domain yang Diotorisasi.
Gambar 1. Layar Izin Penautan Akun Google untuk Aplikasi fiktif, Tunery
Periksa "Status Verifikasi", jika aplikasi Anda memerlukan verifikasi, klik tombol "Kirim untuk Verifikasi" untuk mengirimkan aplikasi Anda untuk diverifikasi. Lihat persyaratan verifikasi OAuth untuk mengetahui detailnya.
Menerapkan server OAuth
授权代码流程的 OAuth 2.0 服务器实现包括 两个端点,您的服务会通过 HTTPS 提供这两个端点。第一个端点 是授权端点,负责查找或获取 就数据访问征求用户意见。授权端点会提供一个 尚未登录的用户的登录界面,并记录同意情况 请求的访问权限。第二个端点是令牌交换端点, 用于获取加密字符串(称为令牌),以授权用户 访问您的服务。
当 Google 应用需要调用您的某个服务的 API 时,Google 会使用 将这些端点组合在一起,以获取用户调用这些 API 的权限 。
由 Google 发起的 OAuth 2.0 授权代码流程会话包含 以下流程:
- Google 会在用户的浏览器中打开您的授权端点。如果流 在用户通过纯语音设备上针对某个 Action 启动,Google 会将 将代码执行到手机上
- 用户登录(如果尚未登录),并授予 Google 以下权限: 访问您的 API 访问其数据(如果尚未授权)。
- 您的服务会创建授权代码并将其返回给 Google。待办事项 因此,请使用授权代码将用户的浏览器重定向回 Google。 附件。
- Google 会将授权代码发送到您的令牌交换端点, 验证代码的真实性并返回访问令牌和 刷新令牌。访问令牌是一个短期有效的令牌 作为访问 API 的凭据。刷新令牌长期有效 Google 可以存储该令牌,以便在用户首次访问该令牌时, 过期。
- 在用户完成账号关联流程后, 从 Google 发送的请求中包含访问令牌。
处理授权请求
需要使用 OAuth 2.0 授权代码执行账号关联的情况 流程中,Google 会通过请求将用户发送到您的授权端点 包含以下参数:
| 授权端点参数 | |
|---|---|
client_id |
您分配给 Google 的客户 ID。 |
redirect_uri |
此请求的响应发送到的网址。 |
state |
将一个在 重定向 URI。 |
scope |
可选:一组以空格分隔的范围字符串,用于指定 Google 请求授权的数据 |
response_type |
要在响应中返回的值的类型。对于 OAuth 2.0
授权代码流程中,响应类型始终为 code。
|
user_locale |
“Google 账号语言设置” RFC5646 格式,用于将您的内容本地化为用户首选语言。 |
例如,如果您的授权端点位于
https://myservice.example.com/auth 时,请求可能如下所示:
GET https://myservice.example.com/auth?client_id=GOOGLE_CLIENT_ID&redirect_uri=REDIRECT_URI&state=STATE_STRING&scope=REQUESTED_SCOPES&response_type=code&user_locale=LOCALE
为了让授权端点能够处理登录请求,请执行以下操作 步骤:
- 验证
client_id是否与您分配给 Google 的 Client ID 匹配,以及redirect_uri与 Google 为您的服务提供的重定向网址是否匹配。这些检查对于防止 访问意外或配置错误的客户端应用。如果你支持多种 OAuth 2.0 流程,还应确认response_type是否为code。 - 检查用户是否已登录您的服务。如果用户没有登录, 完成服务的登录或注册流程。
- 生成授权代码,以供 Google 用于访问您的 API。 授权代码可以是任何字符串值,但它必须是唯一的 代表用户、令牌对应的客户端以及代码的有效期 而且不可猜测出来。您通常需要进行授权 会在大约 10 分钟后过期。
- 确认
redirect_uri参数指定的网址包含 以下表单:https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
- 将用户的浏览器重定向到
redirect_uri参数。添加您在 以及您在重定向时返回未经修改的原始状态值 方法是附加code和state参数。以下是 生成的网址示例:https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID?code=AUTHORIZATION_CODE&state=STATE_STRING
处理令牌交换请求
您的服务的令牌交换端点负责处理两种令牌 广告交易平台:
- 交换访问令牌和刷新令牌的授权代码
- 用刷新令牌换取访问令牌
令牌交换请求包含以下参数:
| 令牌交换端点参数 | |
|---|---|
client_id |
用于将请求来源标识为 Google 的字符串。此字符串必须 在您的系统中注册为 Google 的唯一标识符。 |
client_secret |
您在 Google 中为您的服务注册的密钥字符串。 |
grant_type |
所交换的令牌的类型。是
authorization_code 或 refresh_token。 |
code |
如果值为 grant_type=authorization_code,则此参数为
Google 通过您的登录或令牌交换收到的代码
端点。 |
redirect_uri |
如果值为 grant_type=authorization_code,则此参数为
初始授权请求中使用的网址。 |
refresh_token |
如果值为 grant_type=refresh_token,则此参数为
刷新令牌 Google 从您的令牌交换端点收到的令牌。 |
交换访问令牌和刷新令牌的授权代码
用户登录且您的授权端点返回一个短期有效的 授权代码发送给 Google,Google 会向您的令牌交换发送请求 端点使用授权代码交换访问令牌和刷新 令牌。
对于这些请求,grant_type 的值为 authorization_code,
的 code 值是您先前授予的授权代码的值
。以下是发送
访问令牌和刷新令牌的授权代码:
POST /token HTTP/1.1 Host: oauth2.example.com Content-Type: application/x-www-form-urlencoded client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=REDIRECT_URI
要将授权代码交换为访问令牌和刷新令牌,您的
令牌交换端点通过执行以下命令来响应 POST 请求:
步骤:
- 验证
client_id是否将请求来源标识为已获授权的请求来源 来源,并且client_secret与预期值匹配。 - 请确认授权代码有效且未过期, 请求中指定的客户端 ID 与 授权代码。
- 确认
redirect_uri参数指定的网址完全相同 初始授权请求中使用的值。 - 如果您无法验证上述所有条件,则返回 HTTP
正文为
{"error": "invalid_grant"}的 400 Bad Request 错误。 - 否则,使用授权代码中的用户 ID 来生成刷新 令牌和访问令牌。这些标记可以是任何字符串值, 必须唯一地代表用户和令牌对应的客户端, 不得被猜到对于访问令牌,请记录 令牌,通常是在您发出令牌一个小时后。 刷新令牌不会过期。
- 在 HTTPS 响应的正文中返回以下 JSON 对象:
{ "token_type": "Bearer", "access_token": "ACCESS_TOKEN", "refresh_token": "REFRESH_TOKEN", "expires_in": SECONDS_TO_EXPIRATION }
Google 会存储用户的访问令牌和刷新令牌,并存储相关记录 访问令牌的有效期。访问令牌过期后,Google 会使用 刷新令牌,以从令牌交换端点获取新的访问令牌。
用刷新令牌换取访问令牌
访问令牌过期后,Google 会向您的令牌交换发送请求 端点将刷新令牌交换为新的访问令牌。
对于这些请求,grant_type 的值为 refresh_token,值
“refresh_token”是您之前授予的刷新令牌的值
Google。以下是交换刷新令牌的请求示例
获取访问令牌:
POST /token HTTP/1.1 Host: oauth2.example.com Content-Type: application/x-www-form-urlencoded client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=refresh_token&refresh_token=REFRESH_TOKEN
如需将刷新令牌交换为访问令牌,令牌交换端点
来响应 POST 请求:
- 验证
client_id是否将请求来源标识为 Google,并client_secret与预期值一致。 - 请确认刷新令牌有效,以及在 请求与刷新令牌所关联的客户端 ID 相匹配。
- 如果您无法验证上述所有条件,则返回 HTTP 400
正文为
{"error": "invalid_grant"}的 Bad Request 错误。 - 否则,请使用刷新令牌中的用户 ID 来生成访问权限 令牌。这些标记可以是任何字符串值,但它们必须是唯一的 代表用户和客户端,而不得 猜测。对于访问令牌,请记录令牌的到期时间, 通常在您发出令牌一小时后发送
- 在 HTTPS 的正文中返回以下 JSON 对象
回答:
{ "token_type": "不记名", "access_token": "ACCESS_TOKEN", “expires_in”:SECONDS_TO_EXPIRATION }
Menangani permintaan info pengguna
Endpoint userinfo adalah resource yang dilindungi OAuth 2.0 yang menampilkan klaim tentang pengguna yang ditautkan. Menerapkan dan menghosting endpoint userinfo bersifat opsional, kecuali untuk kasus penggunaan berikut:
- Login dengan Akun Tertaut dengan Google One Ketuk.
- Langganan tanpa hambatan di Android TV.
Setelah token akses berhasil diambil dari endpoint token Anda, Google akan mengirimkan permintaan ke endpoint userinfo Anda untuk mengambil informasi profil dasar tentang pengguna yang ditautkan.
| header permintaan endpoint userinfo | |
|---|---|
Authorization header |
Token akses jenis Bearer. |
Misalnya, jika endpoint userinfo Anda tersedia di
https://myservice.example.com/userinfo, permintaan mungkin akan terlihat seperti berikut:
GET /userinfo HTTP/1.1 Host: myservice.example.com Authorization: Bearer ACCESS_TOKEN
Agar endpoint userinfo Anda dapat menangani permintaan, lakukan langkah-langkah berikut:
- Ekstrak token akses dari header Otorisasi dan tampilkan informasi untuk pengguna yang terkait dengan token akses.
- Jika token akses tidak valid, tampilkan error HTTP 401 Tidak Sah dengan menggunakan Header Respons
WWW-Authenticate. Berikut adalah contoh respons error userinfo: Jika pesan error 401 Tidak Sah, atau respons error lainnya yang tidak berhasil ditampilkan selama proses penautan, error tersebut tidak akan dapat dipulihkan, token yang diambil akan dihapus dan pengguna harus memulai proses penautan lagi.HTTP/1.1 401 Unauthorized WWW-Authenticate: error="invalid_token", error_description="The Access Token expired"
Jika token akses valid, tampilkan dan respons HTTP 200 dengan objek JSON berikut dalam isi HTTPS respons:
Jika endpoint userinfo Anda menampilkan respons sukses HTTP 200, token dan klaim yang diambil akan didaftarkan terhadap Akun Google pengguna.{ "sub": "USER_UUID", "email": "EMAIL_ADDRESS", "given_name": "FIRST_NAME", "family_name": "LAST_NAME", "name": "FULL_NAME", "picture": "PROFILE_PICTURE", }respons endpoint userinfo subID unik yang mengidentifikasi pengguna di sistem Anda. emailAlamat email pengguna. given_nameOpsional: Nama depan pengguna. family_nameOpsional: Nama belakang pengguna. nameOpsional: Nama lengkap pengguna. pictureOpsional: Foto profil pengguna.
Memvalidasi implementasi
您可以使用 OAuth 2.0 Playground 工具验证您的实现。
在该工具中,执行以下步骤:
- 点击配置 以打开 OAuth 2.0 配置窗口。
- 在 OAuth flow 字段中,选择 Client-side(客户端)。
- 在 OAuth 端点字段中,选择自定义。
- 在相应字段中指定您的 OAuth 2.0 端点和您分配给 Google 的客户端 ID。
- 在第 1 步部分,不要选择任何 Google 范围。请将此字段留空或输入对服务器有效的范围(如果您不使用 OAuth 范围,则可以输入任意字符串)。完成后,点击授权 API。
- 在 Step 2 和 Step 3 部分中,完成 OAuth 2.0 流程,并验证每个步骤是否按预期运行。
您可以使用 Google 账号关联演示版工具验证您的实现。
在该工具中,执行以下步骤:
- 点击使用 Google 账号登录按钮。
- 选择您要关联的账号。
- 输入服务 ID。
- (可选)输入您要请求访问权限的一个或多个范围。
- 点击开始演示。
- 当系统提示时,请确认您同意或拒绝关联请求。
- 确认您已被重定向到您的平台。