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

ทุกsmart homeการดําเนินการต้องมีกลไกในการตรวจสอบสิทธิ์ผู้ใช้

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

หน้านี้อธิบายถึงวิธีตั้งค่าเซิร์ฟเวอร์ OAuth 2.0 ให้เหมาะกับการทํางาน smart home

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

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

• ปลายทางการให้สิทธิ์ ซึ่งจะแสดง UI การลงชื่อเข้าใช้แก่ผู้ใช้ที่ไม่ได้ลงชื่อเข้าใช้ ปลายทางการให้สิทธิ์ยังสร้างรหัสการให้สิทธิ์ที่ใช้ได้เพียงสั้นๆ เพื่อบันทึกคํายินยอมของผู้ใช้ในการเข้าถึงคําขอ

• ปลายทางของ Token Exchange ซึ่งรับผิดชอบการแลกเปลี่ยน 2 ประเภทดังนี้

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

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

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

ข้อกำหนด

1. คุณต้องสื่อสารว่าบัญชีของผู้ใช้จะลิงก์กับ Google ไม่ใช่ผลิตภัณฑ์เฉพาะของ Google เช่น Google Home หรือ Google Assistant
2. คุณต้องมีคําชี้แจงการให้สิทธิ์ของ Google เช่น "การลงชื่อเข้าใช้เป็นการให้สิทธิ์ Google ควบคุมอุปกรณ์" ดูส่วนการให้สิทธิ์ควบคุมอุปกรณ์ของ Google ในนโยบายสําหรับนักพัฒนาซอฟต์แวร์ Google Home

การแนะนำวิดีโอ

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

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

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

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

4. ความสามารถในการยกเลิก เสนอวิธีให้ผู้ใช้ยกเลิกหรือยกเลิก หากไม่ต้องการลิงก์

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

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

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

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

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

ขั้นตอนการให้สิทธิ์รหัสการให้สิทธิ์

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

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

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

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

พารามิเตอร์ปลายทางการแลกเปลี่ยนโทเค็น
client_id	สตริงที่ระบุที่มาของคําขอเป็น Google สตริงนี้ต้องลงทะเบียนภายในระบบเป็นตัวระบุที่ไม่ซ้ํากันของ Google&#39
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 ได้รับจากปลายทางการแลกเปลี่ยนโทเค็น

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

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

หากต้องการแลกเปลี่ยนรหัสการให้สิทธิ์สําหรับโทเค็นเพื่อการเข้าถึงและโทเค็นการรีเฟรช ปลายทาง Exchange โทเค็นจะตอบกลับคําขอ 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 จะใช้โทเค็นการรีเฟรช เพื่อรับโทเค็นเพื่อการเข้าถึงใหม่จากปลายทางการแลกเปลี่ยนโทเค็น

โทเค็นการรีเฟรช Exchange สําหรับโทเค็นเพื่อการเข้าถึง

เมื่อโทเค็นเพื่อการเข้าถึงหมดอายุ 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. ไม่เช่นนั้น ให้ใช้ User ID จากโทเค็นการรีเฟรชเพื่อสร้างโทเค็นเพื่อการเข้าถึง โดยโทเค็นเหล่านี้อาจเป็นค่าสตริงใดก็ได้ แต่ต้องแสดงถึงผู้ใช้และไคลเอ็นต์สําหรับโทเค็นโดยเฉพาะ และต้องไม่คาดเดาได้ สําหรับโทเค็นเพื่อการเข้าถึง ให้บันทึกเวลาหมดอายุของโทเค็นด้วย ซึ่งโดยทั่วไปคือใช้เวลา 1 ชั่วโมงหลังจากคุณออกโทเค็น
5. แสดงผลออบเจ็กต์ JSON ต่อไปนี้ในส่วนเนื้อหาของการตอบกลับ HTTPS

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

จัดการคําขอข้อมูลผู้ใช้

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

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

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

ส่วนหัวของคําขอปลายทางข้อมูลผู้ใช้
Authorization header	โทเค็นเพื่อการเข้าถึงของประเภท Bearer

ตัวอย่างเช่น หากปลายทาง userinfo ของคุณอยู่ที่ https://myservice.example.com/userinfo คําขออาจมีลักษณะเช่นนี้

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

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

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

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

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

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 ของผู้ใช้

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