การลิงก์บัญชี Google กับ OAuth

ระบบจะลิงก์บัญชีโดยใช้ขั้นตอน รหัสการให้สิทธิ์ OAuth 2.0 ซึ่งเป็นมาตรฐานอุตสาหกรรม

OAuth 2.1 และ PKCE สำหรับ Agent

เราขอแนะนำให้บังคับใช้ OAuth 2.1 สำหรับ AI Agent แบบไม่เก็บสถานะและไปป์ไลน์แบบมัลติโมดัล

• PKCE (Proof Key for Code Exchange): ต้องใช้เพื่อรักษาความปลอดภัย ขั้นตอนรหัสการให้สิทธิ์ ซึ่งจะป้องกันการโจมตีแบบดักรับ
• ไม่มีขั้นตอนการให้สิทธิ์โดยนัย: ขั้นตอนการให้สิทธิ์โดยนัยจะเปิดเผยโทเค็นเพื่อการเข้าถึงใน URL, ซึ่งเป็นความเสี่ยงด้านความปลอดภัยสำหรับสภาพแวดล้อมของ Agent

บริการของคุณต้องรองรับปลายทาง การให้สิทธิ์ และ การแลกเปลี่ยนโทเค็น ที่เป็นไปตามข้อกำหนด OAuth 2.0/2.1

หมายเหตุ: ขั้นตอนการให้สิทธิ์โดยนัยเลิกใช้งานแล้วและไม่รองรับการผสานรวมใหม่ หากคุณดูแลการผสานรวมขั้นตอนการให้สิทธิ์โดยนัยที่มีอยู่ โปรดดูเอกสารประกอบ [ขั้นตอนการให้สิทธิ์โดยนัยที่เก็บถาวรแล้ว](/identity/account-linking/archive/implicit-flow)

创建项目

**注意**： 您可以重复使用现有项目，无需专门为账号关联创建新项目。

如需创建项目以使用账号关联，请执行以下操作：

1. 前往 Google API 控制台。
2. 点击 Create project 。
3. 输入名称或接受生成的建议。
4. 确认或修改任何剩余字段。
5. 点击创建 。

如需查看项目 ID，请执行以下操作：

1. 前往 Google API 控制台。
2. 在着陆页的表格中找到您的项目。项目 ID 会显示在 ID 列中。

配置 OAuth 权限请求页面

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 验证要求。

ติดตั้งใช้งานเซิร์ฟเวอร์ OAuth

การใช้งานเซิร์ฟเวอร์ OAuth 2.0 ของโฟลว์ รหัสการให้สิทธิ์ประกอบด้วยปลายทาง 2 รายการ ซึ่งบริการของคุณจะให้บริการผ่าน HTTPS ปลายทางแรกคือปลายทางการให้สิทธิ์ ซึ่งมีหน้าที่ค้นหาหรือขอความยินยอมจากผู้ใช้ในการเข้าถึงข้อมูล ปลายทางการให้สิทธิ์จะแสดง UI การลงชื่อเข้าใช้แก่ผู้ใช้ที่ยังไม่ได้ลงชื่อเข้าใช้ และบันทึกความยินยอมในการเข้าถึงที่ขอ ปลายทางที่ 2 คือปลายทางการแลกเปลี่ยนโทเค็น ซึ่งใช้เพื่อรับสตริงที่เข้ารหัสที่เรียกว่าโทเค็น ซึ่งอนุญาตให้ผู้ใช้เข้าถึงบริการของคุณ

เมื่อแอปพลิเคชันของ Google ต้องการเรียกใช้ API ของบริการของคุณ Google จะใช้ปลายทางเหล่านี้ร่วมกันเพื่อขอสิทธิ์จากผู้ใช้ในการเรียกใช้ API เหล่านี้ในนามของผู้ใช้

การลิงก์บัญชี Google: ขั้นตอนรหัสการให้สิทธิ์ OAuth

แผนภาพลำดับเหตุการณ์ต่อไปนี้แสดงรายละเอียดการโต้ตอบระหว่างผู้ใช้ Google และปลายทางของบริการ

Figure 1. ลำดับเหตุการณ์ในขั้นตอนรหัสการให้สิทธิ์ OAuth 2.0 สำหรับการลิงก์บัญชี Google

บทบาทและความรับผิดชอบ

ตารางต่อไปนี้กำหนดบทบาทและความรับผิดชอบของผู้มีส่วนร่วมในโฟลว์ OAuth ของการลิงก์บัญชี Google (GAL) โปรดทราบว่าใน GAL นั้น Google จะทำหน้าที่เป็น ไคลเอ็นต์ OAuth ขณะที่บริการของคุณจะทำหน้าที่เป็น ผู้ให้บริการข้อมูลประจำตัว/บริการ

