วิธีการทํางานของการให้สิทธิ์ผู้ใช้

หากคุณยังใหม่หรือไม่คุ้นเคยกับ Google Identity Services หรือการให้สิทธิ์ โปรดเริ่มต้นด้วยการอ่านภาพรวม

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

ขอบเขตการตรวจสอบสิทธิ์เท่านั้น

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

คำและแนวคิดที่สำคัญ

คู่มือเหล่านี้ถือว่าคุณมีความเข้าใจพื้นฐานเกี่ยวกับแนวคิด OAuth 2.0 และมาตรฐาน IETF เช่น RFC6749 เราใช้คำต่อไปนี้ในคู่มือการให้สิทธิ์

  • โทเค็นเพื่อการเข้าถึง คือข้อมูลเข้าสู่ระบบของผู้ใช้แต่ละรายที่ออกโดย Google ซึ่งมีอายุการใช้งานสั้น และใช้เพื่อเรียกใช้ Google API และเข้าถึงข้อมูลผู้ใช้อย่างปลอดภัย
  • รหัสการให้สิทธิ์ คือรหัสชั่วคราวที่ออกโดย Google เพื่อระบุตัวตนของผู้ใช้แต่ละรายที่ลงชื่อเข้าใช้บัญชี Google จากเบราว์เซอร์อย่างปลอดภัย แพลตฟอร์มแบ็กเอนด์ของคุณจะแลกรหัสนี้เป็นโทเค็นการเข้าถึงและโทเค็นเพื่อการรีเฟรช
  • โทเค็นการรีเฟรช คือข้อมูลเข้าสู่ระบบของผู้ใช้แต่ละรายที่ออกโดย Google ซึ่งมีอายุการใช้งานยาวนาน จัดเก็บไว้ในแพลตฟอร์มของคุณอย่างปลอดภัย และใช้เพื่อรับโทเค็นเพื่อการเข้าถึงใหม่ที่ถูกต้องได้แม้ว่าผู้ใช้จะไม่ได้อยู่ก็ตาม
  • ขอบเขต จำกัดโทเค็นไว้ที่ข้อมูลผู้ใช้จำนวนหนึ่งที่กำหนดและจำกัด โปรดดูข้อมูลเพิ่มเติมที่ ขอบเขต OAuth 2.0 สำหรับ Google API
  • โหมดป๊อปอัป คือขั้นตอนรหัสการให้สิทธิ์ที่อิงตาม Callback JavaScript ที่ทำงานในเบราว์เซอร์ของผู้ใช้ Google จะเรียกใช้ Callback Handler ซึ่งมีหน้าที่รับผิดชอบในการส่งรหัสการให้สิทธิ์ไปยังแพลตฟอร์มของคุณ โดยวิธีดำเนินการขึ้นอยู่กับคุณ
  • โหมดเปลี่ยนเส้นทาง คือขั้นตอนรหัสการให้สิทธิ์ที่อิงตามการเปลี่ยนเส้นทาง HTTP ระบบจะเปลี่ยนเส้นทาง User Agent ไปยัง Google ก่อน จากนั้น Google จะเปลี่ยนเส้นทางไปยังปลายทางรหัสการให้สิทธิ์ของแพลตฟอร์มของคุณ ซึ่งรวมถึงรหัส

Google เป็นผู้กำหนดอายุการใช้งานของโทเค็นในฐานะผู้ออก ระยะเวลาที่แน่นอนอาจแตกต่างกันไปเนื่องจากปัจจัยต่างๆ

โฟลว์ OAuth 2.0

เราจะพูดถึง 2 โฟลว์ ได้แก่ โฟลว์แบบโดยนัยและโฟลว์รหัสการให้สิทธิ์ ทั้ง 2 โฟลว์จะแสดงโทเค็นการเข้าถึงที่เหมาะสำหรับการใช้กับ Google API

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

ไลบรารี JavaScript ของ Google Identity Services เป็นไปตามมาตรฐาน OAuth 2.0 เพื่อดำเนินการต่อไปนี้

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

ขั้นตอนทั่วไป

ทั้งโฟลว์แบบโดยนัยและโฟลว์รหัสการให้สิทธิ์เริ่มต้นด้วยวิธีเดียวกัน ดังนี้

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

จากนั้นแต่ละโฟลว์จะสิ้นสุดด้วยขั้นตอนที่แตกต่างกัน

เมื่อใช้ขั้นตอนการให้สิทธิ์โดยนัย

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

เมื่อใช้โฟลว์รหัสการให้สิทธิ์

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

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

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

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

กล่องโต้ตอบความยินยอมของผู้ใช้ที่มีปุ่มยกเลิกหรือดำเนินการต่อและขอบเขตเดียวจะแสดงขึ้นโดยไม่มีช่องทําเครื่องหมาย

รูปที่ 1: กล่องโต้ตอบความยินยอมของผู้ใช้ที่มีขอบเขตเดียว

รูปที่ 2 แสดงกล่องโต้ตอบความยินยอมสำหรับหลายขอบเขต เมื่อมีการขอขอบเขตมากกว่า 1 รายการ คุณต้องใช้ช่องทำเครื่องหมายแต่ละรายการเพื่อให้ผู้ใช้สามารถอนุมัติหรือปฏิเสธแต่ละขอบเขตได้

กล่องโต้ตอบความยินยอมของผู้ใช้ที่มีปุ่มยกเลิกหรือดำเนินการต่อและขอบเขตหลายรายการ โดยแต่ละขอบเขตจะมีตัวเลือกช่องทําเครื่องหมาย

รูปที่ 2: กล่องโต้ตอบความยินยอมของผู้ใช้ที่มีหลายขอบเขต

บัญชีผู้ใช้

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

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

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

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

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

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

ผู้ใช้ดูหรือเพิกถอนความยินยอมได้ทุกเมื่อจากการตั้งค่าบัญชี Google

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

ตัวเลือกการให้สิทธิ์อื่นๆ

อีกทางเลือกหนึ่งคือ เบราว์เซอร์อาจรับโทเค็นเพื่อการเข้าถึงโดยใช้ขั้นตอนการให้สิทธิ์โดยนัยด้วยการเรียกใช้ปลายทาง OAuth 2.0 ของ Google โดยตรงตามที่อธิบายไว้ใน OAuth 2.0 สำหรับ เว็บแอปพลิเคชันฝั่งไคลเอ็นต์

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

ในทั้ง 2 กรณี เราขอแนะนำอย่างยิ่งให้ใช้ไลบรารี Google Identity Services เพื่อลดเวลาและความพยายามในการพัฒนา และเพื่อลดความเสี่ยงด้านความปลอดภัย เช่น ความเสี่ยงที่อธิบายไว้ใน แนวทางปฏิบัติแนะนำด้านความปลอดภัยของ OAuth 2.0