ภาพรวม

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

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

คุณควรใช้โฟลว์ใด

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