การลิงก์บัญชีด้วย OAuth

ประเภทการลิงก์ OAuth รองรับขั้นตอน OAuth 2.0 มาตรฐานอุตสาหกรรม 2 ขั้นตอน ได้แก่ ขั้นตอนของรหัสโดยนัยและการให้สิทธิ์

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

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

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

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

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

เพื่อช่วยให้กระบวนการตรวจสอบง่ายขึ้น

กำหนดค่าโปรเจ็กต์

หากต้องการกำหนดค่าโปรเจ็กต์เพื่อใช้การลิงก์ OAuth ให้ทำตามขั้นตอนต่อไปนี้

  1. เปิดคอนโซล Actions แล้วเลือกโปรเจ็กต์ที่ต้องการใช้
  2. คลิกแท็บพัฒนา และเลือกการลิงก์บัญชี
  3. เปิดใช้สวิตช์ข้างการลิงก์บัญชี
  4. ในส่วนการสร้างบัญชี ให้เลือกไม่ ฉันต้องการอนุญาตให้สร้างบัญชีบนเว็บไซต์เท่านั้น
  5. ในประเภทการลิงก์ ให้เลือก OAuth และรหัสการให้สิทธิ์

  6. ในส่วนข้อมูลลูกค้า:

    • กำหนดค่ารหัสลูกค้าที่ออกโดย Actions to Google เพื่อระบุคำขอที่มาจาก Google
    • จดบันทึกมูลค่าของรหัสลูกค้าที่ Google ออกให้กับการดำเนินการของคุณ
    • ใส่ URL สำหรับปลายทางการให้สิทธิ์และการแลกเปลี่ยนโทเค็น
  1. คลิกบันทึก

ใช้งานเซิร์ฟเวอร์ OAuth

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

เมื่อการดำเนินการของคุณต้องเรียกใช้ API ของบริการ Google จะใช้ปลายทางเหล่านี้ร่วมกันเพื่อขอสิทธิ์จากผู้ใช้ให้เรียกใช้ API เหล่านี้ในนามของบริษัท

เซสชันโฟลว์ของรหัสการให้สิทธิ์ OAuth 2.0 ที่ Google เป็นผู้เริ่มต้นมีขั้นตอนดังต่อไปนี้

  1. Google จะเปิดปลายทางการให้สิทธิ์ในเบราว์เซอร์ของผู้ใช้ หากขั้นตอนเริ่มต้นในอุปกรณ์แบบเสียงเท่านั้นสำหรับการดำเนินการ Google จะโอนการดำเนินการไปยังโทรศัพท์
  2. ผู้ใช้จะลงชื่อเข้าใช้ (หากยังไม่ได้ลงชื่อเข้าใช้) และให้สิทธิ์ Google ในการเข้าถึงข้อมูลของตนด้วย API ของคุณ หากผู้ใช้ยังไม่ได้ให้สิทธิ์

  3. บริการจะสร้างรหัสการให้สิทธิ์และส่งคืนไปยัง Google โดยเปลี่ยนเส้นทางเบราว์เซอร์ของผู้ใช้กลับไปยัง Google โดยมีรหัสการให้สิทธิ์แนบไปกับคำขอ

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

  5. หลังจากที่ผู้ใช้ดำเนินการตามขั้นตอนการลิงก์บัญชีเสร็จแล้ว คำขอที่ตามมาทุกรายการที่ส่งจาก 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

