การลิงก์บัญชี Google กับ OAuth

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

In the implicit flow, Google opens your authorization endpoint in the user's browser. After successful sign in, you return a long-lived access token to Google. This access token is now included in every request sent from Google.

In the authorization code flow, you need two endpoints:

• The authorization endpoint, which presents the sign-in UI to your users that aren't already signed in. The authorization endpoint also creates a short-lived authorization code to record users' consent to the requested access.

• The token exchange endpoint, which is responsible for two types of exchanges:

  1. Exchanges an authorization code for a long-lived refresh token and a short-lived access token. This exchange happens when the user goes through the account linking flow.
  2. Exchanges a long-lived refresh token for a short-lived access token. This exchange happens when Google needs a new access token because the one it had expired.

Choose an OAuth 2.0 flow

Although the implicit flow is simpler to implement, Google recommends that access tokens issued by the implicit flow never expire. This is because the user is forced to link their account again after a token expires with the implicit flow. If you need token expiration for security reasons, we strongly recommend that you use the authorization code flow instead.

Note: Use the following buttons to choose which OAuth 2.0 flow you want to implement. If needed, the content of this guide will reload to match your choice.

Implicit flow Authorization code

Design guidelines

This section describes the design requirements and recommendations for the user screen that you host for OAuth linking flows. After it's called by Google's app, your platform displays a sign in to Google page and account linking consent screen to the user. The user is directed back to Google's app after giving their consent to link accounts.

Figure 1. Account linking user sign in to Google and consent screens.

Requirements

1. You must communicate that the user’s account will be linked to Google, not a specific Google product like Google Home or Google Assistant.

Recommendations

We recommend that you do the following:

1. Display Google's Privacy Policy. Include a link to Google’s Privacy Policy on the consent screen.

2. Data to be shared. Use clear and concise language to tell the user what data of theirs Google requires and why.

3. Clear call-to-action. State a clear call-to-action on your consent screen, such as “Agree and link.” This is because users need to understand what data they're required to share with Google to link their accounts.

4. Ability to cancel. Provide a way for users to go back or cancel, if they choose not to link.

5. Clear sign-in process. Ensure that users have clear method for signing in to their Google account, such as fields for their username and password or Sign in with Google.

6. Ability to unlink. Offer a mechanism for users to unlink, such as a URL to their account settings on your platform. Alternatively, you can include a link to Google Account where users can manage their linked account.

7. Ability to change user account. Suggest a method for users to switch their account(s). This is especially beneficial if users tend to have multiple accounts.

   • If a user must close the consent screen to switch accounts, send a recoverable error to Google so the user can sign in to the desired account with OAuth linking and the implicit flow.

8. Include your logo. Display your company logo on the consent screen. Use your style guidelines to place your logo. If you wish to also display Google's logo, see Logos and trademarks.

Figure 2. Design guidelines for user sign in to Google and consent screens.

สร้างโปรเจ็กต์

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

วิธีสร้างโปรเจ็กต์เพื่อใช้การลิงก์บัญชี

2. คลิกสร้างโปรเจ็กต์
3. ป้อนชื่อหรือยอมรับคำแนะนำที่สร้างขึ้น
4. ยืนยันหรือแก้ไขช่องที่เหลือ
5. คลิกสร้าง

วิธีดูรหัสโปรเจ็กต์

2. ค้นหาโปรเจ็กต์ในตารางในหน้า Landing Page รหัสโปรเจ็กต์จะปรากฏในคอลัมน์รหัส

กำหนดค่าหน้าจอขอความยินยอม OAuth

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

1. เปิดหน้าหน้าจอขอความยินยอม OAuth ของคอนโซล Google APIs
2. หากได้รับข้อความแจ้ง ให้เลือกโปรเจ็กต์ที่คุณเพิ่งสร้าง

3. ในหน้า "หน้าจอคำยินยอม OAuth" ให้กรอกแบบฟอร์มแล้วคลิกปุ่ม "บันทึก"

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

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

   อีเมลสนับสนุน: เพื่อให้ผู้ใช้ติดต่อคุณพร้อมคำถามเกี่ยวกับการยินยอม

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

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

   ลิงก์หน้าแรกของแอปพลิเคชัน: หน้าแรกของแอปพลิเคชัน ต้องโฮสต์ในโดเมนที่ได้รับอนุญาต

   ลิงก์นโยบายความเป็นส่วนตัวของแอปพลิเคชัน: แสดงในหน้าจอขอความยินยอมในการลิงก์บัญชี Google ต้องโฮสต์ในโดเมนที่ได้รับอนุญาต

   ลิงก์ข้อกำหนดในการให้บริการของแอปพลิเคชัน (ไม่บังคับ): ต้องโฮสต์ในโดเมนที่ได้รับอนุญาต

   

   รูปที่ 1 หน้าจอขอความยินยอมในการลิงก์บัญชี Google สำหรับแอปพลิเคชันสมมติ Tunery

