ทุกsmart homeการดําเนินการต้องมีกลไกในการตรวจสอบสิทธิ์ผู้ใช้
การตรวจสอบสิทธิ์ช่วยให้คุณลิงก์บัญชี Google ของผู้ใช้เข้ากับบัญชีผู้ใช้ในระบบการตรวจสอบสิทธิ์ ซึ่งจะช่วยให้คุณระบุผู้ใช้ได้เมื่อดําเนินการตามคําสั่งซื้อบ้านสําเร็จ สมาร์ทโฮมของ Google รองรับเฉพาะ OAuth ด้วยขั้นตอนการให้สิทธิ์รหัสการให้สิทธิ์
หน้านี้อธิบายถึงวิธีตั้งค่าเซิร์ฟเวอร์ OAuth 2.0 ให้เหมาะกับการทํางาน smart home
การลิงก์บัญชี Google กับ OAuth
ในรหัสการให้สิทธิ์ คุณต้องมีปลายทาง 2 จุด ได้แก่
ปลายทางการให้สิทธิ์ ซึ่งจะแสดง UI การลงชื่อเข้าใช้แก่ผู้ใช้ที่ไม่ได้ลงชื่อเข้าใช้ ปลายทางการให้สิทธิ์ยังสร้างรหัสการให้สิทธิ์ที่ใช้ได้เพียงสั้นๆ เพื่อบันทึกคํายินยอมของผู้ใช้ในการเข้าถึงคําขอ
ปลายทางของ Token Exchange ซึ่งรับผิดชอบการแลกเปลี่ยน 2 ประเภทดังนี้
- แลกเปลี่ยนรหัสการให้สิทธิ์สําหรับโทเค็นการรีเฟรชที่ใช้ได้นานและโทเค็นเพื่อการเข้าถึงที่ใช้ได้นาน การแลกเปลี่ยนนี้จะเกิดขึ้นเมื่อผู้ใช้เข้าสู่ ขั้นตอนการเชื่อมโยงบัญชี
- แลกเปลี่ยนโทเค็นการรีเฟรชที่ใช้ได้นานกับโทเค็นเพื่อการเข้าถึงที่ใช้ได้ในระยะสั้น การแลกเปลี่ยนนี้เกิดขึ้นเมื่อ Google ต้องการโทเค็นเพื่อการเข้าถึงใหม่ เนื่องจากโทเค็นหมดอายุ
หลักเกณฑ์การออกแบบ
ส่วนนี้จะอธิบายข้อกําหนดการออกแบบและคําแนะนําสําหรับหน้าจอผู้ใช้ที่คุณโฮสต์สําหรับขั้นตอนการเชื่อมโยง OAuth หลังจากที่ Google เรียกใช้ฟีเจอร์นี้ แพลตฟอร์มจะแสดงการลงชื่อเข้าใช้หน้า Google และหน้าจอคํายินยอมในการลิงก์บัญชีต่อผู้ใช้ ระบบจะนําผู้ใช้กลับมาที่แอปของ Google หลังจากให้ความยินยอมในการลิงก์บัญชี

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

