เลือกรูปแบบการให้สิทธิ์ผู้ใช้

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

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

ไลบรารี GIS ทำงานในเบราว์เซอร์ที่รองรับเหล่านี้ในอุปกรณ์ของผู้ใช้ แต่ไม่ได้มีไว้สำหรับใช้กับเฟรมเวิร์ก JavaScript ฝั่งเซิร์ฟเวอร์ เช่น Node.js ดังนั้นให้ใช้ไลบรารีของไคลเอ็นต์ Node.js ของ Google แทน

คู่มือนี้ครอบคลุมเฉพาะหัวข้อการให้สิทธิ์และการแชร์ข้อมูล โดยจะไม่ตรวจสอบ การตรวจสอบสิทธิ์ผู้ใช้ แต่ให้ดูลงชื่อเข้าใช้ด้วย Google และคำแนะนำการย้ายข้อมูล จาก Google Sign-In สำหรับการลงชื่อสมัครใช้และลงชื่อเข้าใช้ของผู้ใช้

การตัดสินใจว่าห้องสมุด GIS เหมาะกับคุณหรือไม่

คุณต้องเลือกว่าการใช้ไลบรารีของ Google หรือการสร้างไลบรารีของคุณเองเหมาะกับความต้องการของคุณมากที่สุด ภาพรวมของฟีเจอร์และฟังก์ชันการทำงาน

  • ไลบรารี JavaScript ของ Google Identity Services จะใช้
    • ขั้นตอนความยินยอมที่อิงตามกล่องโต้ตอบเพื่อลดการเปลี่ยนเส้นทาง ซึ่งช่วยให้ผู้ใช้ อยู่ในเว็บไซต์ของคุณตลอดกระบวนการให้สิทธิ์
    • ฟีเจอร์ความปลอดภัย เช่น การปลอมแปลงคำขอแบบข้ามเว็บไซต์ (CRSF)
    • เมธอดตัวช่วยในการขอขอบเขตแต่ละรายการและยืนยันความยินยอมของผู้ใช้
    • การจัดการข้อผิดพลาดและลิงก์เอกสารที่เข้าใจง่ายสำหรับวิศวกรใช้ในระหว่างการพัฒนาซอฟต์แวร์ และสำหรับผู้เข้าชมเว็บไซต์ในภายหลัง
  • เมื่อติดตั้งใช้งานโดยไม่มีไลบรารีบริการระบุตัวตน คุณมีหน้าที่รับผิดชอบในเรื่องต่อไปนี้
    • การจัดการคำขอและการตอบกลับด้วยปลายทาง OAuth 2.0 ของ Google รวมถึงการเปลี่ยนเส้นทาง
    • การเพิ่มประสิทธิภาพประสบการณ์ของผู้ใช้
    • การติดตั้งใช้งานฟีเจอร์ความปลอดภัยเพื่อตรวจสอบคำขอ คำตอบ และ เพื่อป้องกัน CSRF
    • วิธีเพื่อยืนยันว่าผู้ใช้ได้ให้ความยินยอมสำหรับขอบเขตที่ขอแล้ว
    • การจัดการรหัสข้อผิดพลาดของ OAuth 2.0 การสร้างข้อความที่มนุษย์อ่านได้ และ ลิงก์ไปยังความช่วยเหลือสำหรับผู้ใช้

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

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

คุณจะต้องเลือกขั้นตอนการให้สิทธิ์ OAuth 2.0 อย่างใดอย่างหนึ่งจาก 2 ขั้นตอน ได้แก่ ขั้นตอนแบบโดยนัยหรือขั้นตอนรหัสการให้สิทธิ์ ไม่ว่าคุณจะตัดสินใจใช้ไลบรารี JavaScript ของ Google Identity Services หรือสร้างไลบรารีของคุณเองก็ตาม

ทั้ง 2 โฟลว์จะส่งผลให้ได้โทเค็นเพื่อการเข้าถึงซึ่งใช้เรียก Google APIs ได้

ความแตกต่างหลักระหว่าง 2 โฟลว์มีดังนี้

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

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

การเปรียบเทียบขั้นตอน OAuth 2.0

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