4. ตรวจสอบ "สถานะการยืนยัน" หากแอปพลิเคชันของคุณต้องได้รับการยืนยัน ให้คลิกปุ่ม "ส่งเพื่อรับการยืนยัน" เพื่อส่งแอปพลิเคชันเพื่อรับการยืนยัน ดูรายละเอียดได้ที่ข้อกำหนดในการยืนยัน OAuth

ใช้เซิร์ฟเวอร์ OAuth

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

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

เซสชันโฟลว์รหัสการให้สิทธิ์ OAuth 2.0 ที่เริ่มต้นโดย Google จะมีส่วน ขั้นตอนดังต่อไปนี้

1. Google จะเปิดปลายทางการให้สิทธิ์ในเบราว์เซอร์ของผู้ใช้ หากขั้นตอน ซึ่งเริ่มต้นในอุปกรณ์ที่มีแต่เสียงสำหรับการดำเนินการ Google จะโอน กับโทรศัพท์
2. ผู้ใช้ลงชื่อเข้าใช้หากยังไม่ได้ลงชื่อเข้าใช้ และให้สิทธิ์ Google ในการ เข้าถึงข้อมูลของตนด้วย API ของคุณได้ หากผู้ใช้ยังไม่ได้ให้สิทธิ์
3. บริการจะสร้างรหัสการให้สิทธิ์และส่งคืนให้ Google สิ่งต้องทำ ดังนั้น ให้เปลี่ยนเส้นทางเบราว์เซอร์ของผู้ใช้กลับไปที่ Google ด้วยรหัสการให้สิทธิ์ ที่แนบมากับคำขอ
4. Google จะส่งรหัสการให้สิทธิ์ไปยังปลายทางการแลกเปลี่ยนโทเค็น จะตรวจสอบความถูกต้องของโค้ดและส่งกลับโทเค็นเพื่อการเข้าถึงและ โทเค็นการรีเฟรช โทเค็นเพื่อการเข้าถึงเป็นโทเค็นที่มีอายุใช้งานสั้นที่บริการของคุณ ยอมรับเป็นข้อมูลรับรองเพื่อเข้าถึง API โทเค็นการรีเฟรชมีอายุการใช้งานที่ยาวนาน ที่ Google สามารถจัดเก็บและใช้เพื่อรับโทเค็นเพื่อการเข้าถึงใหม่ หมดอายุ
5. หลังจากที่ผู้ใช้ทำการลิงก์บัญชีเสร็จแล้ว ทุกครั้ง คำขอที่ส่งจาก Google มีโทเค็นเพื่อการเข้าถึง

จัดการคำขอการให้สิทธิ์

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

พารามิเตอร์ปลายทางการให้สิทธิ์
client_id	รหัสไคลเอ็นต์ที่คุณกำหนดให้กับ Google
redirect_uri	URL ที่คุณส่งการตอบกลับคำขอนี้
state	มูลค่าการทำบัญชีที่ส่งกลับไปยัง Google ไม่เปลี่ยนแปลงใน URI การเปลี่ยนเส้นทาง
scope	ไม่บังคับ: ชุดสตริงขอบเขตที่คั่นด้วยช่องว่างซึ่งระบุค่า ข้อมูลที่ Google กำลังขออนุญาต
response_type	ประเภทของค่าที่จะแสดงในคำตอบ สำหรับ OAuth 2.0 โฟลว์รหัสการให้สิทธิ์ ประเภทการตอบกลับจะเป็น code เสมอ
user_locale	การตั้งค่าภาษาของบัญชี Google ใน RFC5646 รูปแบบ ใช้เพื่อแปลเนื้อหาของคุณเป็นภาษาที่ผู้ใช้ต้องการ

ตัวอย่างเช่น หากปลายทางการให้สิทธิ์อยู่ที่ https://myservice.example.com/auth คำขออาจมีลักษณะดังต่อไปนี้

