ระบบจะลิงก์บัญชีโดยใช้ขั้นตอน รหัสการให้สิทธิ์ OAuth 2.0 ซึ่งเป็นมาตรฐานอุตสาหกรรม
OAuth 2.1 และ PKCE สำหรับ Agent
เราขอแนะนำให้บังคับใช้ OAuth 2.1 สำหรับ Agent AI แบบไร้สถานะและไปป์ไลน์แบบมัลติโมดัล
- PKCE (Proof Key for Code Exchange): ต้องใช้เพื่อรักษาความปลอดภัย ขั้นตอนรหัสการให้สิทธิ์ ซึ่งจะป้องกันการโจมตีแบบดักรับ
- ไม่มีขั้นตอนการให้สิทธิ์โดยนัย: ขั้นตอนการให้สิทธิ์โดยนัยจะเปิดเผยโทเค็นเพื่อการเข้าถึงใน URL ซึ่งเป็นความเสี่ยงด้านความปลอดภัยสำหรับสภาพแวดล้อมของ Agent
บริการของคุณต้องรองรับปลายทาง การให้สิทธิ์และ การแลกเปลี่ยนโทเค็นที่สอดคล้องกับ OAuth 2.0/2.1
สร้างโปรเจ็กต์
วิธีสร้างโปรเจ็กต์เพื่อใช้การลิงก์บัญชี
- ไปที่คอนโซล Google API
- คลิกสร้างโปรเจ็กต์
- ป้อนชื่อหรือยอมรับคำแนะนำที่สร้างขึ้น
- ยืนยันหรือแก้ไขช่องที่เหลือ
- คลิกสร้าง
วิธีดูรหัสโปรเจ็กต์
- ไปที่คอนโซล Google API
- ค้นหาโปรเจ็กต์ในตารางบนหน้า Landing Page รหัสโปรเจ็กต์จะปรากฏในคอลัมน์รหัส
กำหนดค่าหน้าจอขอความยินยอม OAuth
กระบวนการลิงก์บัญชี Google มีหน้าจอขอความยินยอมซึ่งจะแจ้งให้ผู้ใช้ทราบว่าแอปพลิเคชันใดขอสิทธิ์เข้าถึงข้อมูลของผู้ใช้ ข้อมูลประเภทใดที่แอปพลิเคชันขอ และข้อกำหนดที่เกี่ยวข้อง คุณจะต้องกำหนดค่าหน้าจอขอความยินยอม OAuth ก่อนที่จะสร้างรหัสไคลเอ็นต์ Google API
- เปิดหน้าหน้าจอขอความยินยอม OAuth ของคอนโซล Google APIs
- หากได้รับข้อความแจ้ง ให้เลือกโปรเจ็กต์ที่คุณเพิ่งสร้าง
ในหน้า "หน้าจอขอความยินยอม OAuth" ให้กรอกแบบฟอร์มแล้วคลิกปุ่ม "บันทึก"
ชื่อแอปพลิเคชัน: ชื่อของแอปพลิเคชันที่ขอความยินยอม ชื่อควรแสดงถึงแอปพลิเคชันของคุณอย่างถูกต้องและสอดคล้องกับชื่อแอปพลิเคชันที่ผู้ใช้เห็นในที่อื่นๆ ชื่อแอปพลิเคชันจะแสดงในหน้าจอขอความยินยอมในการลิงก์บัญชี
โลโก้แอปพลิเคชัน: รูปภาพในหน้าจอขอความยินยอมที่จะช่วยให้ผู้ใช้จดจำแอปของคุณได้ โลโก้จะแสดงในหน้าจอขอความยินยอมในการลิงก์บัญชีและในการตั้งค่าบัญชี
อีเมลสนับสนุน: เพื่อให้ผู้ใช้ติดต่อคุณพร้อมคำถามเกี่ยวกับการยินยอม
ขอบเขตสำหรับ Google APIs: ขอบเขตช่วยให้แอปพลิเคชันเข้าถึงข้อมูล Google ส่วนตัวของผู้ใช้ได้ สำหรับกรณีการใช้งานการลิงก์บัญชี Google ขอบเขตเริ่มต้น (อีเมล โปรไฟล์ openid) ก็เพียงพอแล้ว คุณไม่จำเป็นต้องเพิ่มขอบเขตที่มีความละเอียดอ่อน โดยทั่วไปแล้ว แนวทางปฏิบัติแนะนำคือการขอขอบเขตทีละรายการเมื่อจำเป็นต้องเข้าถึง แทนที่จะขอตั้งแต่แรก ดูข้อมูลเพิ่มเติม
โดเมนที่ได้รับอนุญาต: Google อนุญาตเฉพาะแอปพลิเคชันที่ตรวจสอบสิทธิ์โดยใช้ OAuth ในการใช้โดเมนที่ได้รับอนุญาตเท่านั้นเพื่อเป็นการปกป้องคุณและผู้ใช้ ลิงก์ของแอปพลิเคชันต้องโฮสต์อยู่ในโดเมนที่ได้รับอนุญาต ดูข้อมูลเพิ่มเติม
ลิงก์หน้าแรกของแอปพลิเคชัน: หน้าแรกของแอปพลิเคชัน ต้องโฮสต์ในโดเมนที่ได้รับอนุญาต
ลิงก์นโยบายความเป็นส่วนตัวของแอปพลิเคชัน: แสดงในหน้าจอขอความยินยอมในการลิงก์บัญชี Google ต้องโฮสต์ในโดเมนที่ได้รับอนุญาต
ลิงก์ข้อกำหนดในการให้บริการของแอปพลิเคชัน (ไม่บังคับ): ต้องโฮสต์ในโดเมนที่ได้รับอนุญาต
รูปที่ 1 หน้าจอความยินยอมในการลิงก์บัญชี Google สำหรับแอปพลิเคชันสมมติ Tunery
ตรวจสอบ "สถานะการยืนยัน" หากแอปพลิเคชันของคุณต้องได้รับการยืนยัน ให้คลิกปุ่ม "ส่งเพื่อรับการยืนยัน" เพื่อส่งแอปพลิเคชันเพื่อรับการยืนยัน ดูรายละเอียดได้ที่ข้อกำหนดในการยืนยัน OAuth
ติดตั้งใช้งานเซิร์ฟเวอร์ OAuth
การติดตั้งใช้งานเซิร์ฟเวอร์ OAuth 2.0 ของขั้นตอนรหัสการให้สิทธิ์ประกอบด้วย ปลายทาง 2 รายการ ซึ่งบริการของคุณจะทำให้พร้อมใช้งานผ่าน HTTPS ปลายทางแรก คือปลายทางการให้สิทธิ์ ซึ่งมีหน้าที่ค้นหาหรือขอ ความยินยอมจากผู้ใช้สำหรับการเข้าถึงข้อมูล ปลายทางการให้สิทธิ์จะแสดง UI การลงชื่อเข้าใช้ต่อผู้ใช้ที่ยังไม่ได้ลงชื่อเข้าใช้ และบันทึกความยินยอมในการเข้าถึงที่ขอ ส่วนปลายทางที่ 2 คือปลายทางการแลกเปลี่ยนโทเค็น ซึ่งใช้เพื่อรับสตริงที่เข้ารหัสที่เรียกว่าโทเค็น ซึ่งให้สิทธิ์ผู้ใช้ในการเข้าถึงบริการของคุณ
เมื่อแอปพลิเคชันของ Google ต้องการเรียกใช้ API ของบริการใดบริการหนึ่ง Google จะใช้ ปลายทางเหล่านี้ร่วมกันเพื่อขอสิทธิ์จากผู้ใช้ในการเรียกใช้ API เหล่านี้ ในนามของผู้ใช้
การลิงก์บัญชี Google: ขั้นตอนรหัสการให้สิทธิ์ OAuth
แผนภาพลำดับต่อไปนี้แสดงรายละเอียดการโต้ตอบระหว่างผู้ใช้ Google และปลายทางของบริการ
บทบาทและความรับผิดชอบ
ตารางต่อไปนี้จะกำหนดบทบาทและความรับผิดชอบของผู้เกี่ยวข้องใน ขั้นตอน OAuth ของการลิงก์บัญชี Google (GAL) โปรดทราบว่าใน GAL นั้น Google จะทำหน้าที่เป็นไคลเอ็นต์ OAuth ส่วนบริการของคุณจะทำหน้าที่เป็นผู้ให้บริการข้อมูลประจำตัว/บริการ
| ผู้ดำเนินการ / คอมโพเนนต์ | บทบาท GAL | หน้าที่รับผิดชอบ |
|---|---|---|
| แอป / เซิร์ฟเวอร์ของ Google | ไคลเอ็นต์ OAuth | เริ่มโฟลว์ รับรหัสการให้สิทธิ์ แลกเปลี่ยนรหัสการให้สิทธิ์เป็น โทเค็น และจัดเก็บโทเค็นอย่างปลอดภัยเพื่อเข้าถึง API ของบริการ |
| ปลายทางการให้สิทธิ์ | เซิร์ฟเวอร์การให้สิทธิ์ | ตรวจสอบสิทธิ์ผู้ใช้และขอความยินยอมในการแชร์สิทธิ์เข้าถึง ข้อมูลกับ Google |
| ปลายทางการแลกเปลี่ยนโทเค็น | เซิร์ฟเวอร์การให้สิทธิ์ | ตรวจสอบรหัสการให้สิทธิ์และโทเค็นการรีเฟรช รวมถึงออกโทเค็นเพื่อการเข้าถึง ให้กับเซิร์ฟเวอร์ของ Google |
| URI การเปลี่ยนเส้นทางของ Google | ปลายทางการเรียกกลับ | รับการเปลี่ยนเส้นทางผู้ใช้จากบริการการให้สิทธิ์ของคุณพร้อมค่า code และ state |
เซสชันขั้นตอนรหัสการให้สิทธิ์ OAuth 2.0 ที่ Google เริ่มต้นจะมีโฟลว์ดังนี้
- Google จะเปิดปลายทางการให้สิทธิ์ในเบราว์เซอร์ของผู้ใช้ หากโฟลว์ เริ่มต้นในอุปกรณ์ที่ใช้เสียงเท่านั้นสำหรับ Action Google จะโอน การดำเนินการไปยังโทรศัพท์
- ผู้ใช้จะลงชื่อเข้าใช้ (หากยังไม่ได้ลงชื่อเข้าใช้) และให้สิทธิ์ Google ในการ เข้าถึงข้อมูลด้วย API ของคุณ หากยังไม่ได้ให้สิทธิ์
- บริการของคุณจะสร้างรหัสการให้สิทธิ์และส่งกลับไปยัง Google โดยให้เปลี่ยนเส้นทางเบราว์เซอร์ของผู้ใช้กลับไปที่ Google พร้อมแนบรหัสการให้สิทธิ์ไปกับคำขอ
- Google จะส่งรหัสการให้สิทธิ์ไปยังปลายทางการแลกเปลี่ยนโทเค็นของคุณ ซึ่งจะ ยืนยันความถูกต้องของรหัสและแสดงโทเค็นเพื่อการเข้าถึงและ โทเค็นการรีเฟรช โทเค็นเพื่อการเข้าถึงเป็นโทเค็นที่มีอายุสั้นซึ่งบริการของคุณ ยอมรับเป็นข้อมูลเข้าสู่ระบบเพื่อเข้าถึง API โทเค็นการรีเฟรชเป็นโทเค็นที่ใช้ได้นาน ซึ่ง Google สามารถจัดเก็บและใช้เพื่อขอโทเค็นเพื่อการเข้าถึงใหม่เมื่อโทเค็นหมดอายุ
- หลังจากที่ผู้ใช้ทำตามโฟลว์การลิงก์บัญชีเสร็จสมบูรณ์แล้ว คำขอที่ส่งจาก Google ในครั้งต่อๆ ไปจะมีโทเค็นเพื่อการเข้าถึง
สูตรการติดตั้งใช้งาน
ทำตามขั้นตอนต่อไปนี้เพื่อใช้โฟลว์รหัสการให้สิทธิ์
ขั้นตอนที่ 1: จัดการคำขอการให้สิทธิ์
เมื่อ Google เริ่มการลิงก์บัญชี ระบบจะเปลี่ยนเส้นทางผู้ใช้ไปยัง ปลายทางการให้สิทธิ์ของคุณ โปรดดูรายละเอียดสัญญาโปรโตคอลและข้อกำหนดของพารามิเตอร์ ที่ปลายทางการให้สิทธิ์
หากต้องการจัดการคำขอ ให้ดำเนินการต่อไปนี้
ตรวจสอบคำขอ
- ยืนยันว่า
client_idตรงกับรหัสไคลเอ็นต์ที่กำหนดให้กับ Google - ยืนยันว่า
redirect_uriตรงกับ URL การเปลี่ยนเส้นทางของ Google ที่คาดไว้ ดังนี้- Prod:
https://oauth-redirect.googleusercontent.com/r/YOUR_PARTNER_ID - แซนด์บ็อกซ์:
https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PARTNER_ID
- Prod:
- ตรวจสอบว่า
response_typeคือcode
- ยืนยันว่า
ตรวจสอบสิทธิ์ผู้ใช้:
- ตรวจสอบว่าผู้ใช้ลงชื่อเข้าใช้บริการของคุณหรือไม่
- หากผู้ใช้ไม่ได้ลงชื่อเข้าใช้ ให้แจ้งให้ผู้ใช้ทำตามขั้นตอนการลงชื่อเข้าใช้หรือ ลงชื่อสมัครใช้ให้เสร็จสมบูรณ์
สร้างรหัสการให้สิทธิ์:
- สร้างรหัสการให้สิทธิ์ที่ไม่ซ้ำกันและคาดเดาไม่ได้ซึ่งเชื่อมโยงกับ ผู้ใช้และไคลเอ็นต์
- ตั้งค่าให้รหัสหมดอายุในอีกประมาณ 10 นาที
เปลี่ยนเส้นทางกลับไปที่ Google
- เปลี่ยนเส้นทางเบราว์เซอร์ไปยัง URL ที่ระบุใน
redirect_uri - ต่อท้ายพารามิเตอร์การค้นหาต่อไปนี้
code: รหัสการให้สิทธิ์ที่คุณสร้างstate: ค่าสถานะที่ไม่ได้แก้ไขซึ่งได้รับจาก Google
- เปลี่ยนเส้นทางเบราว์เซอร์ไปยัง URL ที่ระบุใน
ขั้นตอนที่ 2: จัดการคำขอแลกเปลี่ยนโทเค็น
ปลายทางการแลกเปลี่ยนโทเค็นจะประมวลผลคำขอ 2 ประเภท ได้แก่ การแลกรหัส เป็นโทเค็น และการรีเฟรชโทเค็นเพื่อการเข้าถึงที่หมดอายุ ดูรายละเอียดเกี่ยวกับสัญญาโปรโตคอล และข้อกำหนดของพารามิเตอร์ได้ที่ปลายทางแลกเปลี่ยนโทเค็น
ก. แลกรหัสการให้สิทธิ์เป็นโทเค็น
เมื่อ Google ได้รับรหัสการให้สิทธิ์แล้ว ระบบจะเรียกใช้ปลายทางการแลกเปลี่ยนโทเค็น (POST) เพื่อดึงข้อมูลโทเค็น
ตรวจสอบคำขอ
- ยืนยัน
client_idและclient_secret - ตรวจสอบว่ารหัสการให้สิทธิ์ถูกต้องและยังไม่หมดอายุ
- ตรวจสอบว่า
redirect_uriตรงกับค่าที่ใช้ในขั้นตอนที่ 1 - หากการตรวจสอบไม่สำเร็จ ให้ส่งคืน HTTP
400 Bad Requestพร้อม{"error": "invalid_grant"}
- ยืนยัน
ออกโทเค็น
- สร้าง
refresh_tokenที่มีอายุการใช้งานยาวนานและaccess_tokenที่มีอายุการใช้งานสั้น (โดยปกติคือ 1 ชั่วโมง) - ส่งคืน HTTP
200 OKพร้อมการตอบกลับโทเค็น JSON มาตรฐาน
- สร้าง
ข. รีเฟรชโทเค็นเพื่อการเข้าถึง
เมื่อโทเค็นเพื่อการเข้าถึงหมดอายุ Google จะขอโทเค็นใหม่โดยใช้โทเค็นการรีเฟรช
ตรวจสอบคำขอ
- ยืนยัน
client_id,client_secretและrefresh_token - หากการตรวจสอบไม่สำเร็จ ให้ส่งคืน HTTP
400 Bad Requestพร้อม{"error": "invalid_grant"}
- ยืนยัน
ออกโทเค็นเพื่อการเข้าถึงใหม่
- สร้าง
access_tokenที่ใช้งานได้ชั่วคราวใหม่ - ส่งคืน HTTP
200 OKพร้อมการตอบกลับโทเค็น JSON (รวมถึงโทเค็นการรีเฟรชใหม่ด้วยก็ได้)
- สร้าง
Handle userinfo requests
The userinfo endpoint is an OAuth 2.0 protected resource that return claims about the linked user. Implementing and hosting the userinfo endpoint is optional, except for the following use cases:
- Linked Account Sign-In with Google One Tap.
- Frictionless subscription on AndroidTV.
After the access token has been successfully retrieved from your token endpoint, Google sends a request to your userinfo endpoint to retrieve basic profile information about the linked user.
| userinfo endpoint request headers | |
|---|---|
Authorization header |
The access token of type Bearer. |
For example, if your userinfo endpoint is available at
https://myservice.example.com/userinfo, a request might look like the following:
GET /userinfo HTTP/1.1 Host: myservice.example.com Authorization: Bearer ACCESS_TOKEN
For your userinfo endpoint to handle requests, do the following steps:
- Extract access token from the Authorization header and return information for the user associated with the access token.
- If the access token is invalid, return an HTTP 401 Unauthorized error with using the
WWW-AuthenticateResponse Header. Below is an example of a userinfo error response: If a 401 Unauthorized, or any other unsuccessful error response is returned during the linking process, the error will be non-recoverable, the retrieved token will be discarded and the user will have to initiate the linking process again.HTTP/1.1 401 Unauthorized WWW-Authenticate: error="invalid_token", error_description="The Access Token expired"
If the access token is valid, return and HTTP 200 response with the following JSON object in the body of the HTTPS response:
If your userinfo endpoint returns an HTTP 200 success response, the retrieved token and claims are registered against the user's Google account.{ "sub": "USER_UUID", "email": "EMAIL_ADDRESS", "given_name": "FIRST_NAME", "family_name": "LAST_NAME", "name": "FULL_NAME", "picture": "PROFILE_PICTURE", }userinfo endpoint response subA unique ID that identifies the user in your system. emailEmail address of the user. given_nameOptional: First name of the user. family_nameOptional: Last name of the user. nameOptional: Full name of the user. pictureOptional: Profile picture of the user.
การตรวจสอบการติดตั้งใช้งาน
คุณสามารถตรวจสอบการติดตั้งใช้งานได้โดยใช้เครื่องมือ OAuth 2.0 Playground
ในเครื่องมือ ให้ทำตามขั้นตอนต่อไปนี้
- คลิกการกำหนดค่า เพื่อเปิดหน้าต่างการกำหนดค่า OAuth 2.0
- ในช่องโฟลว์ OAuth ให้เลือกฝั่งไคลเอ็นต์
- ในช่องปลายทาง OAuth ให้เลือกกำหนดเอง
- ระบุปลายทาง OAuth 2.0 และรหัสไคลเอ็นต์ที่คุณกำหนดให้กับ Google ในช่องที่เกี่ยวข้อง
- ในส่วนขั้นตอนที่ 1 ไม่ต้องเลือกขอบเขตของ Google แต่ให้เว้นช่องนี้ว่างไว้หรือพิมพ์ขอบเขตที่ใช้ได้กับเซิร์ฟเวอร์ (หรือสตริงที่กำหนดเองหากคุณไม่ได้ใช้ขอบเขต OAuth) เมื่อเสร็จแล้ว ให้คลิกให้สิทธิ์ API
- ในส่วนขั้นตอนที่ 2 และขั้นตอนที่ 3 ให้ทำตามโฟลว์ OAuth 2.0 และตรวจสอบว่าแต่ละขั้นตอนทำงานตามที่ตั้งใจไว้
คุณสามารถตรวจสอบการติดตั้งใช้งานได้โดยใช้เครื่องมือสาธิตการลิงก์บัญชี Google
ในเครื่องมือ ให้ทำตามขั้นตอนต่อไปนี้
- คลิกปุ่มลงชื่อเข้าใช้ด้วย Google
- เลือกบัญชีที่ต้องการลิงก์
- ป้อนรหัสบริการ
- ป้อนขอบเขตอย่างน้อย 1 รายการที่คุณจะขอสิทธิ์เข้าถึง (ไม่บังคับ)
- คลิกเริ่มการสาธิต
- เมื่อได้รับข้อความแจ้ง ให้ยืนยันว่าคุณอาจให้ความยินยอมและปฏิเสธคำขอลิงก์
- ยืนยันว่าระบบจะนำคุณไปยังแพลตฟอร์มของคุณ