หน้านี้ได้รับการแปลโดย Cloud Translation API

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

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

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

ในกระบวนการรหัสการให้สิทธิ์ คุณต้องมีปลายทาง 2 จุด ได้แก่

ปลายทางการให้สิทธิ์ซึ่งจะแสดง UI การลงชื่อเข้าใช้แก่ผู้ใช้ที่ไม่ได้ลงชื่อเข้าใช้ ปลายทางการให้สิทธิ์จะสร้างรหัสการให้สิทธิ์ที่ใช้งานได้ชั่วคราวเพื่อบันทึกผู้ใช้&#39 และให้ความยินยอมแก่การเข้าถึงที่ขอ
ปลายทาง token Exchange ซึ่งรับผิดชอบ Exchange 2 ประเภทดังนี้
1. แลกเปลี่ยนรหัสการให้สิทธิ์สําหรับโทเค็นการรีเฟรชเป็นระยะเวลานานและโทเค็นเพื่อการเข้าถึงที่ใช้งานได้เป็นระยะเวลาสั้นๆ ซึ่ง Exchange นี้จะเกิดขึ้นเมื่อผู้ใช้ทําตามขั้นตอนการลิงก์บัญชี
2. แลกเปลี่ยนโทเค็นการรีเฟรชเป็นระยะเวลานานสําหรับโทเค็นเพื่อการเข้าถึงเป็นระยะเวลาสั้นๆ Exchange นี้จะเกิดขึ้นเมื่อ Google ต้องการโทเค็นเพื่อการเข้าถึงใหม่เนื่องจากโทเค็นหมดอายุ

เลือกขั้นตอน OAuth 2.0

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

หลักเกณฑ์การออกแบบ

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

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

ข้อกำหนด

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

คำแนะนำ

เราขอแนะนําให้คุณทําสิ่งต่อไปนี้

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

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

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

Go to the Google API Console.
คลิก สร้างโครงการ
ป้อนชื่อหรือยอมรับคำแนะนำที่สร้างขึ้น
ยืนยันหรือแก้ไขฟิลด์ที่เหลือ
คลิก สร้าง

วิธีดูรหัสโครงการของคุณ:

Go to the Google API Console.
ค้นหาโครงการของคุณในตารางบนหน้า Landing Page รหัสโครงการจะปรากฏในคอลัมน์ ID

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ยืนยันว่า client_id ตรงกับรหัสไคลเอ็นต์ที่คุณกำหนดให้กับ Google และ redirect_uri ตรงกับ URL การเปลี่ยนเส้นทางที่ Google ให้ไว้สำหรับบริการของคุณ การตรวจสอบเหล่านี้มีความสําคัญอย่างยิ่งในการป้องกันไม่ให้ สิทธิ์เข้าถึงแอปไคลเอ็นต์ที่ไม่ได้ตั้งใจหรือกำหนดค่าไม่ถูกต้อง หากคุณรองรับ ขั้นตอน OAuth 2.0 ให้ยืนยันว่า response_type คือ code
ตรวจสอบว่าผู้ใช้ลงชื่อเข้าใช้บริการของคุณหรือไม่ หากผู้ใช้ไม่ได้ลงชื่อเข้าใช้ ดำเนินการตามขั้นตอนการลงชื่อเข้าใช้หรือลงชื่อสมัครใช้บริการให้เสร็จสิ้น
สร้างรหัสการให้สิทธิ์เพื่อให้ Google ใช้ในการเข้าถึง API ของคุณ รหัสการให้สิทธิ์จะเป็นค่าสตริงใดก็ได้ แต่ต้องไม่ซ้ำกัน แสดงผู้ใช้ ไคลเอ็นต์ที่ใช้โทเค็น และวันหมดอายุของรหัส และไม่ควรคาดเดาได้ โดยปกติแล้วคุณจะออกการให้สิทธิ์ ซึ่งจะหมดอายุหลังจากผ่านไปประมาณ 10 นาที
ยืนยันว่า URL ที่ระบุโดยพารามิเตอร์ redirect_uri มี แบบฟอร์มต่อไปนี้:
```
  https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID
  https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
  
```
เปลี่ยนเส้นทางเบราว์เซอร์ของผู้ใช้ไปยัง 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 โดยเรียกใช้คำสั่งต่อไปนี้ ขั้นตอน:

ยืนยันว่า client_id ระบุว่าต้นทางของคำขอได้รับอนุญาต ต้นทาง และ client_secret ตรงกับค่าที่คาดไว้
ตรวจสอบว่ารหัสการให้สิทธิ์ถูกต้องและไม่หมดอายุ รหัสไคลเอ็นต์ที่ระบุในคำขอตรงกับรหัสไคลเอ็นต์ที่เชื่อมโยงกับ รหัสการให้สิทธิ์ของคุณ
ยืนยันว่า URL ที่ระบุโดยพารามิเตอร์ redirect_uri เหมือนกัน กับค่าที่ใช้ในคำขอการให้สิทธิ์เริ่มต้น
หากยืนยันเกณฑ์ข้างต้นได้ทั้งหมด ให้แสดงผล HTTP 400 ข้อผิดพลาด "คำขอไม่ถูกต้อง" ที่มี {"error": "invalid_grant"} เป็นเนื้อความ
หรือใช้รหัสผู้ใช้จากรหัสการให้สิทธิ์เพื่อสร้างการรีเฟรช และโทเค็นเพื่อการเข้าถึง โทเค็นเหล่านี้จะเป็นค่าสตริงใดก็ได้ ต้องแสดงถึงผู้ใช้และไคลเอ็นต์ที่ใช้โทเค็นโดยไม่ซ้ำกัน และ ต้องไม่คาดเดา สำหรับโทเค็นเพื่อการเข้าถึง ให้บันทึกเวลาหมดอายุของ โทเค็น ซึ่งโดยปกติแล้วจะอยู่ที่ 1 ชั่วโมงหลังจากที่คุณออกโทเค็น โทเค็นการรีเฟรชไม่มีวันหมดอายุ
แสดงผลออบเจ็กต์ 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 โดยดำเนินการตามขั้นตอนต่อไปนี้

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