GET https://myservice.example.com/auth?client_id=GOOGLE_CLIENT_ID&redirect_uri=REDIRECT_URI&state=STATE_STRING&scope=REQUESTED_SCOPES&response_type=code&user_locale=LOCALE

สำหรับปลายทางการให้สิทธิ์ในการจัดการคำขอลงชื่อเข้าใช้ ให้ทำดังนี้ ขั้นตอน:

1. ยืนยันว่า client_id ตรงกับรหัสไคลเอ็นต์ที่คุณกำหนดให้กับ Google และ redirect_uri ตรงกับ URL การเปลี่ยนเส้นทางที่ Google ให้ไว้สำหรับบริการของคุณ การตรวจสอบเหล่านี้มีความสําคัญอย่างยิ่งในการป้องกันไม่ให้ สิทธิ์เข้าถึงแอปไคลเอ็นต์ที่ไม่ได้ตั้งใจหรือกำหนดค่าไม่ถูกต้อง หากคุณรองรับ ขั้นตอน OAuth 2.0 ให้ยืนยันว่า response_type คือ code
2. ตรวจสอบว่าผู้ใช้ลงชื่อเข้าใช้บริการของคุณหรือไม่ หากผู้ใช้ไม่ได้ลงชื่อเข้าใช้ ดำเนินการตามขั้นตอนการลงชื่อเข้าใช้หรือลงชื่อสมัครใช้บริการให้เสร็จสิ้น
3. สร้างรหัสการให้สิทธิ์เพื่อให้ Google ใช้ในการเข้าถึง API ของคุณ รหัสการให้สิทธิ์จะเป็นค่าสตริงใดก็ได้ แต่ต้องไม่ซ้ำกัน แสดงผู้ใช้ ไคลเอ็นต์ที่ใช้โทเค็น และวันหมดอายุของรหัส และไม่ควรคาดเดาได้ โดยปกติแล้วคุณจะออกการให้สิทธิ์ ซึ่งจะหมดอายุหลังจากผ่านไปประมาณ 10 นาที
4. ยืนยันว่า URL ที่ระบุโดยพารามิเตอร์ redirect_uri มี แบบฟอร์มต่อไปนี้:

     https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID
     https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
     

5. เปลี่ยนเส้นทางเบราว์เซอร์ของผู้ใช้ไปยัง URL ที่ระบุโดย พารามิเตอร์ redirect_uri ระบุรหัสการให้สิทธิ์ที่คุณ เพิ่งสร้าง และค่าสถานะเดิมที่ไม่มีการแก้ไขเมื่อคุณเปลี่ยนเส้นทาง ด้วยการเพิ่มพารามิเตอร์ code และ state ต่อท้าย ต่อไปนี้เป็น ตัวอย่างของ URL ผลลัพธ์:

   https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID?code=AUTHORIZATION_CODE&state=STATE_STRING

จัดการคำขอแลกเปลี่ยนโทเค็น

ปลายทางการแลกเปลี่ยนโทเค็นของบริการมีโทเค็น 2 ประเภท การแลกเปลี่ยน:

• แลกเปลี่ยนรหัสการให้สิทธิ์สำหรับโทเค็นเพื่อการเข้าถึงและโทเค็นการรีเฟรช
• แลกเปลี่ยนโทเค็นการรีเฟรชสำหรับโทเค็นเพื่อการเข้าถึง

คำขอแลกเปลี่ยนโทเค็นมีพารามิเตอร์ต่อไปนี้

พารามิเตอร์ปลายทางของการแลกเปลี่ยนโทเค็น
client_id	สตริงที่ระบุต้นทางของคำขอเป็น Google สตริงนี้ต้อง ได้รับการลงทะเบียนในระบบของคุณเป็นตัวระบุที่ไม่ซ้ำกันของ Google
client_secret	สตริงลับที่คุณลงทะเบียนกับ Google สําหรับบริการของคุณ
grant_type	ประเภทของโทเค็นที่แลกเปลี่ยน สามารถทำได้ authorization_code หรือ refresh_token
code	เมื่อ grant_type=authorization_code พารามิเตอร์นี้คือช่วง รหัสที่ Google ได้รับจากการลงชื่อเข้าใช้หรือการแลกเปลี่ยนโทเค็นของคุณ ปลายทาง
redirect_uri	เมื่อ grant_type=authorization_code พารามิเตอร์นี้คือช่วง URL ที่ใช้ในคำขอการให้สิทธิ์เริ่มต้น
refresh_token	เมื่อ grant_type=refresh_token พารามิเตอร์นี้คือช่วง รีเฟรชโทเค็นที่ Google ได้รับจากปลายทางการแลกเปลี่ยนโทเค็นของคุณ

