Penautan Akun Google dengan OAuth

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:

    1. Menukar kode otorisasi dengan token refresh yang berumur panjang dan token akses yang berumur singkat. Pertukaran ini terjadi saat pengguna melalui alur penautan akun.
    2. 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.

Gambar ini menunjukkan langkah-langkah bagi pengguna untuk menautkan Akun Google mereka
            ke sistem autentikasi Anda. Screenshot pertama menunjukkan
            penautan yang dimulai pengguna dari platform Anda. Gambar kedua menunjukkan
            proses login pengguna ke Google, sedangkan gambar ketiga menunjukkan izin dan
            konfirmasi pengguna untuk menautkan Akun Google mereka dengan aplikasi Anda. Screenshot
            terakhir menunjukkan akun pengguna yang berhasil ditautkan di
            aplikasi Google.
Gambar 1. Akun yang menautkan pengguna, login ke Google dan layar izin.

Persyaratan

  1. 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:

  1. Menampilkan Kebijakan Privasi Google. Sertakan link ke Kebijakan Privasi Google di layar izin.

  2. Data yang akan dibagikan. Gunakan bahasa yang jelas dan ringkas untuk memberi tahu pengguna data apa saja yang diperlukan Google dan alasannya.

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

  4. Kemampuan untuk membatalkan. Berikan cara bagi pengguna untuk kembali atau membatalkan, jika mereka memilih untuk tidak menautkan.

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

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

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

创建项目

如需创建使用账号关联的项目,请执行以下操作:

  1. 点击 Create project
  2. 输入名称或接受生成的建议。
  3. 确认或修改所有剩余字段。
  4. 点击创建

如需查看项目 ID,请执行以下操作:

  1. 在着陆页的表格中找到您的项目。项目 ID 会显示在 ID 列中。

Google 账号关联流程包含一个权限请求页面,该页面会告知用户哪个应用在请求访问其数据、请求访问哪些类型的数据,以及适用的条款。您需要先配置 OAuth 权限请求页面,然后才能生成 Google API 客户端 ID。

  1. 打开 Google API 控制台的 OAuth 同意屏幕页面。
  2. 如果出现提示,请选择您刚刚创建的项目。
  3. 在“OAuth 同意屏幕”页面上,填写表单,然后点击“保存”按钮。

    应用名称:征求用户同意的应用的名称。名称应准确反映您的应用,并与用户在其他位置看到的应用名称保持一致。应用名称将显示在账号关联权限请求界面上。

    应用徽标:权限请求页面上显示的一张图片,用以让用户认出您的应用。徽标会显示在账号关联权限请求页面和账号设置

    支持电子邮件地址:供用户就其同意问题与您联系。

    Google API 的范围:借助范围,您的应用可以访问用户的非公开 Google 数据。对于 Google 账号关联使用情形,默认范围(电子邮件地址、个人资料、openid)就足够了,您无需添加任何敏感范围。一般来说,最佳做法是在需要访问权限时逐步请求权限范围,而不是提前请求。了解详情

    已获授权的网域:为了保护您和您的用户,Google 只允许使用 OAuth 进行身份验证的应用使用已获授权的网域。应用的链接必须托管在已获授权的网域上。了解详情

    应用首页链接:应用的首页。必须托管在已获授权的网域上。

    应用隐私权政策链接:显示在 Google 账号关联意见征求界面上。必须托管在已获授权的网域上。

    应用服务条款链接(可选):必须托管在已获授权的网域上。

    图 1. 虚构应用 Tunery 的 Google 账号关联意见征求界面

  4. 查看“验证状态”,如果您的应用需要验证,请点击“提交以供验证”按钮,提交应用以供验证。如需了解详情,请参阅 OAuth 验证要求

Menerapkan server OAuth

授权代码流程的 OAuth 2.0 服务器实现包括 两个端点,您的服务会通过 HTTPS 提供这两个端点。第一个端点 是授权端点,负责查找或获取 就数据访问征求用户意见。授权端点会提供一个 尚未登录的用户的登录界面,并记录同意情况 请求的访问权限。第二个端点是令牌交换端点, 用于获取加密字符串(称为令牌),以授权用户 访问您的服务。

当 Google 应用需要调用您的某个服务的 API 时,Google 会使用 将这些端点组合在一起,以获取用户调用这些 API 的权限 。

由 Google 发起的 OAuth 2.0 授权代码流程会话包含 以下流程:

  1. Google 会在用户的浏览器中打开您的授权端点。如果流 在用户通过纯语音设备上针对某个 Action 启动,Google 会将 将代码执行到手机上
  2. 用户登录(如果尚未登录),并授予 Google 以下权限: 访问您的 API 访问其数据(如果尚未授权)。
  3. 您的服务会创建授权代码并将其返回给 Google。待办事项 因此,请使用授权代码将用户的浏览器重定向回 Google。 附件。
  4. Google 会将授权代码发送到您的令牌交换端点, 验证代码的真实性并返回访问令牌刷新令牌。访问令牌是一个短期有效的令牌 作为访问 API 的凭据。刷新令牌长期有效 Google 可以存储该令牌,以便在用户首次访问该令牌时, 过期。
  5. 在用户完成账号关联流程后, 从 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

