ภาพรวม

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

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

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

Use Case

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

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

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

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

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

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

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

การลิงก์ OAuth ("OAuth ในเว็บ")

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

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

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

การลิงก์ App Flip ที่ใช้ OAuth ("การสลับแอป")

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

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

App Flip รองรับทั้ง Android และ iOS

วิธีการทำงาน

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

• หากพบแอป ระบบจะ "พลิก" ผู้ใช้มายังแอปของคุณ แอปรวบรวมความยินยอมจากผู้ใช้เพื่อลิงก์บัญชีกับ Google จากนั้น "พลิกกลับ" ไปยังแพลตฟอร์มของ Google
• หากไม่พบแอปหรือเกิดข้อผิดพลาดระหว่างกระบวนการลิงก์แอปแบบพลิก ระบบจะเปลี่ยนเส้นทางผู้ใช้ไปยังขั้นตอน OAuth ที่เพิ่มประสิทธิภาพหรือ 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) และใช้ Intent check, create และ get

วิธีการทำงาน

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

• หากมีบัญชีอยู่แล้วสำหรับผู้ใช้ในฐานข้อมูลของคุณ ผู้ใช้จะลิงก์บัญชี Google ของตนกับบัญชีของผู้ใช้ในบริการของคุณ
• หากไม่มีบัญชีสำหรับผู้ใช้ในฐานข้อมูลของคุณ ผู้ใช้สามารถสร้างบัญชี 3P ใหม่ที่มีข้อมูลที่ยืนยันที่ Google ให้ไว้ ซึ่งได้แก่ อีเมล ชื่อ และรูปโปรไฟล์ หรือเลือกลงชื่อเข้าใช้และลิงก์กับอีเมลอื่น (ซึ่งจะต้องให้ผู้ใช้ลงชื่อเข้าใช้บริการผ่าน 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 และแชร์ข้อมูลเข้าสู่ระบบเพื่อเปิดใช้การลิงก์บัญชี ดูรายละเอียดในการลงทะเบียน