เลือกเส้นทางการผสานรวม
เลือกเส้นทางที่เหมาะกับความต้องการของคุณมากที่สุด
| เส้นทาง | เหมาะสำหรับ | ดูข้อมูลเพิ่มเติม |
|---|---|---|
| Universal Commerce Protocol (UCP) | ผู้ขายและผู้ค้าปลีก | เอกสาร UCP |
| การลิงก์บัญชีมาตรฐาน | บ้านอัจฉริยะ ทีวี และ YouTube | เอกสาร |
การลิงก์บัญชีช่วยให้ผู้ถือบัญชี Google เชื่อมต่อกับบริการของคุณได้อย่างรวดเร็ว ราบรื่น และปลอดภัย คุณอาจเลือกใช้การลิงก์บัญชี Google เพื่อ แชร์ข้อมูลของผู้ใช้จากแพลตฟอร์มของคุณกับแอปและบริการของ Google
โปรโตคอล OAuth 2.0 ที่ปลอดภัยช่วยให้คุณลิงก์บัญชี Google ของผู้ใช้กับ บัญชีในแพลตฟอร์มของคุณได้อย่างปลอดภัย ซึ่งจะทำให้แอปพลิเคชันและอุปกรณ์ของ Google มีสิทธิ์เข้าถึงบริการของคุณ
ผู้ใช้สามารถลิงก์หรือยกเลิกการลิงก์บัญชี และสร้างบัญชีใหม่ในแพลตฟอร์มของคุณได้ด้วยการลิงก์บัญชี Google
กรณีการใช้งาน
เหตุผลบางประการที่ควรใช้การลิงก์บัญชี Google มีดังนี้
แชร์ข้อมูลของผู้ใช้จากแพลตฟอร์มของคุณกับแอปและบริการของ Google
ผสานรวมกับ Google Shopping และแพลตฟอร์ม AI (Search, Gemini) โดยใช้ Universal Commerce Protocol (UCP)
เล่นเนื้อหาวิดีโอและภาพยนตร์โดยใช้ Google TV
จัดการและควบคุมอุปกรณ์ที่เชื่อมต่อกับ Google สมาร์ทโฮม โดยใช้แอป Google Home และ Google Assistant "Ok Google เปิดไฟ"
สร้างประสบการณ์การใช้งานและฟังก์ชันการทำงานของ Google Assistant ที่ผู้ใช้ปรับแต่งได้ด้วย การสนทนา "Ok Google สั่งกาแฟแก้วเดิมจาก Starbucks"
เปิดให้ผู้ใช้รับรางวัลได้โดยการดูสตรีมแบบสดที่มีสิทธิ์บน YouTube หลังจากลิงก์บัญชี Google กับบัญชีพาร์ทเนอร์ด้านรางวัล
ป้อนข้อมูลล่วงหน้าในบัญชีใหม่ระหว่างการลงชื่อสมัครใช้ด้วยข้อมูลที่แชร์โดยความยินยอมจาก โปรไฟล์บัญชี Google
ความสามารถและข้อกำหนด
เมทริกซ์ต่อไปนี้กำหนดการสนับสนุนและคำแนะนำสำหรับการเชื่อมโยงแต่ละโฟลว์
| การลิงก์ Flow | ฟีเจอร์มาตรฐาน | ฟีเจอร์ UCP |
|---|---|---|
| App Flip | แนะนำ | แนะนำ |
| การลิงก์ที่มีประสิทธิภาพ | แนะนำ | แนะนำ |
| การลิงก์ OAuth | ต้องระบุ (สำรอง) | ต้องระบุ (สำรอง) |
| OAuth 2.1 | แนะนำ | แนะนำ |
ปรับปรุงความเป็นส่วนตัวของผู้ใช้โดยกำหนดขอบเขตที่กำหนดเองเพื่อแชร์เฉพาะข้อมูลที่จำเป็น เพิ่มความไว้วางใจจากผู้ใช้โดยกำหนดวิธีใช้ข้อมูลของผู้ใช้อย่างชัดเจน
คุณเพิกถอนสิทธิ์เข้าถึงข้อมูลและบริการที่โฮสต์ในแพลตฟอร์มได้โดยยกเลิกการลิงก์บัญชี การติดตั้งใช้งานปลายทางการเพิกถอนโทเค็นที่ไม่บังคับช่วยให้คุณซิงค์กับเหตุการณ์ที่ Google เริ่มต้นได้ ขณะที่การป้องกันแบบครอบคลุมหลายบริการ(RISC)ช่วยให้คุณแจ้งให้ Google ทราบถึงเหตุการณ์การยกเลิกการลิงก์ที่เกิดขึ้นบนแพลตฟอร์มของคุณได้
ขั้นตอนการลิงก์บัญชี
ขั้นตอนการลิงก์บัญชี Google มี 3 ขั้นตอน ซึ่งทั้งหมดใช้ OAuth และกำหนดให้คุณต้องจัดการหรือควบคุมการให้สิทธิ์และปลายทางการแลกเปลี่ยนโทเค็นที่สอดคล้องกับ OAuth 2.0
ในระหว่างกระบวนการเชื่อมต่อ คุณจะออกโทเค็นเพื่อการเข้าถึงให้ Google สำหรับบัญชี Google ของแต่ละบุคคลหลังจากได้รับความยินยอมจากเจ้าของบัญชีให้ลิงก์บัญชีและแชร์ข้อมูล
การลิงก์ OAuth
นี่คือขั้นตอนการลิงก์ OAuth ที่ส่งผู้ใช้ไปยังเว็บไซต์ของคุณ เพื่อทำการลิงก์ ระบบจะเปลี่ยนเส้นทางผู้ใช้ไปยังเว็บไซต์ของคุณเพื่อลงชื่อเข้าใช้บัญชี เมื่อลงชื่อเข้าใช้แล้ว ผู้ใช้จะยินยอมให้แชร์ข้อมูลในบริการของคุณกับ Google เมื่อถึงจุดนั้น ระบบจะลิงก์บัญชี Google ของผู้ใช้กับบริการของคุณ
การลิงก์ OAuth รองรับรหัสการให้สิทธิ์และโฟลว์ OAuth โดยนัย บริการของคุณต้องโฮสต์ปลายทางการให้สิทธิ์ที่สอดคล้องกับ OAuth 2.0 สำหรับขั้นตอนการให้สิทธิ์โดยนัย และต้องแสดงทั้งปลายทางการให้สิทธิ์และการแลกเปลี่ยนโทเค็นเมื่อใช้ขั้นตอนรหัสการให้สิทธิ์
รูปที่ 1 การลิงก์บัญชีในโทรศัพท์ของผู้ใช้ด้วยการลิงก์ OAuth
การลิงก์ App Flip ที่ใช้ OAuth ("App Flip")
ขั้นตอน OAuth ที่ส่งผู้ใช้ไปยังแอปเพื่อลิงก์
การลิงก์ App Flip ที่ใช้ OAuth จะแนะนําผู้ใช้ขณะที่สลับไปมาระหว่างแอปบนอุปกรณ์เคลื่อนที่ Android หรือ iOS ที่ยืนยันแล้วกับแพลตฟอร์มของ Google เพื่อตรวจสอบการเปลี่ยนแปลงการเข้าถึงข้อมูลที่เสนอและให้ความยินยอมในการลิงก์บัญชีบนแพลตฟอร์มของคุณกับบัญชี Google หากต้องการเปิดใช้ App Flip บริการของคุณต้อง รองรับการลิงก์ OAuth หรือ การลิงก์การลงชื่อเข้าใช้ด้วย Google ที่อิงตาม OAuth โดยใช้ขั้นตอนรหัสการให้สิทธิ์
App Flip รองรับทั้ง Android และ iOS
วิธีการทำงาน
แอป Google จะตรวจสอบว่าแอปของคุณติดตั้งอยู่ในอุปกรณ์ของผู้ใช้หรือไม่ โดยทำดังนี้
- หากพบแอป ระบบจะ "เปลี่ยน" ผู้ใช้ไปยังแอปของคุณ แอปจะรวบรวม ความยินยอมจากผู้ใช้เพื่อลิงก์บัญชีกับ Google แล้ว "เปลี่ยนกลับ" ไปยังแพลตฟอร์มของ Google
- หากไม่พบแอปหรือเกิดข้อผิดพลาดระหว่างกระบวนการเชื่อมต่อ App Flip ระบบจะเปลี่ยนเส้นทางผู้ใช้ไปยังโฟลว์การลิงก์ที่ปรับปรุงแล้วหรือ OAuth
รูปที่ 2 การลิงก์บัญชีในโทรศัพท์ของผู้ใช้ด้วย App Flip
การลิงก์ที่ปรับปรุงแล้วที่ใช้ OAuth ("ปรับปรุงแล้ว")
การลงชื่อเข้าใช้ด้วย Google ที่ใช้ OAuth และการเชื่อมต่อที่ปรับปรุงแล้วจะเพิ่มการลงชื่อเข้าใช้ด้วย Google นอกเหนือจากการลิงก์ OAuth ซึ่งช่วยให้ผู้ใช้ทำกระบวนการเชื่อมต่อให้เสร็จสมบูรณ์ได้โดยไม่ต้องออกจากแพลตฟอร์มของ Google จึงช่วยลดอุปสรรคและอัตราการเลิกใช้งาน
การลิงก์ที่มีประสิทธิภาพซึ่งใช้ OAuth มอบประสบการณ์การใช้งานที่ดีที่สุด
ด้วยการลงชื่อเข้าใช้ การสร้างบัญชี และการลิงก์บัญชีที่ราบรื่น
โดยการรวมการลงชื่อเข้าใช้ด้วย Google กับการลิงก์ OAuth บริการของคุณต้อง
รองรับปลายทางการให้สิทธิ์และการแลกเปลี่ยนโทเค็นที่สอดคล้องกับ OAuth 2.0
นอกจากนี้ ปลายทางการแลกเปลี่ยนโทเค็นต้องรองรับการยืนยัน JSON Web Token (JWT)
และใช้
check,
create
และ get
Intent
วิธีการทำงาน
Google ยืนยันบัญชีผู้ใช้และส่งข้อมูลนี้ให้คุณ
- หากมีบัญชีสำหรับผู้ใช้ในฐานข้อมูล ผู้ใช้จะลิงก์บัญชี Google กับบัญชีในบริการของคุณได้สำเร็จ
- หากไม่มีบัญชีของผู้ใช้ในฐานข้อมูล ผู้ใช้จะเลือก สร้างบัญชีบุคคลที่สามใหม่ด้วยข้อมูลที่ Google ยืนยันให้ ซึ่งได้แก่ อีเมล ชื่อ และรูปโปรไฟล์ หรือเลือกที่จะลงชื่อเข้าใช้และลิงก์กับ อีเมลอื่น (ซึ่งจะต้องให้ผู้ใช้ลงชื่อเข้าใช้บริการของคุณโดยใช้การลิงก์ OAuth)
รูปที่ 3 การลิงก์บัญชีในโทรศัพท์ของผู้ใช้ด้วยการลิงก์ที่ปรับปรุงแล้ว
คุณควรใช้โฟลว์ใด
เราขอแนะนำให้ใช้ขั้นตอนทั้งหมดเพื่อให้ผู้ใช้ได้รับประสบการณ์การลิงก์ที่ดีที่สุด ขั้นตอน Streamlined และ App Flip ช่วยลดความยุ่งยากในการลิงก์ เนื่องจากผู้ใช้สามารถทำกระบวนการเชื่อมต่อให้เสร็จสมบูรณ์ได้ในไม่กี่ขั้นตอน ขั้นตอนการลิงก์ OAuth ใช้ความพยายามน้อยที่สุดและเป็นจุดเริ่มต้นที่ดี จากนั้นคุณ สามารถเพิ่มขั้นตอนการลิงก์อื่นๆ ได้
ทำงานกับโทเค็น
การลิงก์บัญชี Google อิงตามมาตรฐานอุตสาหกรรม OAuth 2.0
คุณออกโทเค็นการเข้าถึงให้ Google สำหรับบัญชี Google แต่ละบัญชีหลังจากได้รับ ความยินยอมจากผู้ถือบัญชีในการลิงก์บัญชีและแชร์ข้อมูล
Token types
OAuth 2.0 uses strings called tokens to communicate between the user agent, the client application, and the OAuth 2.0 server.
Three types of OAuth 2.0 tokens can be used during account linking:
Authorization code. A short-lived token that can be exchanged for an access and a refresh token. For security purposes, Google calls your authorization endpoint to obtain a single use or very short-lived code.
Access token. A token that grants the bearer access to a resource. To limit exposure that could result from the loss of this token, it has a limited lifetime, usually expiring after an hour or so.
Refresh token. A long-lived token that can be exchanged for a new access token when an access token expires. When your service integrates with Google, this token is exclusively stored and used by Google. Google calls your token exchange endpoint to exchange refresh tokens for access tokens, which are in turn used to access user data.
Token handling
Race conditions in clustered environments and client-server exchanges can result in complex timing and error handling scenarios when working with tokens. For example:
- You receive a request for a new access token, and you issue a new access token. Concurrently, you receive a request for access to your service's resource using the previous, unexpired access token.
- Your refresh token reply is yet to be received (or is never received) by Google. Meanwhile, the previously valid refresh token is used in a request from Google.
Requests and replies can arrive in any order, or not at all due to asynchronous services running in a cluster, network behavior, or other means.
Immediate and fully consistent shared state both within, and between, your and Google's token handling systems cannot be guaranteed. Multiple valid, unexpired tokens can coexist within or across systems short period of time. To minimize negative user impact we recommend you do the following:
- Accept unexpired access tokens, even after a newer token is issued.
- Use alternatives to Refresh Token Rotation.
- Support multiple, concurrently valid access and refresh tokens. For security, you should limit the number of tokens and token lifetime.
Maintenance and outage handling
During maintenance or unplanned outages Google might be unable to call your authorization or token exchange endpoints to obtain access and refresh tokens.
Your endpoints should respond with a 503 error code and empty body. In this
case, Google retries failed token exchange requests for a limited time. Provided
that Google is later able to obtain refresh and access tokens, failed requests
are not visible to users.
Failing requests for an access token result in a visible error, if initiated by a user. Users will be required to retry linking failures if the implicit OAuth 2.0 flow is used.
Recommendations
There are many solutions to minimize maintenance impact. Some options to consider:
Maintain your existing service and route a limited number of requests to your newly updated service. Migrate all requests only after confirming expected functionality.
Reduce the number of token requests during the maintenance period:
Limit maintenance periods to less than the access token lifetime.
Temporarily increase the access token lifetime:
- Increase token lifetime to greater than maintenance period.
- Wait twice the duration of your access token lifetime, enabling users to exchange short lived tokens for longer duration tokens.
- Enter maintenance.
- Respond to token requests with a
503error code and empty body. - Exit maintenance.
- Decrease token lifetime back to normal.
การลิงก์แบบถาวร
การลิงก์แบบถาวรเป็นข้อกำหนดหลักสำหรับการผสานรวมที่เสถียร ซึ่งจะช่วยให้มั่นใจได้ว่าบัญชีผู้ใช้จะยังคงลิงก์อยู่แม้ว่าเครือข่ายจะล้มเหลวชั่วคราวหรือมีการรีเฟรชข้อมูลเข้าสู่ระบบเป็นระยะๆ
หากต้องการใช้การลิงก์แบบถาวร ให้ใช้วิธี "หน้าต่างเลื่อน" โดยขยายวันหมดอายุของ Refresh Token ที่มีอยู่แทนที่จะหมุนเวียน (อ้างอิง RFC 6749 ส่วนที่ 6) ซึ่งจะป้องกันไม่ให้เกิดสภาวะการแข่งขันและการยกเลิกการลิงก์โดยไม่ตั้งใจ ที่อาจเกิดขึ้นหากมีการออกโทเค็นรีเฟรชใหม่ แต่ Google ไม่ได้รับหรือจัดเก็บโทเค็นดังกล่าวสำเร็จ
ลงทะเบียนด้วย Google
เราจะต้องทราบรายละเอียดการตั้งค่า OAuth 2.0 และแชร์ข้อมูลเข้าสู่ระบบเพื่อเปิดใช้การลิงก์บัญชี ดูรายละเอียดได้ที่การจดทะเบียน