Actor / Component	GAL Role	Responsibilities
Google App / Server	OAuth Client	เริ่มต้นโฟลว์ รับรหัสการให้สิทธิ์ แลกเปลี่ยนรหัสเป็น โทเค็น และจัดเก็บโทเค็นอย่างปลอดภัยเพื่อเข้าถึง API ของบริการ
Your Authorization Endpoint	Authorization Server	ตรวจสอบสิทธิ์ผู้ใช้และขอความยินยอมจากผู้ใช้ในการแชร์สิทธิ์เข้าถึง ข้อมูลกับ Google
Your Token Exchange Endpoint	Authorization Server	ตรวจสอบรหัสการให้สิทธิ์และโทเค็นการรีเฟรช และออกโทเค็นเพื่อการเข้าถึงให้กับเซิร์ฟเวอร์ของ Google
Google Redirect URI	Callback Endpoint	รับการเปลี่ยนเส้นทางของผู้ใช้จากบริการการให้สิทธิ์พร้อมค่า code และ state

เซสชันขั้นตอนรหัสการให้สิทธิ์ OAuth 2.0 ที่ Google เริ่มต้นจะมีโฟลว์ดังนี้

1. Google จะเปิดปลายทางการให้สิทธิ์ในเบราว์เซอร์ของผู้ใช้ หากโฟลว์เริ่มต้นในอุปกรณ์ที่ใช้เสียงเท่านั้นสำหรับ Action Google จะโอนการดำเนินการไปยังโทรศัพท์
2. ผู้ใช้ลงชื่อเข้าใช้ (หากยังไม่ได้ลงชื่อเข้าใช้) และให้สิทธิ์ Google ในการเข้าถึงข้อมูลด้วย API ของคุณ (หากยังไม่ได้ให้สิทธิ์)
3. บริการของคุณจะสร้าง รหัสการให้สิทธิ์และส่งกลับไปยัง Google โดยเปลี่ยนเส้นทางเบราว์เซอร์ของผู้ใช้กลับไปที่ Google พร้อมรหัสการให้สิทธิ์ที่แนบมากับคำขอ
4. Google จะส่งรหัสการให้สิทธิ์ไปยังปลายทางการแลกเปลี่ยนโทเค็น ซึ่งจะตรวจสอบความถูกต้องของรหัสและส่งกลับ โทเค็นเพื่อการเข้าถึงและ โทเค็นการรีเฟรช โทเค็นเพื่อการเข้าถึงเป็นโทเค็นที่ใช้ได้ในระยะสั้น ซึ่งบริการของคุณยอมรับเป็นข้อมูลเข้าสู่ระบบเพื่อเข้าถึง API โทเค็นการรีเฟรชเป็นโทเค็นที่ใช้ได้นาน ซึ่ง Google สามารถจัดเก็บและใช้เพื่อรับโทเค็นเพื่อการเข้าถึงใหม่เมื่อโทเค็นเดิมหมดอายุ
5. หลังจากที่ผู้ใช้ทำตามขั้นตอนการลิงก์บัญชีเสร็จสมบูรณ์แล้ว คำขอที่ส่งจาก Google ทุกครั้งจะมีโทเค็นเพื่อการเข้าถึง

สูตรการใช้งาน

ทำตามขั้นตอนต่อไปนี้เพื่อใช้โฟลว์รหัสการให้สิทธิ์

ขั้นตอนที่ 1: จัดการคำขอการให้สิทธิ์

เมื่อ Google เริ่มต้นการลิงก์บัญชี ระบบจะเปลี่ยนเส้นทางผู้ใช้ไปยังปลายทางการให้สิทธิ์ โปรดดูข้อตกลงโปรโตคอลโดยละเอียดและข้อกำหนดของพารามิเตอร์ได้ที่ปลายทางการให้สิทธิ์

หากต้องการจัดการคำขอ ให้ทำดังนี้

1. ตรวจสอบคำขอ:

   • ยืนยันว่า client_id ตรงกับรหัสไคลเอ็นต์ที่กำหนดให้กับ Google
   • ยืนยันว่า redirect_uri ตรงกับ URL การเปลี่ยนเส้นทางที่คาดไว้ของ Google: none https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
   • ตรวจสอบว่า response_type คือ code