หากต้องการให้ปลายทางการให้สิทธิ์จัดการคำขอลงชื่อเข้าใช้ ให้ทำตามขั้นตอนต่อไปนี้

  1. ยืนยันว่า client_id ตรงกับรหัสไคลเอ็นต์ของ Google ที่คุณลงทะเบียนกับ 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
    YOUR_PROJECT_ID คือรหัสที่อยู่ในหน้าการตั้งค่าโปรเจ็กต์ของคอนโซล Actions

  5. เปลี่ยนเส้นทางเบราว์เซอร์ของผู้ใช้ไปยัง 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 ที่ดำเนินการตามขั้นตอนต่อไปนี้

  1. ตรวจสอบว่า client_id ระบุต้นทางของคำขอว่าเป็นต้นทางที่ได้รับอนุญาต และ client_secret ตรงกับค่าที่คาดไว้
  2. โปรดตรวจสอบสิ่งต่อไปนี้
    • รหัสการให้สิทธิ์ถูกต้องและไม่หมดอายุ และรหัสไคลเอ็นต์ที่ระบุในคำขอตรงกับรหัสไคลเอ็นต์ที่เชื่อมโยงกับรหัสการให้สิทธิ์
    • URL ที่ระบุโดยพารามิเตอร์ redirect_uri จะเหมือนกับ URL ที่ใช้ในคำขอการให้สิทธิ์ครั้งแรก
  3. หากคุณยืนยันเกณฑ์ข้างต้นทั้งหมดไม่ได้ ให้แสดงผลข้อผิดพลาด HTTP 400 Bad Request โดยมี {"error": "invalid_grant"} เป็นเนื้อความ
  4. หรือสร้างโทเค็นการรีเฟรชและโทเค็นเพื่อการเข้าถึงโดยใช้รหัสผู้ใช้จากรหัสการให้สิทธิ์ โทเค็นเหล่านี้จะเป็นค่าสตริงใดก็ได้ แต่จะต้องแสดงถึงผู้ใช้และไคลเอ็นต์ที่โทเค็นนั้นใช้ได้อย่างไม่ซ้ำกัน และต้องไม่มีการคาดเดา สำหรับโทเค็นเพื่อการเข้าถึง ให้บันทึกเวลาหมดอายุของโทเค็นด้วย (โดยปกติคือ 1 ชั่วโมงหลังจากที่ออกโทเค็น) โทเค็นการรีเฟรชไม่มีวันหมดอายุ
  5. แสดงออบเจ็กต์ 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 Bad Request โดยมี {"error": "invalid_grant"} เป็นเนื้อความ
  4. หรือใช้ User-ID จากโทเค็นการรีเฟรชเพื่อสร้างโทเค็นเพื่อการเข้าถึง โทเค็นเหล่านี้อาจเป็นค่าสตริงใดก็ได้ แต่จะต้องแสดงถึงผู้ใช้และไคลเอ็นต์ที่โทเค็นใช้ได้โดยไม่ซ้ำกัน และต้องเดาไม่ได้ สำหรับโทเค็นเพื่อการเข้าถึง ให้บันทึกเวลาหมดอายุของโทเค็นด้วย (โดยปกติคือ 1 ชั่วโมงหลังจากที่ออกโทเค็น)
  5. แสดงออบเจ็กต์ JSON ต่อไปนี้ในเนื้อหาของการตอบสนอง HTTPS
    {
    "token_type": "Bearer",
    "access_token": "ACCESS_TOKEN",
    "expires_in": SECONDS_TO_EXPIRATION
    }

ออกแบบอินเทอร์เฟซผู้ใช้แบบเสียงสำหรับขั้นตอนการตรวจสอบสิทธิ์

