ภาพรวม

การลิงก์บัญชีช่วยให้ผู้ถือบัญชี Google เชื่อมต่อกับบริการของคุณได้อย่างรวดเร็ว ราบรื่น และปลอดภัย คุณอาจเลือกใช้บัญชี Google ในการลิงก์เพื่อแชร์ข้อมูลจากแพลตฟอร์มของคุณกับแอปและบริการของ Google

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

ผู้ใช้สามารถลิงก์หรือยกเลิกการลิงก์บัญชี และสร้างบัญชีใหม่ในแพลตฟอร์มของคุณได้ด้วยการลิงก์บัญชี Google

กรณีการใช้งาน

เหตุผลบางประการในการใช้การลิงก์บัญชี Google มีดังนี้

• แชร์ข้อมูลของผู้ใช้จากแพลตฟอร์มของคุณกับแอปและบริการของ Google

• เล่นเนื้อหาวิดีโอและภาพยนตร์โดยใช้ Google TV

• จัดการและควบคุมอุปกรณ์ที่เชื่อมต่อกับ Google Smart Home โดยใช้แอป Google Home และ Google Assistant โดยพูดว่า "Ok Google เปิดไฟ"

• สร้างประสบการณ์การใช้งานและฟังก์ชันการทำงานของ Google Assistant ที่ผู้ใช้กำหนดเองด้วยการดำเนินการแบบการสนทนา เช่น "Ok Google สั่งกาแฟจาก Starbucks แบบเดิมให้ฉันหน่อย"

• อนุญาตให้ผู้ใช้รับรางวัลด้วยการดูสตรีมแบบสดที่มีสิทธิ์บน YouTube หลังจากที่ลิงก์บัญชี Google กับบัญชีพาร์ทเนอร์ด้านรางวัล

• ป้อนข้อมูลใหม่ล่วงหน้าในบัญชีระหว่างการลงชื่อสมัครใช้ด้วยข้อมูลที่แชร์โดยได้รับความยินยอมจากโปรไฟล์บัญชี Google

ฟีเจอร์ที่รองรับ

การลิงก์บัญชี Google รองรับฟีเจอร์ต่อไปนี้

• แชร์ข้อมูลได้อย่างรวดเร็วและง่ายดายโดยใช้ขั้นตอนการลิงก์ OAuth โดยนัย

• เพิ่มความปลอดภัยด้วยโฟลว์รหัสการให้สิทธิ์การลิงก์ OAuth

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

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

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

• คุณเพิกถอนสิทธิ์เข้าถึงข้อมูลและบริการที่โฮสต์บนแพลตฟอร์มได้โดยยกเลิกการลิงก์บัญชี การใช้ปลายทางการเพิกถอนโทเค็นที่ไม่บังคับจะช่วยให้คุณซิงค์กับเหตุการณ์ที่ Google เริ่มต้นได้ ส่วนการป้องกันข้ามบัญชี (RISC) ช่วยให้คุณแจ้ง Google เกี่ยวกับเหตุการณ์การยกเลิกการลิงก์ที่เกิดขึ้นบนแพลตฟอร์มได้

ขั้นตอนการลิงก์บัญชี

ขั้นตอนการลิงก์บัญชี Google มี 3 ขั้นตอน ซึ่งทั้งหมดอิงตาม OAuth และกำหนดให้คุณต้องจัดการหรือควบคุมปลายทางการให้สิทธิ์และการแลกเปลี่ยนโทเค็นที่เป็นไปตามข้อกำหนด OAuth 2.0

ในระหว่างกระบวนการลิงก์ คุณจะออกโทเค็นการเข้าถึงให้กับ Google สําหรับบัญชี Google แต่ละบัญชีหลังจากที่ได้รับความยินยอมจากผู้ถือบัญชีให้ลิงก์บัญชีและแชร์ข้อมูล

การลิงก์ OAuth ("Web OAuth")

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

การลิงก์ OAuth รองรับรหัสการให้สิทธิ์และโฟลว์ OAuth โดยนัย บริการต้องโฮสต์ปลายทางการให้สิทธิ์ที่เป็นไปตาม OAuth 2.0 สำหรับโฟลว์แบบไม่เจาะจงปลายทาง และต้องแสดงทั้งปลายทางการให้สิทธิ์และโทเค็นการแลกเปลี่ยนเมื่อใช้โฟลว์รหัสการให้สิทธิ์