为了让授权端点能够处理登录请求,请执行以下操作 步骤:

  1. 验证 client_id 是否与您分配给 Google 的 Client ID 匹配,以及 redirect_uri 与 Google 为您的服务提供的重定向网址是否匹配。这些检查对于防止 访问意外或配置错误的客户端应用。如果你支持多种 OAuth 2.0 流程,还应确认 response_type 是否为 code
  2. 检查用户是否已登录您的服务。如果用户没有登录, 完成服务的登录或注册流程。
  3. 生成授权代码,以供 Google 用于访问您的 API。 授权代码可以是任何字符串值,但它必须是唯一的 代表用户、令牌对应的客户端以及代码的有效期 而且不可猜测出来。您通常需要进行授权 会在大约 10 分钟后过期。
  4. 确认 redirect_uri 参数指定的网址包含 以下表单:
      https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID
      https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
      
  5. 将用户的浏览器重定向到 redirect_uri 参数。添加您在 以及您在重定向时返回未经修改的原始状态值 方法是附加 codestate 参数。以下是 生成的网址示例:
    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_coderefresh_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 请求: 步骤:

  1. 验证 client_id 是否将请求来源标识为已获授权的请求来源 来源,并且 client_secret 与预期值匹配。
  2. 请确认授权代码有效且未过期, 请求中指定的客户端 ID 与 授权代码。
  3. 确认 redirect_uri 参数指定的网址完全相同 初始授权请求中使用的值。
  4. 如果您无法验证上述所有条件,则返回 HTTP 正文为 {"error": "invalid_grant"} 的 400 Bad Request 错误。
  5. 否则,使用授权代码中的用户 ID 来生成刷新 令牌和访问令牌。这些标记可以是任何字符串值, 必须唯一地代表用户和令牌对应的客户端, 不得被猜到对于访问令牌,请记录 令牌,通常是在您发出令牌一个小时后。 刷新令牌不会过期。
  6. 在 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 请求:

  1. 验证 client_id 是否将请求来源标识为 Google,并 client_secret 与预期值一致。
  2. 请确认刷新令牌有效,以及在 请求与刷新令牌所关联的客户端 ID 相匹配。
  3. 如果您无法验证上述所有条件,则返回 HTTP 400 正文为 {"error": "invalid_grant"} 的 Bad Request 错误。
  4. 否则,请使用刷新令牌中的用户 ID 来生成访问权限 令牌。这些标记可以是任何字符串值,但它们必须是唯一的 代表用户和客户端,而不得 猜测。对于访问令牌,请记录令牌的到期时间, 通常在您发出令牌一小时后发送
  5. 在 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:

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:

  1. Ekstrak token akses dari header Otorisasi dan tampilkan informasi untuk pengguna yang terkait dengan token akses.
  2. Jika token akses tidak valid, tampilkan error HTTP 401 Tidak Sah dengan menggunakan Header Respons WWW-Authenticate. Berikut adalah contoh respons error userinfo:
    HTTP/1.1 401 Unauthorized
    WWW-Authenticate: error="invalid_token",
    error_description="The Access Token expired"
    
    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.
  3. Jika token akses valid, tampilkan dan respons HTTP 200 dengan objek JSON berikut dalam isi HTTPS respons:

    {
    "sub": "USER_UUID",
    "email": "EMAIL_ADDRESS",
    "given_name": "FIRST_NAME",
    "family_name": "LAST_NAME",
    "name": "FULL_NAME",
    "picture": "PROFILE_PICTURE",
    }
    Jika endpoint userinfo Anda menampilkan respons sukses HTTP 200, token dan klaim yang diambil akan didaftarkan terhadap Akun Google pengguna.

    respons endpoint userinfo
    sub ID unik yang mengidentifikasi pengguna di sistem Anda.
    email Alamat email pengguna.
    given_name Opsional: Nama depan pengguna.
    family_name Opsional: Nama belakang pengguna.
    name Opsional: Nama lengkap pengguna.
    picture Opsional: Foto profil pengguna.

Memvalidasi implementasi

Anda dapat memvalidasi penerapan menggunakan alat OAuth 2.0 Playground.

Di alat ini, lakukan langkah-langkah berikut:

  1. Klik Configuration untuk membuka jendela OAuth 2.0 Configuration.
  2. Di kolom OAuth flow, pilih Client-side.
  3. Di kolom OAuth Endpoints, pilih Custom.
  4. Tentukan endpoint OAuth 2.0 dan client ID yang Anda tetapkan ke Google di kolom yang sesuai.
  5. Di bagian Langkah 1, jangan pilih cakupan Google apa pun. Sebagai gantinya, biarkan kolom ini kosong atau ketik cakupan yang valid untuk server Anda (atau string arbitrer jika Anda tidak menggunakan cakupan OAuth). Setelah selesai, klik Otorisasi API.
  6. Di bagian Langkah 2 dan Langkah 3, ikuti alur OAuth 2.0 dan verifikasi bahwa setiap langkah berfungsi sebagaimana mestinya.

Anda dapat memvalidasi penerapan menggunakan alat Demo Penautan Akun Google.

Di alat tersebut, lakukan langkah-langkah berikut:

  1. Klik tombol Login dengan Google.
  2. Pilih akun yang ingin ditautkan.
  3. Masukkan ID layanan.
  4. Secara opsional, masukkan satu atau beberapa cakupan yang akan Anda minta aksesnya.
  5. Klik Mulai Demo.
  6. Jika diminta, konfirmasi bahwa Anda dapat mengizinkan dan menolak permintaan penautan.
  7. Pastikan Anda dialihkan ke platform Anda.