ระบบจะลิงก์บัญชีโดยใช้ขั้นตอน OAuth 2.0 แบบโดยนัยและรหัสการให้สิทธิ์ซึ่งเป็นมาตรฐานอุตสาหกรรม บริการของคุณต้องรองรับปลายทางการให้สิทธิ์และการแลกเปลี่ยนโทเค็นที่เป็นไปตาม OAuth 2.0
ในขั้นตอนโดยนัย Google จะเปิดปลายทางการให้สิทธิ์ในเบราว์เซอร์ของผู้ใช้ หลังจากลงชื่อเข้าใช้สำเร็จแล้ว ให้ส่งคืนโทเค็นการเข้าถึงที่มีอายุการใช้งานยาวนานไปยัง Google ตอนนี้โทเค็นการเข้าถึงนี้จะรวมอยู่ในคําขอทุกรายการที่ส่งจาก Google
ในขั้นตอนรหัสการให้สิทธิ์ คุณต้องมีปลายทาง 2 รายการดังนี้
- ปลายทางการให้สิทธิ์ ซึ่งแสดง UI การลงชื่อเข้าใช้ต่อผู้ใช้ที่ยังไม่ได้ลงชื่อเข้าใช้ ปลายทางการให้สิทธิ์จะสร้างรหัสการให้สิทธิ์ที่มีอายุสั้นเพื่อบันทึกความยินยอมของผู้ใช้ในการเข้าถึงที่ขอ 
- ปลายทางการแลกเปลี่ยนโทเค็น ซึ่งรับผิดชอบต่อการแลกเปลี่ยน 2 ประเภทดังนี้ - แลกเปลี่ยนรหัสการให้สิทธิ์เป็นโทเค็นการรีเฟรชที่ใช้ได้นานและโทเค็นเพื่อการเข้าถึงที่ใช้ได้ในระยะสั้น การแลกเปลี่ยนนี้จะเกิดขึ้นเมื่อผู้ใช้ดำเนินการตามขั้นตอนการลิงก์บัญชี
- แลกเปลี่ยนโทเค็นการรีเฟรชที่ใช้ได้นานกับโทเค็นเพื่อการเข้าถึงที่ใช้ได้ในระยะสั้น การแลกเปลี่ยนนี้จะเกิดขึ้นเมื่อ Google ต้องการโทเค็นเพื่อการเข้าถึงใหม่เนื่องจากโทเค็นหมดอายุ
 
เลือกขั้นตอน OAuth 2.0
แม้ว่าการใช้เวิร์กโฟลว์โดยนัยจะง่ายกว่า แต่ Google ขอแนะนำให้ใช้โทเค็นการเข้าถึงที่ออกโดยเวิร์กโฟลว์โดยนัยซึ่งไม่มีวันหมดอายุ เนื่องจากผู้ใช้ต้องลิงก์บัญชีอีกครั้งหลังจากโทเค็นหมดอายุด้วยขั้นตอนที่ชัดเจน หากต้องการกำหนดวันหมดอายุของโทเค็นเพื่อเหตุผลด้านความปลอดภัย เราขอแนะนําอย่างยิ่งให้คุณใช้ขั้นตอนรหัสการให้สิทธิ์แทน
หลักเกณฑ์การออกแบบ
ส่วนนี้จะอธิบายข้อกำหนดและคำแนะนำด้านการออกแบบสำหรับหน้าจอผู้ใช้ที่คุณโฮสต์สำหรับขั้นตอนการลิงก์ OAuth หลังจากที่แอปของ Google เรียกใช้แล้ว แพลตฟอร์มจะแสดงหน้าการลงชื่อเข้าใช้ Google และหน้าจอคำยินยอมการลิงก์บัญชีแก่ผู้ใช้ ระบบจะนําผู้ใช้กลับไปที่แอปของ Google หลังจากที่ผู้ใช้ให้ความยินยอมในการลิงก์บัญชี
 
  ข้อกำหนด
