ประเภทการลิงก์ OAuth รองรับขั้นตอน OAuth 2.0 มาตรฐานอุตสาหกรรม 2 ขั้นตอน ได้แก่ ขั้นตอนของรหัสโดยนัยและการให้สิทธิ์
ในขั้นตอนการเขียนโค้ดแบบโดยนัย Google จะเปิดปลายทางการให้สิทธิ์ในเบราว์เซอร์ของผู้ใช้ เมื่อลงชื่อเข้าใช้สําเร็จ คุณจะส่งคืนโทเค็นเพื่อการเข้าถึงที่ใช้ได้นานแก่ Google ตอนนี้โทเค็นเพื่อการเข้าถึงนี้รวมอยู่ในคําขอทุกรายการที่ส่งจาก Assistant ไปยังการดําเนินการของคุณแล้ว
ในกระบวนการรหัสการให้สิทธิ์ คุณต้องมีปลายทาง 2 จุด ได้แก่
- ปลายทางการให้สิทธิ์ ซึ่งมีหน้าที่นําเสนอ UI การลงชื่อเข้าใช้แก่ผู้ใช้ที่ไม่ได้ลงชื่อเข้าใช้ และยินยอมให้มีการเข้าถึงการเข้าถึงที่ขอในรูปของรหัสการให้สิทธิ์ระยะสั้น
- ปลายทางของการแลกเปลี่ยนโทเค็นที่มีหน้าที่รับผิดชอบการแลกเปลี่ยน 2 ประเภท ได้แก่
- แลกเปลี่ยนรหัสการให้สิทธิ์สําหรับโทเค็นการรีเฟรชที่ใช้ได้นานและโทเค็นเพื่อการเข้าถึงที่ใช้ได้นาน การแลกเปลี่ยนนี้จะเกิดขึ้นเมื่อผู้ใช้เข้าสู่ กระบวนการเชื่อมโยงบัญชี
- แลกเปลี่ยนโทเค็นการรีเฟรชที่ใช้ได้นานกับโทเค็นเพื่อการเข้าถึงที่ใช้ได้ในระยะสั้น Exchange นี้จะเกิดขึ้นเมื่อ Google ต้องการโทเค็นเพื่อการเข้าถึงใหม่เนื่องจากโทเค็นหมดอายุ
แม้ว่าขั้นตอนการใช้รหัสโดยนัยจะง่ายกว่า Google ขอแนะนําว่าโทเค็นเพื่อการเข้าถึงที่ออกโดยใช้โฟลว์โดยนัยไม่มีวันหมดอายุ เนื่องจากการใช้การหมดอายุของโทเค็นด้วยขั้นตอนโดยนัยบังคับให้ผู้ใช้ลิงก์บัญชีอีกครั้ง หากคุณต้องการใช้การหมดอายุของโทเค็นด้วยเหตุผลด้านความปลอดภัย คุณควรพิจารณาการใช้ขั้นตอนการตรวจสอบสิทธิ์แทน
ใช้การลิงก์บัญชี OAuth
เพื่อช่วยให้กระบวนการตรวจสอบง่ายขึ้นกำหนดค่าโปรเจ็กต์
หากต้องการกำหนดค่าโปรเจ็กต์เพื่อใช้การลิงก์ OAuth ให้ทำตามขั้นตอนต่อไปนี้
- เปิดคอนโซล Actions แล้วเลือกโปรเจ็กต์ที่ต้องการใช้
- คลิกแท็บพัฒนา และเลือกการลิงก์บัญชี
- เปิดใช้สวิตช์ข้างการลิงก์บัญชี
- ในส่วนการสร้างบัญชี ให้เลือกไม่ ฉันต้องการอนุญาตให้สร้างบัญชีบนเว็บไซต์เท่านั้น
ในประเภทการลิงก์ ให้เลือก OAuth และรหัสการให้สิทธิ์
ในส่วนข้อมูลลูกค้า:
- กำหนดค่ารหัสลูกค้าที่ออกโดย Actions to Google เพื่อระบุคำขอที่มาจาก Google
- จดบันทึกมูลค่าของรหัสลูกค้าที่ Google ออกให้กับการดำเนินการของคุณ
- ใส่ URL สำหรับปลายทางการให้สิทธิ์และการแลกเปลี่ยนโทเค็น
- คลิกบันทึก
ใช้งานเซิร์ฟเวอร์ OAuth
การใช้งานเซิร์ฟเวอร์ OAuth 2.0 สำหรับโฟลว์ของรหัสการให้สิทธิ์ประกอบไปด้วยปลายทาง 2 จุด ซึ่ง HTTPS จะใช้บริการของคุณได้ ปลายทางแรกคือปลายทางการให้สิทธิ์ ซึ่งมีหน้าที่ค้นหาหรือขอความยินยอมจากผู้ใช้ในการเข้าถึงข้อมูล ปลายทางการให้สิทธิ์จะแสดง UI การลงชื่อเข้าใช้แก่ผู้ใช้ที่ยังไม่ได้ลงชื่อเข้าใช้และบันทึกความยินยอมในการเข้าถึงที่ขอ ปลายทางที่ 2 คือปลายทางการแลกเปลี่ยนโทเค็น ซึ่งใช้เพื่อรับสตริงที่เข้ารหัสที่เรียกว่าโทเค็นที่ให้สิทธิ์ผู้ใช้ Action เข้าถึงบริการของคุณ
เมื่อการดำเนินการของคุณต้องเรียกใช้ API ของบริการ Google จะใช้ปลายทางเหล่านี้ร่วมกันเพื่อขอสิทธิ์จากผู้ใช้ให้เรียกใช้ API เหล่านี้ในนามของบริษัท
เซสชันโฟลว์ของรหัสการให้สิทธิ์ OAuth 2.0 ที่ Google เป็นผู้เริ่มต้นมีขั้นตอนดังต่อไปนี้
- Google จะเปิดปลายทางการให้สิทธิ์ในเบราว์เซอร์ของผู้ใช้ หากขั้นตอนเริ่มต้นในอุปกรณ์แบบเสียงเท่านั้นสำหรับการดำเนินการ Google จะโอนการดำเนินการไปยังโทรศัพท์
ผู้ใช้จะลงชื่อเข้าใช้ (หากยังไม่ได้ลงชื่อเข้าใช้) และให้สิทธิ์ Google ในการเข้าถึงข้อมูลของตนด้วย API ของคุณ หากผู้ใช้ยังไม่ได้ให้สิทธิ์
บริการจะสร้างรหัสการให้สิทธิ์และส่งคืนไปยัง Google โดยเปลี่ยนเส้นทางเบราว์เซอร์ของผู้ใช้กลับไปยัง Google โดยมีรหัสการให้สิทธิ์แนบไปกับคำขอ
Google จะส่งรหัสการให้สิทธิ์ไปยังปลายทางการแลกเปลี่ยนโทเค็น ซึ่งจะยืนยันความถูกต้องของโค้ดและแสดงผลโทเค็นเพื่อการเข้าถึงและโทเค็นการรีเฟรช โทเค็นเพื่อการเข้าถึงคือโทเค็นที่มีอายุสั้นที่บริการของคุณยอมรับเป็นข้อมูลเข้าสู่ระบบเพื่อเข้าถึง API โทเค็นการรีเฟรชเป็นโทเค็นที่มีอายุการใช้งานยาวนานซึ่ง Google สามารถจัดเก็บและใช้เพื่อให้ได้โทเค็นเพื่อการเข้าถึงใหม่เมื่อโทเค็นดังกล่าวหมดอายุ
หลังจากที่ผู้ใช้ดำเนินการตามขั้นตอนการลิงก์บัญชีเสร็จแล้ว คำขอที่ตามมาทุกรายการที่ส่งจาก Assistant ไปยังเว็บฮุค Fulfillment ของคุณจะมีโทเค็นเพื่อการเข้าถึง
จัดการคำขอการให้สิทธิ์
เมื่อการดำเนินการของคุณจำเป็นต้องลิงก์บัญชีผ่านขั้นตอนรหัสการให้สิทธิ์ OAuth 2.0 Google จะส่งผู้ใช้ไปยังปลายทางการให้สิทธิ์พร้อมคำขอที่มีพารามิเตอร์ต่อไปนี้
พารามิเตอร์ปลายทางการให้สิทธิ์ | |
---|---|
client_id |
รหัสไคลเอ็นต์ Google ที่คุณลงทะเบียนกับ Google |
redirect_uri |
URL ที่คุณส่งการตอบกลับคำขอนี้ |
state |
ค่าการทำบัญชีที่ส่งกลับไปยัง Google โดยไม่มีการเปลี่ยนแปลงใน URI การเปลี่ยนเส้นทาง |
scope |
ไม่บังคับ: ชุดสตริงขอบเขตที่คั่นด้วยช่องว่างซึ่งระบุข้อมูลที่ Google ขอการให้สิทธิ์ |
response_type |
สตริง code |
ตัวอย่างเช่น หากปลายทางการให้สิทธิ์พร้อมใช้งานที่ 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
หากต้องการให้ปลายทางการให้สิทธิ์จัดการคำขอลงชื่อเข้าใช้ ให้ทำตามขั้นตอนต่อไปนี้
ยืนยันว่า
client_id
ตรงกับรหัสไคลเอ็นต์ของ Google ที่คุณลงทะเบียนกับ 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
YOUR_PROJECT_ID คือรหัสที่อยู่ในหน้าการตั้งค่าโปรเจ็กต์ของคอนโซล Actionsเปลี่ยนเส้นทางเบราว์เซอร์ของผู้ใช้ไปยัง 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
จะเหมือนกับ URL ที่ใช้ในคำขอการให้สิทธิ์ครั้งแรก
- หากคุณยืนยันเกณฑ์ข้างต้นทั้งหมดไม่ได้ ให้แสดงผลข้อผิดพลาด HTTP 400 Bad Request โดยมี
{"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 Bad Request โดยมี
{"error": "invalid_grant"}
เป็นเนื้อความ - หรือใช้ User-ID จากโทเค็นการรีเฟรชเพื่อสร้างโทเค็นเพื่อการเข้าถึง โทเค็นเหล่านี้อาจเป็นค่าสตริงใดก็ได้ แต่จะต้องแสดงถึงผู้ใช้และไคลเอ็นต์ที่โทเค็นใช้ได้โดยไม่ซ้ำกัน และต้องเดาไม่ได้ สำหรับโทเค็นเพื่อการเข้าถึง ให้บันทึกเวลาหมดอายุของโทเค็นด้วย (โดยปกติคือ 1 ชั่วโมงหลังจากที่ออกโทเค็น)
- แสดงออบเจ็กต์ JSON ต่อไปนี้ในเนื้อหาของการตอบสนอง HTTPS
{ "token_type": "Bearer", "access_token": "ACCESS_TOKEN", "expires_in": SECONDS_TO_EXPIRATION }
ออกแบบอินเทอร์เฟซผู้ใช้แบบเสียงสำหรับขั้นตอนการตรวจสอบสิทธิ์
ตรวจสอบว่าผู้ใช้ได้รับการยืนยันหรือไม่ และเริ่มขั้นตอนการลิงก์บัญชี
- เปิดโปรเจ็กต์ Actions Builder ในคอนโซล Actions
- สร้างฉากใหม่เพื่อเริ่มลิงก์บัญชีใน Action ของคุณ
- คลิกฉาก
- คลิกไอคอนเพิ่ม (+) เพื่อเพิ่มฉากใหม่
- ในโหมดที่สร้างขึ้นใหม่ ให้คลิกไอคอนเพิ่ม add สำหรับเงื่อนไข
- เพิ่มเงื่อนไขที่ตรวจสอบว่าผู้ใช้ที่เชื่อมโยงกับการสนทนาเป็นผู้ใช้ที่ได้รับการยืนยันหรือไม่ หากการตรวจสอบไม่สำเร็จ การดำเนินการของคุณจะไม่สามารถลิงก์บัญชีในระหว่างการสนทนา และควรกลับไปให้สิทธิ์เข้าถึงฟังก์ชันการทำงานที่ไม่จำเป็นต้องมีการลิงก์บัญชี
- ในช่อง
Enter new expression
ในส่วนเงื่อนไข ให้ป้อนตรรกะต่อไปนี้user.verificationStatus != "VERIFIED"
- ในส่วนการเปลี่ยน ให้เลือกฉากที่ไม่ต้องมีการลิงก์บัญชีหรือฉากที่เป็นจุดเข้าถึงฟังก์ชันการทำงานสำหรับผู้มาเยือนเท่านั้น
- ในช่อง
- คลิกไอคอนเพิ่ม add สำหรับเงื่อนไข
- เพิ่มเงื่อนไขเพื่อทริกเกอร์โฟลว์การลิงก์บัญชีหากผู้ใช้ไม่มีข้อมูลระบุตัวตนที่เชื่อมโยง
- ในช่อง
Enter new expression
ในส่วนเงื่อนไข ให้ป้อนตรรกะต่อไปนี้user.verificationStatus == "VERIFIED"
- ในส่วนการเปลี่ยน ให้เลือกโหมดระบบการลิงก์บัญชี
- คลิกบันทึก
- ในช่อง
เมื่อบันทึกแล้ว ระบบจะเพิ่มโหมดระบบการลิงก์บัญชีใหม่ที่ชื่อว่า <SceneName>_AccountLinking
ลงในโปรเจ็กต์
ปรับแต่งฉากการลิงก์บัญชี
- เลือกโหมดระบบการลิงก์บัญชีในส่วนฉาก
- คลิกส่งพรอมต์ แล้วเพิ่มประโยคสั้นๆ เพื่ออธิบายให้ผู้ใช้ทราบว่าทำไมการดำเนินการจึงจำเป็นต้องเข้าถึงข้อมูลประจำตัว (เช่น "เพื่อบันทึกค่ากำหนดของคุณ")
- คลิกบันทึก
- ในส่วนเงื่อนไข ให้คลิกหากผู้ใช้ลิงก์บัญชีสำเร็จแล้ว
- กำหนดค่าว่าขั้นตอนควรดำเนินการอย่างไรหากผู้ใช้ตกลงที่จะลิงก์บัญชี เช่น เรียกใช้เว็บฮุคเพื่อประมวลผลตรรกะทางธุรกิจที่กำหนดเองที่จำเป็น แล้วเปลี่ยนกลับไปยังฉากที่สร้างขึ้น
- คลิกบันทึก
- คลิกหากผู้ใช้ยกเลิกหรือปิดการลิงก์บัญชีในส่วนเงื่อนไข
- กำหนดค่าว่าขั้นตอนควรดำเนินการอย่างไรหากผู้ใช้ไม่ตกลงที่จะลิงก์บัญชี เช่น ส่งข้อความตอบรับและเปลี่ยนเส้นทางไปยังฉากที่มีฟังก์ชันการทำงานที่ไม่ต้องใช้การลิงก์บัญชี
- คลิกบันทึก
- ในส่วนเงื่อนไข ให้คลิกหากระบบหรือเครือข่ายเกิดข้อผิดพลาด
- กำหนดค่าว่าขั้นตอนควรดำเนินการอย่างไรหากดำเนินการลิงก์บัญชีไม่สำเร็จเนื่องจากข้อผิดพลาดของระบบหรือเครือข่าย เช่น ส่งข้อความตอบรับและเปลี่ยนเส้นทางไปยังฉากที่มีฟังก์ชันการทำงานที่ไม่ต้องใช้การลิงก์บัญชี
- คลิกบันทึก
จัดการคำขอเข้าถึงข้อมูล
หากคำขอ Assistant มีโทเค็นเพื่อการเข้าถึง ก่อนอื่นให้ตรวจสอบว่าโทเค็นเพื่อการเข้าถึงถูกต้อง (และยังไม่หมดอายุ) แล้วจึงเรียกข้อมูลบัญชีผู้ใช้ที่เชื่อมโยงจากฐานข้อมูล