รูปที่ 1 การลิงก์บัญชีในโทรศัพท์ของผู้ใช้ด้วย OAuth สำหรับเว็บ

การลิงก์ App Flip ("App Flip") ที่ใช้ OAuth

ขั้นตอน OAuth ที่ส่งผู้ใช้ไปยังแอปเพื่อลิงก์

การลิงก์ App Flip ที่ใช้ OAuth แนะนำผู้ใช้ขณะที่ย้ายไปมาระหว่างแอปบนอุปกรณ์เคลื่อนที่ Android หรือ iOS ที่ยืนยันแล้วกับแพลตฟอร์มของ Google เพื่อตรวจสอบการเปลี่ยนแปลงการเข้าถึงข้อมูลที่เสนอและให้ความยินยอมในการลิงก์บัญชีในแพลตฟอร์มกับบัญชี Google หากต้องการเปิดใช้ฟีเจอร์ App Flip บริการของคุณต้องรองรับการลิงก์ OAuth หรือการลิงก์ Google Sign-In ตาม OAuth โดยใช้ขั้นตอนรหัสการให้สิทธิ์

การพลิกแอปใช้ได้ทั้งใน Android และ iOS

วิธีการทํางาน:

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

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

รูปที่ 2 การลิงก์บัญชีในโทรศัพท์ของผู้ใช้ด้วยฟีเจอร์ App Flip

การลิงก์ที่ปรับปรุงใหม่โดยใช้ OAuth ("ปรับปรุงแล้ว")

การลิงก์ที่มีประสิทธิภาพมากขึ้นของ Google Sign-In ที่ใช้ OAuth จะเพิ่ม Google Sign-In ไว้ด้านบนของการลิงก์ OAuth ซึ่งช่วยให้ผู้ใช้ลิงก์กระบวนการลิงก์ให้เสร็จสมบูรณ์ได้โดยไม่ต้องออกจากแพลตฟอร์ม Google จึงช่วยลดความยุ่งยากและอัตราการหยุดกลางคัน การลิงก์ที่มีประสิทธิภาพยิ่งขึ้นตาม OAuth มอบประสบการณ์การใช้งานที่ดีที่สุดแก่ผู้ใช้ด้วยการลงชื่อเข้าใช้ การสร้างบัญชี และการลิงก์บัญชีอย่างราบรื่น โดยรวม Google Sign-In เข้ากับการลิงก์ OAuth บริการของคุณต้องรองรับปลายทางการให้สิทธิ์และการแลกเปลี่ยนโทเค็นที่เป็นไปตาม OAuth 2.0 นอกจากนี้ปลายทางการแลกเปลี่ยนโทเค็นต้องรองรับการยืนยัน JSON Web Token (JWT) และใช้ความตั้งใจ check create และ get

วิธีการทํางาน:

Google จะยืนยันบัญชีผู้ใช้และส่งข้อมูลนี้ให้คุณ

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

รูปที่ 3 การลิงก์บัญชีในโทรศัพท์ของผู้ใช้ด้วยการลิงก์แบบมีประสิทธิภาพ

คุณควรใช้ขั้นตอนใด

เราขอแนะนำให้ใช้ขั้นตอนทั้งหมดเพื่อให้ผู้ใช้ได้รับประสบการณ์การลิงก์ที่ดีที่สุด ขั้นตอนการลิงก์ที่มีประสิทธิภาพมากขึ้นและการเปลี่ยนแอปช่วยลดความยุ่งยากในการลิงก์ เนื่องจากผู้ใช้สามารถดำเนินการลิงก์ให้เสร็จสมบูรณ์ได้ในไม่กี่ขั้นตอน การลิงก์ 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:

    1. Increase token lifetime to greater than maintenance period.
    2. Wait twice the duration of your access token lifetime, enabling users to exchange short lived tokens for longer duration tokens.
    3. Enter maintenance.
    4. Respond to token requests with a 503 error code and empty body.
    5. Exit maintenance.
    6. Decrease token lifetime back to normal.

การลงทะเบียนกับ Google

เราต้องการรายละเอียดการตั้งค่า OAuth 2.0 และต้องการแชร์ข้อมูลเข้าสู่ระบบเพื่อเปิดใช้การลิงก์บัญชี ดูรายละเอียดได้ที่การลงทะเบียน