- คุณต้องแจ้งให้ผู้ใช้ทราบว่าบัญชีของผู้ใช้จะลิงก์กับ Googleไม่ใช่ผลิตภัณฑ์ที่เฉพาะเจาะจงของ Google เช่น Google Home หรือ Google Assistant
คำแนะนำ
เราขอแนะนำให้คุณทำดังนี้
- แสดงนโยบายความเป็นส่วนตัวของ Google ใส่ลิงก์ไปยังนโยบายความเป็นส่วนตัวของ Google ในหน้าจอขอความยินยอม 
- ข้อมูลที่แชร์ ใช้ภาษาที่ชัดเจนและกระชับเพื่อบอกให้ผู้ใช้ทราบว่า Google ต้องการข้อมูลใดและเพราะเหตุใด 
- คำกระตุ้นให้ดำเนินการที่ชัดเจน ระบุคำกระตุ้นให้ดำเนินการที่ชัดเจนในหน้าจอคำยินยอม เช่น "ยอมรับและลิงก์" เนื่องจากผู้ใช้ต้องเข้าใจว่าต้องแชร์ข้อมูลใดกับ Google จึงจะลิงก์บัญชีได้ 
- ความสามารถในการยกเลิก ระบุวิธีให้ผู้ใช้ย้อนกลับหรือยกเลิก หากผู้ใช้เลือกที่จะไม่ลิงก์ 
- กระบวนการลงชื่อเข้าใช้ที่ชัดเจน ตรวจสอบว่าผู้ใช้มีวิธีการที่ชัดเจนในการลงชื่อเข้าใช้บัญชี Google เช่น ช่องสำหรับชื่อผู้ใช้และรหัสผ่าน หรือลงชื่อเข้าใช้ด้วย Google 
- ความสามารถในการยกเลิกการลิงก์ เสนอกลไกให้ผู้ใช้ยกเลิกการลิงก์ เช่น URL ไปยังการตั้งค่าบัญชีบนแพลตฟอร์มของคุณ หรือจะใส่ลิงก์ไปยังบัญชี Google ที่ผู้ใช้สามารถจัดการบัญชีที่ลิงก์ไว้ก็ได้ 
- ความสามารถในการเปลี่ยนบัญชีผู้ใช้ แนะนำวิธีการให้ผู้ใช้เปลี่ยนบัญชี ซึ่งจะเป็นประโยชน์อย่างยิ่งหากผู้ใช้มีแนวโน้มที่จะมีบัญชีหลายบัญชี - หากผู้ใช้ต้องปิดหน้าจอขอความยินยอมเพื่อเปลี่ยนบัญชี ให้ส่งข้อผิดพลาดที่แก้ไขได้ไปยัง Google เพื่อให้ผู้ใช้ลงชื่อเข้าใช้บัญชีที่ต้องการได้โดยใช้การลิงก์ OAuth และขั้นตอนโดยนัย
 
- ใส่โลโก้ของคุณ แสดงโลโก้บริษัทในหน้าจอขอความยินยอม ใช้หลักเกณฑ์การจัดรูปแบบในการวางโลโก้ หากต้องการแสดงโลโก้ของ Google ด้วย โปรดดูโลโก้และเครื่องหมายการค้า 
 
  สร้างโปรเจ็กต์
