การลิงก์บัญชี 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 หลังจากให้ความยินยอมในการลิงก์บัญชี

ข้อกำหนด

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

คำแนะนำ

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

1. แสดงนโยบายความเป็นส่วนตัวของ Google ใส่ลิงก์ไปยังนโยบายความเป็นส่วนตัวของ Google ในหน้าจอคํายินยอม

2. ข้อมูลที่จะแชร์ ใช้ภาษาที่ชัดเจนและกระชับเพื่อบอกผู้ใช้ว่า Google ต้องการข้อมูลใดและเพราะเหตุใด

3. คํากระตุ้นการตัดสินใจที่ชัดเจน ระบุคํากระตุ้นการตัดสินใจที่ชัดเจนบนหน้าจอคํายินยอม เช่น "ยอมรับและลิงก์" เนื่องจากผู้ใช้ต้องเข้าใจว่าข้อมูลใดที่ตนเองต้องแชร์กับ Google เพื่อลิงก์บัญชีของตน

4. ความสามารถในการยกเลิก ระบุวิธีให้ผู้ใช้ย้อนกลับหรือยกเลิกได้หากผู้ใช้เลือกที่จะไม่ลิงก์

5. ล้างกระบวนการลงชื่อเข้าใช้ ตรวจสอบว่าผู้ใช้มีวิธีลงชื่อเข้าใช้บัญชี Google ที่ชัดเจน เช่น ช่องสําหรับชื่อผู้ใช้และรหัสผ่าน หรือลงชื่อเข้าใช้ด้วย Google

6. ความสามารถในการยกเลิกการลิงก์ มีกลไกให้ผู้ใช้ยกเลิกการลิงก์ เช่น URL ไปยังการตั้งค่าบัญชีในแพลตฟอร์ม หรือใส่ลิงก์ไปยังบัญชี Google ก็ได้ ซึ่งผู้ใช้จะจัดการบัญชีที่ลิงก์ไว้ได้

7. ความสามารถในการเปลี่ยนบัญชีผู้ใช้ แนะนําวิธีการให้ผู้ใช้เปลี่ยนบัญชี ซึ่งจะเป็นประโยชน์อย่างยิ่งหากผู้ใช้มีแนวโน้มที่จะมีหลายบัญชี

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

8. ใส่โลโก้ของคุณ แสดงโลโก้บริษัทในหน้าจอคํายินยอม ใช้หลักเกณฑ์รูปแบบในการวางโลโก้ หากต้องการแสดงโลโก้ Google&#39 ด้วย โปรดดูโลโก้และเครื่องหมายการค้า

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

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

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

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

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

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

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

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

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

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

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

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

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

ตัวอย่างเช่น หากปลายทางการให้สิทธิ์อยู่ที่ 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 ประเภท การแลกเปลี่ยน:

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

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

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

หลังจากผู้ใช้ลงชื่อเข้าใช้และปลายทางการให้สิทธิ์แสดงผลเป็นช่วงเวลาสั้นๆ รหัสการให้สิทธิ์ไปยัง 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
   }

จัดการคำขอ Userinfo

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

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

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

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

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

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

1. แยกโทเค็นเพื่อการเข้าถึงจากส่วนหัวการให้สิทธิ์ แล้วแสดงผลข้อมูลสำหรับผู้ใช้ที่เชื่อมโยงกับโทเค็นเพื่อการเข้าถึง
2. หากโทเค็นเพื่อการเข้าถึงไม่ถูกต้อง ให้แสดงข้อผิดพลาด HTTP 401 Unauthorized ด้วยการใช้ส่วนหัวการตอบกลับ WWW-Authenticate ตัวอย่างการตอบกลับข้อผิดพลาดเกี่ยวกับ Userinfo มีดังนี้

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

   หากข้อผิดพลาด 401 Unauthorized หรือการตอบกลับที่ผิดพลาดอื่นๆ ที่ไม่สำเร็จในระหว่างกระบวนการลิงก์ ข้อผิดพลาดดังกล่าวจะกู้คืนไม่ได้ ระบบจะทิ้งโทเค็นที่ดึงมาและผู้ใช้จะต้องเริ่มกระบวนการลิงก์อีกครั้ง

3. หากโทเค็นเพื่อการเข้าถึงถูกต้อง ให้แสดงผลและการตอบสนอง 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 สนามเด็กเล่น เครื่องมือ

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

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

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

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

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