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

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

In the implicit code flow, Google opens your authorization endpoint in the user's browser. After successful sign in, you return a long-lived access token to Google. This access token is now included in every request sent from the Assistant to your Action.

In the authorization code flow, you need two endpoints:

  • The authorization endpoint, which is responsible for presenting the sign-in UI to your users that aren't already signed in and recording consent to the requested access in the form of a short-lived authorization code.
  • The token exchange endpoint, which is responsible for two types of exchanges:
    1. Exchanges an authorization code for a long-lived refresh token and a short-lived access token. This exchange happens when the user goes through the account linking flow.
    2. Exchanges a long-lived refresh token for a short-lived access token. This exchange happens when Google needs a new access token because the one it had expired.

Although the implicit code flow is simpler to implement, Google recommends that access tokens issued using the implicit flow never expire, because using token expiration with the implicit flow forces the user to link their account again. If you need token expiration for security reasons, you should strongly consider using the auth code flow instead.

ใช้การลิงก์บัญชี 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 คือปลายทางการแลกเปลี่ยนโทเค็น ใช้เพื่อรับสตริงที่เข้ารหัสที่เรียกว่าโทเค็นที่ให้สิทธิ์ผู้ใช้การดำเนินการ เพื่อเข้าถึงบริการ

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

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

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

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

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

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

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

จัดการคำขอการให้สิทธิ์

เมื่อการดำเนินการของคุณต้องทำการลิงก์บัญชีผ่านรหัสการให้สิทธิ์ 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 คือรหัสในหน้าการตั้งค่าโปรเจ็กต์ ของคอนโซลการดำเนินการ

  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 เหมือนกัน กับค่าที่ใช้ในคำขอการให้สิทธิ์เริ่มต้น
  3. หากยืนยันเกณฑ์ข้างต้นทั้งหมดไม่ได้ ให้แสดงผล HTTP 400 ข้อผิดพลาด "คำขอไม่ถูกต้อง" ที่มี {"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 ข้อผิดพลาด "คำขอไม่ถูกต้อง" ที่มี {"error": "invalid_grant"} เป็นเนื้อความ
  4. หรือใช้รหัสผู้ใช้จากโทเค็นการรีเฟรชเพื่อสร้างการเข้าถึง โทเค็น โทเค็นเหล่านี้จะเป็นค่าสตริงใดก็ได้ แต่จะต้องไม่ซ้ำกัน ผู้ใช้และไคลเอ็นต์ที่ใช้โทเค็น โดยต้องคาดเดาไม่ได้ สำหรับโทเค็นเพื่อการเข้าถึง ให้บันทึกเวลาหมดอายุของโทเค็นด้วย (โดยทั่วไปคือ 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 มีโทเค็นเพื่อการเข้าถึง ก่อนอื่นให้ตรวจสอบว่าโทเค็นเพื่อการเข้าถึงถูกต้อง (และยังไม่หมดอายุ) แล้วจึงเรียกข้อมูลบัญชีผู้ใช้ที่เชื่อมโยงจากฐานข้อมูล