2. ตรวจสอบสิทธิ์ผู้ใช้:

   • ตรวจสอบว่าผู้ใช้ลงชื่อเข้าใช้บริการของคุณหรือไม่
   • หากผู้ใช้ไม่ได้ลงชื่อเข้าใช้ ให้แจ้งให้ผู้ใช้ทำตามขั้นตอนการลงชื่อเข้าใช้หรือลงชื่อสมัครใช้

3. สร้างรหัสการให้สิทธิ์:

   • สร้างรหัสการให้สิทธิ์ที่ไม่ซ้ำกันและคาดเดาได้ยาก ซึ่งเชื่อมโยงกับผู้ใช้และไคลเอ็นต์
   • ตั้งค่าให้รหัสหมดอายุในเวลาประมาณ 10 นาที

4. เปลี่ยนเส้นทางกลับไปที่ Google:

   • เปลี่ยนเส้นทางเบราว์เซอร์ไปยัง URL ที่ระบุไว้ใน redirect_uri
   • แนบพารามิเตอร์การค้นหาต่อไปนี้
     • code: รหัสการให้สิทธิ์ที่คุณสร้างขึ้น
     • state: ค่าสถานะที่ได้รับจาก Google โดยไม่มีการแก้ไข

ขั้นตอนที่ 2: จัดการคำขอแลกเปลี่ยนโทเค็น

ปลายทางการแลกเปลี่ยนโทเค็นจะประมวลผลคำขอ 2 ประเภท ได้แก่ การแลกรหัสเป็นโทเค็น และการรีเฟรชโทเค็นเพื่อการเข้าถึงที่หมดอายุ โปรดดูข้อตกลงโปรโตคอลโดยละเอียดและข้อกำหนดของพารามิเตอร์ได้ที่ปลายทางการแลกเปลี่ยนโทเค็น

ก. แลกรหัสการให้สิทธิ์เป็นโทเค็น

เมื่อ Google ได้รับรหัสการให้สิทธิ์ ระบบจะเรียกใช้ปลายทางการแลกเปลี่ยนโทเค็น (POST) เพื่อดึงโทเค็น

1. ตรวจสอบคำขอ:

   • ตรวจสอบ client_id และ client_secret
   • ตรวจสอบว่ารหัสการให้สิทธิ์ถูกต้องและไม่หมดอายุ
   • ยืนยันว่า redirect_uri ตรงกับค่าที่ใช้ในขั้นตอนที่ 1
   • หากการตรวจสอบไม่สำเร็จ ให้ส่งกลับ HTTP 400 Bad Request พร้อม {"error": "invalid_grant"}

2. ออกโทเค็น:

   • สร้าง refresh_token ที่ใช้ได้นานและ access_token ที่ใช้ได้ในระยะสั้น (โดยปกติคือ 1 ชั่วโมง)
   • ส่งกลับ HTTP 200 OK พร้อมการตอบกลับโทเค็น JSON มาตรฐาน

ข. รีเฟรชโทเค็นเพื่อการเข้าถึง

เมื่อโทเค็นเพื่อการเข้าถึงหมดอายุ Google จะขอโทเค็นใหม่โดยใช้โทเค็นการรีเฟรช

1. ตรวจสอบคำขอ:

   • ตรวจสอบ client_id, client_secret และ refresh_token
   • หากการตรวจสอบไม่สำเร็จ ให้ส่งกลับ HTTP 400 Bad Request พร้อม {"error": "invalid_grant"}

2. ออกโทเค็นเพื่อการเข้าถึงใหม่:

   • สร้าง access_token ใหม่ที่ใช้ได้ในระยะสั้น
   • ส่งกลับ HTTP 200 OK พร้อมการตอบกลับโทเค็น JSON (ซึ่งอาจรวมถึงโทเค็นการรีเฟรชใหม่)

จัดการคำขอ Userinfo

ปลายทาง userinfo เป็นทรัพยากรที่มีการป้องกันด้วย OAuth 2.0 ซึ่งส่งกลับการอ้างสิทธิ์เกี่ยวกับผู้ใช้ที่ลิงก์ การติดตั้งใช้งานและการโฮสต์ปลายทาง userinfo เป็นตัวเลือกที่ไม่บังคับ ยกเว้นกรณีการใช้งานต่อไปนี้

• ลงชื่อเข้าใช้บัญชีที่ลิงก์ด้วย Google One Tap
• การติดตามที่ราบรื่นบน AndroidTV

หลังจากเรียกโทเค็นเพื่อการเข้าถึงจากปลายทางของโทเค็นเรียบร้อยแล้ว Google จะส่งคำขอไปยังปลายทาง userinfo เพื่อดึงข้อมูลโปรไฟล์พื้นฐานเกี่ยวกับผู้ใช้ที่ลิงก์