แลกเปลี่ยนรหัสการให้สิทธิ์สำหรับโทเค็นเพื่อการเข้าถึงและโทเค็นการรีเฟรช

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

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

POST /token HTTP/1.1
Host: oauth2.example.com
Content-Type: application/x-www-form-urlencoded

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=REDIRECT_URI

หากต้องการแลกเปลี่ยนรหัสการให้สิทธิ์กับโทเค็นเพื่อการเข้าถึงและโทเค็นการรีเฟรช ปลายทางการแลกเปลี่ยนโทเค็นจะตอบสนองต่อคำขอ POST โดยเรียกใช้คำสั่งต่อไปนี้ ขั้นตอน:

1. ยืนยันว่า client_id ระบุว่าต้นทางของคำขอได้รับอนุญาต ต้นทาง และ client_secret ตรงกับค่าที่คาดไว้
2. ตรวจสอบว่ารหัสการให้สิทธิ์ถูกต้องและไม่หมดอายุ รหัสไคลเอ็นต์ที่ระบุในคำขอตรงกับรหัสไคลเอ็นต์ที่เชื่อมโยงกับ รหัสการให้สิทธิ์ของคุณ
3. ยืนยันว่า URL ที่ระบุโดยพารามิเตอร์ redirect_uri เหมือนกัน กับค่าที่ใช้ในคำขอการให้สิทธิ์เริ่มต้น
4. หากยืนยันเกณฑ์ข้างต้นได้ทั้งหมด ให้แสดงผล HTTP 400 ข้อผิดพลาด "คำขอไม่ถูกต้อง" ที่มี {"error": "invalid_grant"} เป็นเนื้อความ
5. หรือใช้รหัสผู้ใช้จากรหัสการให้สิทธิ์เพื่อสร้างการรีเฟรช และโทเค็นเพื่อการเข้าถึง โทเค็นเหล่านี้จะเป็นค่าสตริงใดก็ได้ ต้องแสดงถึงผู้ใช้และไคลเอ็นต์ที่ใช้โทเค็นโดยไม่ซ้ำกัน และ ต้องไม่คาดเดา สำหรับโทเค็นเพื่อการเข้าถึง ให้บันทึกเวลาหมดอายุของ โทเค็น ซึ่งโดยปกติแล้วจะอยู่ที่ 1 ชั่วโมงหลังจากที่คุณออกโทเค็น โทเค็นการรีเฟรชไม่มีวันหมดอายุ
6. แสดงผลออบเจ็กต์ JSON ต่อไปนี้ในส่วนเนื้อหาของการตอบกลับ HTTPS

   {
   "token_type": "Bearer",
   "access_token": "ACCESS_TOKEN",
   "refresh_token": "REFRESH_TOKEN",
   "expires_in": SECONDS_TO_EXPIRATION
   }

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

แลกเปลี่ยนโทเค็นการรีเฟรชสำหรับโทเค็นเพื่อการเข้าถึง

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

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

POST /token HTTP/1.1
Host: oauth2.example.com
Content-Type: application/x-www-form-urlencoded

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=refresh_token&refresh_token=REFRESH_TOKEN

หากต้องการแลกเปลี่ยนโทเค็นการรีเฟรชกับโทเค็นเพื่อการเข้าถึง ให้กำหนดปลายทางการแลกเปลี่ยนโทเค็น ตอบสนองคำขอ POST โดยดำเนินการตามขั้นตอนต่อไปนี้