ขั้นตอนการให้สิทธิ์รหัสการให้สิทธิ์
การดําเนินการของเซิร์ฟเวอร์ OAuth 2.0 ตามโฟลว์รหัสการให้สิทธิ์ประกอบด้วยปลายทาง 2 ปลายทาง ซึ่งบริการจะเปิดเผยด้วย HTTPS ปลายทางแรกคือปลายทางการให้สิทธิ์ ซึ่งมีหน้าที่ในการค้นหาหรือขอความยินยอมจากผู้ใช้สําหรับการเข้าถึงข้อมูล ปลายทางการให้สิทธิ์จะแสดง UI การลงชื่อเข้าใช้แก่ผู้ใช้ที่ไม่ได้ลงชื่อเข้าใช้และบันทึกความยินยอมสําหรับการเข้าถึงที่ขอ ปลายทางที่ 2 คือปลายทางการแลกเปลี่ยนโทเค็นซึ่งใช้เพื่อรับสตริงที่เข้ารหัสที่เรียกว่าโทเค็น ซึ่งให้สิทธิ์ผู้ใช้เข้าถึงบริการของคุณ
เมื่อแอปพลิเคชันของ Google ต้องเรียก API บริการใดบริการหนึ่งของคุณ Google จะใช้ปลายทางเหล่านี้ร่วมกันเพื่อขอสิทธิ์จากผู้ใช้ในการเรียก API เหล่านี้ในนามของ 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 ประเภทดังนี้
- รหัสการให้สิทธิ์ของ Exchange สําหรับโทเค็นเพื่อการเข้าถึงและโทเค็นการรีเฟรช
- โทเค็นการรีเฟรช Exchange สําหรับโทเค็นเพื่อการเข้าถึง
คําขอการแลกเปลี่ยนโทเค็นมีพารามิเตอร์ต่อไปนี้
พารามิเตอร์ปลายทางการแลกเปลี่ยนโทเค็น | |
---|---|
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 ได้รับจากปลายทางการแลกเปลี่ยนโทเค็น |
รหัสการให้สิทธิ์ของ 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
โดยทําตามขั้นตอนต่อไปนี้
- ยืนยันว่า
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 จะใช้โทเค็นการรีเฟรช เพื่อรับโทเค็นเพื่อการเข้าถึงใหม่จากปลายทางการแลกเปลี่ยนโทเค็น
โทเค็นการรีเฟรช 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
โดยปฏิบัติตามขั้นตอนต่อไปนี้
- ยืนยันว่า
client_id
ระบุต้นทางคําขอเป็น Google และclient_secret
ตรงกับค่าที่คาดไว้ - ตรวจสอบว่าโทเค็นการรีเฟรชถูกต้อง และรหัสไคลเอ็นต์ที่ระบุในคําขอตรงกับรหัสไคลเอ็นต์ที่เชื่อมโยงกับโทเค็นการรีเฟรช
- หากยืนยันเกณฑ์ทั้งหมดข้างต้นไม่ได้ ให้แสดงข้อผิดพลาดคําขอ HTTP 400 ที่ไม่ถูกต้องโดยมี
{"error": "invalid_grant"}
เป็นเนื้อความ - ไม่เช่นนั้น ให้ใช้ User ID จากโทเค็นการรีเฟรชเพื่อสร้างโทเค็นเพื่อการเข้าถึง โดยโทเค็นเหล่านี้อาจเป็นค่าสตริงใดก็ได้ แต่ต้องแสดงถึงผู้ใช้และไคลเอ็นต์สําหรับโทเค็นโดยเฉพาะ และต้องไม่คาดเดาได้ สําหรับโทเค็นเพื่อการเข้าถึง ให้บันทึกเวลาหมดอายุของโทเค็นด้วย ซึ่งโดยทั่วไปคือใช้เวลา 1 ชั่วโมงหลังจากคุณออกโทเค็น
- แสดงผลออบเจ็กต์ 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 จัดการคําขอ ให้ทําตามขั้นตอนต่อไปนี้
- ดึงโทเค็นการเข้าถึงจากส่วนหัวการให้สิทธิ์และส่งคืนข้อมูลสําหรับผู้ใช้ที่เชื่อมโยงกับโทเค็นเพื่อการเข้าถึง
- หากโทเค็นเพื่อการเข้าถึงไม่ถูกต้อง ให้แสดงผลข้อผิดพลาด HTTP 401 ไม่ได้รับอนุญาตโดยใช้ส่วนหัวการตอบกลับ
WWW-Authenticate
ด้านล่างนี้เป็นตัวอย่างของการตอบกลับข้อผิดพลาด userinfo:HTTP/1.1 401 Unauthorized WWW-Authenticate: error="invalid_token", error_description="The Access Token expired"
หากมีการแสดงข้อผิดพลาด 401 ที่ไม่ได้รับอนุญาต หรือการตอบสนองข้อผิดพลาดอื่นๆ ที่ดําเนินการไม่สําเร็จระหว่างกระบวนการลิงก์ ข้อผิดพลาดนั้นจะไม่สามารถกู้คืนได้ โทเค็นที่เรียกคืนจะถูกทิ้งไปและผู้ใช้ต้องเริ่มต้นกระบวนการลิงก์อีกครั้ง หากโทเค็นเพื่อการเข้าถึงถูกต้อง การตอบกลับและการตอบกลับ 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
ไม่บังคับ: รูปโปรไฟล์ของผู้ใช้