จัดการคำขอ Userinfo

ปลายทาง userinfo เป็นทรัพยากรที่มีการป้องกันด้วย OAuth 2.0 ซึ่งส่งกลับการอ้างสิทธิ์เกี่ยวกับผู้ใช้ที่ลิงก์ การติดตั้งใช้งานและการโฮสต์ปลายทาง userinfo เป็นตัวเลือกที่ไม่บังคับ ยกเว้นกรณีการใช้งานต่อไปนี้

ลงชื่อเข้าใช้บัญชีที่ลิงก์ด้วย Google One Tap
การติดตามที่ราบรื่นบน AndroidTV

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

ส่วนหัวของคำขอปลายทางของ userinfo
`Authorization header`	โทเค็นเพื่อการเข้าถึงของประเภท Bearer

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

GET /userinfo HTTP/1.1
Host: myservice.example.com
Authorization: Bearer ACCESS_TOKEN

หากต้องการให้ปลายทาง userinfo จัดการคำขอ ให้ทำตามขั้นตอนต่อไปนี้

แยกโทเค็นเพื่อการเข้าถึงจากส่วนหัวการให้สิทธิ์ แล้วแสดงผลข้อมูลสำหรับผู้ใช้ที่เชื่อมโยงกับโทเค็นเพื่อการเข้าถึง
หากโทเค็นเพื่อการเข้าถึงไม่ถูกต้อง ให้แสดงข้อผิดพลาด HTTP 401 Unauthorized ด้วยการใช้ส่วนหัวการตอบกลับ WWW-Authenticate ตัวอย่างการตอบกลับข้อผิดพลาดเกี่ยวกับ Userinfo มีดังนี้
```
HTTP/1.1 401 Unauthorized
WWW-Authenticate: error="invalid_token",
error_description="The Access Token expired"
```
หากข้อผิดพลาด 401 Unauthorized หรือการตอบกลับที่ผิดพลาดอื่นๆ ที่ไม่สำเร็จในระหว่างกระบวนการลิงก์ ข้อผิดพลาดดังกล่าวจะกู้คืนไม่ได้ ระบบจะทิ้งโทเค็นที่ดึงมาและผู้ใช้จะต้องเริ่มกระบวนการลิงก์อีกครั้ง

หากโทเค็นเพื่อการเข้าถึงถูกต้อง ให้แสดงผลและการตอบสนอง HTTP 200 ด้วยออบเจ็กต์ JSON ต่อไปนี้ในเนื้อหาของ HTTPS การตอบกลับ:

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

หากปลายทาง userinfo ส่งการตอบกลับที่สำเร็จ HTTP 200 ระบบจะลงทะเบียนโทเค็นที่ดึงมาและการอ้างสิทธิ์กับบัญชี Google ของผู้ใช้

การตอบสนองของปลายทาง userinfo
`sub`	รหัสที่ไม่ซ้ำกันที่ระบุผู้ใช้ในระบบ
`email`	อีเมลของผู้ใช้
`given_name`	ไม่บังคับ: ชื่อของผู้ใช้
`family_name`	ไม่บังคับ: นามสกุลของผู้ใช้
`name`	ไม่บังคับ: ชื่อเต็มของผู้ใช้
`picture`	ไม่บังคับ: รูปโปรไฟล์ของผู้ใช้

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

คุณสามารถตรวจสอบการดำเนินงานของคุณโดยใช้ OAuth 2.0 สนามเด็กเล่น เครื่องมือ

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

คลิกการกำหนดค่า เพื่อเปิดหน้าต่าง OAuth 2.0 การกำหนดค่า
ในด้านการไหล OAuth เลือกฝั่งไคลเอ็นต์
ในฟิลด์ OAuth ปลายทางเลือกที่กำหนดเอง
ระบุตำแหน่งข้อมูล OAuth 2.0 และรหัสไคลเอ็นต์ที่คุณกำหนดให้กับ Google ในช่องที่เกี่ยวข้อง
ในขั้นตอนที่ 1 ส่วนที่ไม่ได้เลือกขอบเขตใด ๆ ของ Google ให้ปล่อยฟิลด์นี้ว่างไว้หรือพิมพ์ขอบเขตที่ถูกต้องสำหรับเซิร์ฟเวอร์ของคุณ (หรือสตริงที่กำหนดเองหากคุณไม่ได้ใช้ขอบเขต OAuth) เมื่อคุณทำเสร็จแล้วคลิกอนุญาต APIs
ในขั้นตอนที่ 2 และขั้นตอนที่ 3 ส่วนไปไหลผ่าน OAuth 2.0 และตรวจสอบว่าแต่ละขั้นตอนการทำงานตามที่ตั้งใจไว้

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

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

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