ตรวจสอบว่าผู้ใช้ได้รับการยืนยันหรือไม่ และเริ่มขั้นตอนการลิงก์บัญชี

  1. เปิดโปรเจ็กต์ Actions Builder ในคอนโซล Actions
  2. สร้างฉากใหม่เพื่อเริ่มลิงก์บัญชีใน Action ของคุณ
    1. คลิกฉาก
    2. คลิกไอคอนเพิ่ม (+) เพื่อเพิ่มฉากใหม่
  3. ในโหมดที่สร้างขึ้นใหม่ ให้คลิกไอคอนเพิ่ม สำหรับเงื่อนไข
  4. เพิ่มเงื่อนไขที่ตรวจสอบว่าผู้ใช้ที่เชื่อมโยงกับการสนทนาเป็นผู้ใช้ที่ได้รับการยืนยันหรือไม่ หากการตรวจสอบไม่สำเร็จ การดำเนินการของคุณจะไม่สามารถลิงก์บัญชีในระหว่างการสนทนา และควรกลับไปให้สิทธิ์เข้าถึงฟังก์ชันการทำงานที่ไม่จำเป็นต้องมีการลิงก์บัญชี
    1. ในช่อง Enter new expression ในส่วนเงื่อนไข ให้ป้อนตรรกะต่อไปนี้ user.verificationStatus != "VERIFIED"
    2. ในส่วนการเปลี่ยน ให้เลือกฉากที่ไม่ต้องมีการลิงก์บัญชีหรือฉากที่เป็นจุดเข้าถึงฟังก์ชันการทำงานสำหรับผู้มาเยือนเท่านั้น

  1. คลิกไอคอนเพิ่ม สำหรับเงื่อนไข
  2. เพิ่มเงื่อนไขเพื่อทริกเกอร์โฟลว์การลิงก์บัญชีหากผู้ใช้ไม่มีข้อมูลระบุตัวตนที่เชื่อมโยง
    1. ในช่อง Enter new expression ในส่วนเงื่อนไข ให้ป้อนตรรกะต่อไปนี้ user.verificationStatus == "VERIFIED"
    2. ในส่วนการเปลี่ยน ให้เลือกโหมดระบบการลิงก์บัญชี
    3. คลิกบันทึก

เมื่อบันทึกแล้ว ระบบจะเพิ่มโหมดระบบการลิงก์บัญชีใหม่ที่ชื่อว่า <SceneName>_AccountLinking ลงในโปรเจ็กต์

ปรับแต่งฉากการลิงก์บัญชี

  1. เลือกโหมดระบบการลิงก์บัญชีในส่วนฉาก
  2. คลิกส่งพรอมต์ แล้วเพิ่มประโยคสั้นๆ เพื่ออธิบายให้ผู้ใช้ทราบว่าทำไมการดำเนินการจึงจำเป็นต้องเข้าถึงข้อมูลประจำตัว (เช่น "เพื่อบันทึกค่ากำหนดของคุณ")
  3. คลิกบันทึก

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

  1. คลิกหากผู้ใช้ยกเลิกหรือปิดการลิงก์บัญชีในส่วนเงื่อนไข
  2. กำหนดค่าว่าขั้นตอนควรดำเนินการอย่างไรหากผู้ใช้ไม่ตกลงที่จะลิงก์บัญชี เช่น ส่งข้อความตอบรับและเปลี่ยนเส้นทางไปยังฉากที่มีฟังก์ชันการทำงานที่ไม่ต้องใช้การลิงก์บัญชี
  3. คลิกบันทึก

  1. ในส่วนเงื่อนไข ให้คลิกหากระบบหรือเครือข่ายเกิดข้อผิดพลาด
  2. กำหนดค่าว่าขั้นตอนควรดำเนินการอย่างไรหากดำเนินการลิงก์บัญชีไม่สำเร็จเนื่องจากข้อผิดพลาดของระบบหรือเครือข่าย เช่น ส่งข้อความตอบรับและเปลี่ยนเส้นทางไปยังฉากที่มีฟังก์ชันการทำงานที่ไม่ต้องใช้การลิงก์บัญชี
  3. คลิกบันทึก

จัดการคำขอเข้าถึงข้อมูล

หากคำขอ Assistant มีโทเค็นเพื่อการเข้าถึง ก่อนอื่นให้ตรวจสอบว่าโทเค็นเพื่อการเข้าถึงถูกต้อง (และยังไม่หมดอายุ) แล้วจึงเรียกข้อมูลบัญชีผู้ใช้ที่เชื่อมโยงจากฐานข้อมูล