ส่วนหัวของคำขอปลายทางของ userinfo
Authorization header	โทเค็นเพื่อการเข้าถึงของประเภท Bearer

ตัวอย่างเช่น หากปลายทาง userinfo พร้อมใช้งานที่ https://myservice.example.com/userinfo คำขออาจมีลักษณะดังต่อไปนี้

GET /userinfo HTTP/1.1
Host: myservice.example.com
Authorization: Bearer ACCESS_TOKEN

หากต้องการให้ปลายทาง userinfo จัดการคำขอ ให้ทำตามขั้นตอนต่อไปนี้

1. แยกโทเค็นเพื่อการเข้าถึงจากส่วนหัวการให้สิทธิ์ แล้วแสดงผลข้อมูลสำหรับผู้ใช้ที่เชื่อมโยงกับโทเค็นเพื่อการเข้าถึง
2. หากโทเค็นเพื่อการเข้าถึงไม่ถูกต้อง ให้แสดงข้อผิดพลาด HTTP 401 Unauthorized ด้วยการใช้ส่วนหัวการตอบกลับ WWW-Authenticate ตัวอย่างการตอบกลับข้อผิดพลาดเกี่ยวกับ Userinfo มีดังนี้

   HTTP/1.1 401 Unauthorized
   WWW-Authenticate: error="invalid_token",
   error_description="The Access Token expired"
   

   หากข้อผิดพลาด 401 Unauthorized หรือการตอบกลับที่ผิดพลาดอื่นๆ ที่ไม่สำเร็จในระหว่างกระบวนการลิงก์ ข้อผิดพลาดดังกล่าวจะกู้คืนไม่ได้ ระบบจะทิ้งโทเค็นที่ดึงมาและผู้ใช้จะต้องเริ่มกระบวนการลิงก์อีกครั้ง

3. หากโทเค็นเพื่อการเข้าถึงถูกต้อง ให้แสดงผลและการตอบสนอง HTTP 200 ด้วยออบเจ็กต์ JSON ต่อไปนี้ในเนื้อหาของ HTTPS การตอบกลับ:

   {
   "sub": "USER_UUID",
   "email": "EMAIL_ADDRESS",
   "given_name": "FIRST_NAME",
   "family_name": "LAST_NAME",
   "name": "FULL_NAME",
   "picture": "PROFILE_PICTURE",
   }

   หากปลายทาง userinfo ส่งการตอบกลับที่สำเร็จ HTTP 200 ระบบจะลงทะเบียนโทเค็นที่ดึงมาและการอ้างสิทธิ์กับบัญชี Google ของผู้ใช้

   การตอบสนองของปลายทาง userinfo
   sub	รหัสที่ไม่ซ้ำกันที่ระบุผู้ใช้ในระบบ
   email	อีเมลของผู้ใช้
   given_name	ไม่บังคับ: ชื่อของผู้ใช้
   family_name	ไม่บังคับ: นามสกุลของผู้ใช้
   name	ไม่บังคับ: ชื่อเต็มของผู้ใช้
   picture	ไม่บังคับ: รูปโปรไฟล์ของผู้ใช้

การตรวจสอบการติดตั้งใช้งาน

您可以使用 OAuth 2.0 Playground 工具验证您的实现。

在该工具中，执行以下步骤：

1. 点击配置 以打开“OAuth 2.0 配置”窗口。
2. 在 OAuth flow（OAuth 流程）字段中，选择 Client-side（客户端）。
3. 在 OAuth Endpoints 字段中，选择 Custom。
4. 在相应字段中指定您的 OAuth 2.0 端点以及您分配给 Google 的客户端 ID。
5. 在第 1 步部分中，请勿选择任何 Google 范围。请将此字段留空，或输入适用于您服务器的范围（如果您不使用 OAuth 范围，则输入任意字符串）。完成后，点击 Authorize APIs。
6. 在第 2 步和第 3 步部分中，完成 OAuth 2.0 流程，并验证每个步骤是否按预期运行。

您可以使用 Google 账号关联演示工具验证您的实现。

在该工具中，执行以下步骤：

1. 点击使用 Google 账号登录按钮。
2. 选择您要关联的账号。
3. 输入服务 ID。
4. （可选）输入您将请求访问的一个或多个范围。
5. 点击开始演示。
6. 当系统提示时，请确认您可以同意或拒绝关联请求。
7. 确认您已重定向到相应平台。