วิธีสร้างโปรเจ็กต์เพื่อใช้การลิงก์บัญชี
- คลิกสร้างโปรเจ็กต์
- ป้อนชื่อหรือยอมรับคำแนะนำที่สร้างขึ้น
- ยืนยันหรือแก้ไขช่องที่เหลือ
- คลิกสร้าง
วิธีดูรหัสโปรเจ็กต์
- ค้นหาโปรเจ็กต์ในตารางในหน้า Landing Page รหัสโปรเจ็กต์จะปรากฏในคอลัมน์รหัส
กำหนดค่าหน้าจอขอความยินยอม OAuth
กระบวนการลิงก์บัญชี Google มีหน้าจอขอความยินยอมซึ่งจะแจ้งให้ผู้ใช้ทราบว่าแอปพลิเคชันใดขอสิทธิ์เข้าถึงข้อมูลของผู้ใช้ ข้อมูลประเภทใดที่แอปพลิเคชันขอ และข้อกำหนดที่เกี่ยวข้อง คุณจะต้องกำหนดค่าหน้าจอคำยินยอม OAuth ก่อนที่จะสร้างรหัสไคลเอ็นต์ Google API
- เปิดหน้าหน้าจอขอความยินยอม OAuth ของคอนโซล Google APIs
- หากได้รับข้อความแจ้ง ให้เลือกโปรเจ็กต์ที่คุณเพิ่งสร้าง
- ในหน้า "หน้าจอคำยินยอม OAuth" ให้กรอกแบบฟอร์มแล้วคลิกปุ่ม "บันทึก" - ชื่อแอปพลิเคชัน: ชื่อของแอปพลิเคชันที่ขอความยินยอม ชื่อควรแสดงถึงแอปพลิเคชันของคุณอย่างถูกต้องและสอดคล้องกับชื่อแอปพลิเคชันที่ผู้ใช้เห็นในที่อื่นๆ ชื่อแอปพลิเคชันจะแสดงในหน้าจอคำยินยอมในการลิงก์บัญชี - โลโก้แอปพลิเคชัน: รูปภาพในหน้าจอคำยินยอมที่จะช่วยให้ผู้ใช้จดจำแอปของคุณได้ ระบบจะแสดงโลโก้ในหน้าจอคำยินยอมในการลิงก์บัญชีและในการตั้งค่าบัญชี - อีเมลสนับสนุน: เพื่อให้ผู้ใช้ติดต่อคุณพร้อมคำถามเกี่ยวกับการยินยอม - ขอบเขตสำหรับ Google API: ขอบเขตช่วยให้แอปพลิเคชันเข้าถึงข้อมูลส่วนตัวของผู้ใช้ใน Google ได้ สำหรับกรณีการใช้งานการลิงก์บัญชี 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" 
- หากโทเค็นเพื่อการเข้าถึงถูกต้อง ให้แสดงผลและการตอบสนอง 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 - sub- รหัสที่ไม่ซ้ำกันที่ระบุผู้ใช้ในระบบ - email- อีเมลของผู้ใช้ - given_name- ไม่บังคับ: ชื่อของผู้ใช้ - family_name- ไม่บังคับ: นามสกุลของผู้ใช้ - name- ไม่บังคับ: ชื่อเต็มของผู้ใช้ - picture- ไม่บังคับ: รูปโปรไฟล์ของผู้ใช้ 
ตรวจสอบการติดตั้งใช้งาน
คุณตรวจสอบการติดตั้งใช้งานได้โดยใช้เครื่องมือ OAuth 2.0 Playground
ทำตามขั้นตอนต่อไปนี้ในเครื่องมือ
- คลิกการกําหนดค่า เพื่อเปิดหน้าต่างการกําหนดค่า OAuth 2.0
- ในช่องขั้นตอน OAuth ให้เลือกฝั่งไคลเอ็นต์
- ในช่อง OAuth Endpoints ให้เลือก Custom
- ระบุปลายทาง OAuth 2.0 และรหัสไคลเอ็นต์ที่คุณกำหนดให้กับ Google ในช่องที่เกี่ยวข้อง
- ในส่วนขั้นตอนที่ 1 ไม่ต้องเลือกขอบเขตของ Google แต่ให้เว้นช่องนี้ว่างไว้หรือพิมพ์ขอบเขตที่ใช้ได้กับเซิร์ฟเวอร์ของคุณ (หรือสตริงที่กำหนดเองหากคุณไม่ได้ใช้ขอบเขต OAuth) เมื่อดำเนินการเสร็จแล้ว ให้คลิกให้สิทธิ์ API
- ในส่วนขั้นตอนที่ 2 และขั้นตอนที่ 3 ให้ทำตามขั้นตอน OAuth 2.0 และตรวจสอบว่าแต่ละขั้นตอนทำงานตามที่ต้องการ
คุณสามารถตรวจสอบการติดตั้งใช้งานโดยใช้เครื่องมือการสาธิตการลิงก์บัญชี Google
ทำตามขั้นตอนต่อไปนี้ในเครื่องมือ
- คลิกปุ่มลงชื่อเข้าใช้ด้วย Google
- เลือกบัญชีที่ต้องการลิงก์
- ป้อนรหัสบริการ
- (ไม่บังคับ) ป้อนขอบเขตที่จะขอสิทธิ์เข้าถึงอย่างน้อย 1 รายการ
- คลิกเริ่มสาธิต
- เมื่อได้รับข้อความแจ้ง ให้ยืนยันว่าคุณอาจยินยอมและปฏิเสธคำขอลิงก์
- ยืนยันว่าระบบเปลี่ยนเส้นทางคุณไปยังแพลตฟอร์ม