1. ตรวจสอบว่า client_id ระบุที่มาของคำขอเป็น Google และ ว่า client_secret ตรงกับค่าที่คาดไว้
2. ตรวจสอบว่าโทเค็นการรีเฟรชถูกต้อง และรหัสไคลเอ็นต์ที่ระบุใน คำขอตรงกับรหัสไคลเอ็นต์ที่เชื่อมโยงกับโทเค็นการรีเฟรช
3. หากยืนยันเกณฑ์ข้างต้นไม่ได้ทั้งหมด ให้แสดงผล HTTP 400 ข้อผิดพลาดคำขอผิดพลาดที่มี {"error": "invalid_grant"} เป็นส่วนเนื้อหา
4. หรือใช้รหัสผู้ใช้จากโทเค็นการรีเฟรชเพื่อสร้างการเข้าถึง โทเค็น โทเค็นเหล่านี้จะเป็นค่าสตริงใดก็ได้ แต่ต้องไม่ซ้ำ เป็นตัวแทนของผู้ใช้และไคลเอ็นต์ที่ใช้โทเค็น และจะต้องไม่ คาดเดาได้ สำหรับโทเค็นเพื่อการเข้าถึง ให้บันทึกเวลาหมดอายุของโทเค็นด้วย ซึ่งโดยทั่วไปจะใช้เวลา 1 ชั่วโมงหลังจากที่คุณออกโทเค็น
5. แสดงผลออบเจ็กต์ JSON ต่อไปนี้ในส่วนเนื้อหาของ HTTPS การตอบกลับ:

   {
   "token_type": "Bearer",
   "access_token": "ACCESS_TOKEN",
   "expires_in": SECONDS_TO_EXPIRATION
   }

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

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:

1. Extract access token from the Authorization header and return information for the user associated with the access token.
2. If the access token is invalid, return an HTTP 401 Unauthorized error with using the WWW-Authenticate Response Header. Below is an example of a userinfo error response:

   HTTP/1.1 401 Unauthorized
   WWW-Authenticate: error="invalid_token",
   error_description="The Access Token expired"
   

   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.

3. If the access token is valid, return and HTTP 200 response with the following JSON object in the body of the HTTPS response:

   {
   "sub": "USER_UUID",
   "email": "EMAIL_ADDRESS",
   "given_name": "FIRST_NAME",
   "family_name": "LAST_NAME",
   "name": "FULL_NAME",
   "picture": "PROFILE_PICTURE",
   }

   If your userinfo endpoint returns an HTTP 200 success response, the retrieved token and claims are registered against the user's Google account.

   userinfo endpoint response
   sub	A unique ID that identifies the user in your system.
   email	Email address of the user.
   given_name	Optional: First name of the user.
   family_name	Optional: Last name of the user.
   name	Optional: Full name of the user.
   picture	Optional: Profile picture of the user.

ตรวจสอบการติดตั้งใช้งาน

คุณตรวจสอบการติดตั้งใช้งานได้โดยใช้เครื่องมือ OAuth 2.0 Playground

ทำตามขั้นตอนต่อไปนี้ในเครื่องมือ

1. คลิกการกําหนดค่า เพื่อเปิดหน้าต่างการกําหนดค่า OAuth 2.0
2. ในช่องขั้นตอน OAuth ให้เลือกฝั่งไคลเอ็นต์
3. ในช่อง OAuth Endpoints ให้เลือก Custom
4. ระบุปลายทาง OAuth 2.0 และรหัสไคลเอ็นต์ที่คุณกำหนดให้กับ Google ในช่องที่เกี่ยวข้อง
5. ในส่วนขั้นตอนที่ 1 ไม่ต้องเลือกขอบเขตของ Google แต่ให้เว้นช่องนี้ว่างไว้หรือพิมพ์ขอบเขตที่ใช้ได้กับเซิร์ฟเวอร์ของคุณ (หรือสตริงที่กำหนดเองหากคุณไม่ได้ใช้ขอบเขต OAuth) เมื่อดำเนินการเสร็จแล้ว ให้คลิกให้สิทธิ์ API
6. ในส่วนขั้นตอนที่ 2 และขั้นตอนที่ 3 ให้ทำตามขั้นตอน OAuth 2.0 และตรวจสอบว่าแต่ละขั้นตอนทำงานตามที่ต้องการ

คุณสามารถตรวจสอบการติดตั้งใช้งานโดยใช้เครื่องมือการสาธิตการลิงก์บัญชี Google

ทำตามขั้นตอนต่อไปนี้ในเครื่องมือ

1. คลิกปุ่มลงชื่อเข้าใช้ด้วย Google
2. เลือกบัญชีที่ต้องการลิงก์
3. ป้อนรหัสบริการ
4. (ไม่บังคับ) ป้อนขอบเขตที่จะขอสิทธิ์เข้าถึงอย่างน้อย 1 รายการ
5. คลิกเริ่มสาธิต
6. เมื่อได้รับข้อความแจ้ง ให้ยืนยันว่าคุณอาจยินยอมและปฏิเสธคำขอลิงก์
7. ยืนยันว่าระบบเปลี่ยนเส้นทางคุณไปยังแพลตฟอร์ม