การใช้ OAuth 2.0 เพื่อเข้าถึง Google API

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

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

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

ขั้นตอนเบื้องต้น

แอปพลิเคชันทั้งหมดจะทำตามรูปแบบพื้นฐานเมื่อเข้าถึง Google API โดยใช้ OAuth 2.0 โดยภาพรวม คุณต้องทำตาม 5 ขั้นตอนต่อไปนี้

1. รับข้อมูลเข้าสู่ระบบ OAuth 2.0 จากคอนโซล Google API

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

คุณต้องสร้างไคลเอ็นต์ OAuth ที่เหมาะกับแพลตฟอร์มที่แอปจะทำงาน เช่น

  • สำหรับแอป Android ให้ใช้ประเภทแอปพลิเคชัน Android
  • สำหรับแอป iOS ให้ใช้ประเภทแอปพลิเคชัน iOS
  • desktop_windows สำหรับแอปบนเดสก์ท็อป (เช่น แอปพลิเคชัน Windows, macOS หรือ Linux หรือเครื่องมือ CLI) ให้ใช้แอปพลิเคชันประเภทแอปบนเดสก์ท็อป
  • โค้ด สำหรับฝั่งเซิร์ฟเวอร์หรือเว็บแอป JavaScript ให้ใช้ประเภทแอปพลิเคชันเว็บแอปพลิเคชัน อย่าใช้ประเภทแอปพลิเคชันนี้กับแอปพลิเคชันอื่นๆ เช่น แอปที่มาพร้อมเครื่องหรือแอปบนอุปกรณ์เคลื่อนที่
  • chrome_extension สำหรับส่วนขยาย Chrome ให้ใช้ประเภทแอปพลิเคชัน Chrome Extension
  • tv สำหรับอุปกรณ์อินพุตที่มีข้อจำกัด เช่น ทีวีหรืออุปกรณ์แบบฝัง ให้ใช้ประเภทแอปพลิเคชันทีวีและอุปกรณ์ที่มีข้อจำกัดในการป้อนข้อมูล
  • โฮสต์ สำหรับการโต้ตอบระหว่างเซิร์ฟเวอร์กับเซิร์ฟเวอร์ ให้ใช้บัญชีบริการ ไม่จำเป็นต้องใช้รหัสไคลเอ็นต์ OAuth

2. รับโทเค็นเพื่อการเข้าถึงจากเซิร์ฟเวอร์การให้สิทธิ์ของ Google

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

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

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

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

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

3. ตรวจสอบขอบเขตของสิทธิ์เข้าถึงที่ผู้ใช้ให้ไว้

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

ขอบเขตที่รวมอยู่ในคำขออาจไม่ตรงกับขอบเขตที่รวมอยู่ในคำตอบ แม้ว่าผู้ใช้จะให้สิทธิ์ขอบเขตที่ขอทั้งหมดก็ตาม โปรดดูเอกสารประกอบของ Google API แต่ละรายการเพื่อดูขอบเขตที่จำเป็นสำหรับการเข้าถึง API อาจจับคู่ค่าสตริงขอบเขตหลายค่ากับขอบเขตการเข้าถึงเดียว โดยแสดงสตริงขอบเขตเดียวกันสำหรับค่าทั้งหมดที่อนุญาตในคำขอ ตัวอย่างเช่น Google People API อาจแสดงผลขอบเขตเป็น https://www.googleapis.com/auth/contacts เมื่อแอปขอให้ผู้ใช้ให้สิทธิ์ขอบเขตเป็น https://www.google.com/m8/feeds/ โดยเมธอด people.updateContact ของ Google People API ต้องใช้ขอบเขตที่ได้รับสิทธิ์เป็น https://www.googleapis.com/auth/contacts

4. ส่งโทเค็นเพื่อการเข้าถึงไปยัง API

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

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

5. รีเฟรชโทเค็นเพื่อการเข้าถึง หากจำเป็น

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

สถานการณ์

สถานการณ์เหล่านี้อธิบายวิธีใช้ OAuth 2.0 เพื่อขอรหัสการให้สิทธิ์และรับโทเค็นเพื่อการเข้าถึงและโทเค็นการรีเฟรชสำหรับแอปพลิเคชันประเภทต่างๆ

แอปพลิเคชันเว็บเซิร์ฟเวอร์

ปลายทาง Google OAuth 2.0 รองรับแอปพลิเคชันเว็บเซิร์ฟเวอร์ที่ใช้ภาษาและเฟรมเวิร์ก เช่น PHP, Java, Go, Python, Ruby และ ASP.NET

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

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

แอปพลิเคชันจะส่งคำขอโทเค็นไปยังเซิร์ฟเวอร์การให้สิทธิ์ของ Google, รับรหัสการให้สิทธิ์, แลกเปลี่ยนรหัสเป็นโทเค็น และใช้โทเค็นเพื่อเรียกปลายทาง Google API

โปรดดูรายละเอียดที่หัวข้อการใช้ OAuth 2.0 สำหรับแอปพลิเคชันเว็บเซิร์ฟเวอร์

แอปพลิเคชันที่ติดตั้ง

ปลายทาง Google OAuth 2.0 รองรับแอปพลิเคชันที่ติดตั้งในอุปกรณ์ต่างๆ เช่น คอมพิวเตอร์ อุปกรณ์เคลื่อนที่ และแท็บเล็ต เมื่อสร้างรหัสไคลเอ็นต์ผ่าน คอนโซล Google API ให้ระบุว่านี่เป็นแอปพลิเคชันที่ติดตั้งไว้ จากนั้นเลือก Android, ส่วนขยาย Chrome, iOS หรือแอปบนเดสก์ท็อปเป็นประเภทแอปพลิเคชัน

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

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

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

แอปพลิเคชันจะส่งคำขอโทเค็นไปยังเซิร์ฟเวอร์การให้สิทธิ์ของ Google, รับรหัสการให้สิทธิ์, แลกเปลี่ยนรหัสเป็นโทเค็น และใช้โทเค็นเพื่อเรียกปลายทาง Google API

โปรดดูรายละเอียดที่หัวข้อให้สิทธิ์เข้าถึงข้อมูลผู้ใช้ Google สำหรับ Android, เข้าถึง Google APIs ในแอป iOS และ OAuth 2.0 สำหรับแอปบนเดสก์ท็อป

แอปพลิเคชันฝั่งไคลเอ็นต์ (JavaScript)

ปลายทาง Google OAuth 2.0 รองรับแอปพลิเคชัน JavaScript ที่ทำงานในเบราว์เซอร์

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

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

แอปพลิเคชัน JS จะส่งคำขอโทเค็นไปยังเซิร์ฟเวอร์การให้สิทธิ์ของ Google, รับโทเค็น, ตรวจสอบโทเค็น และใช้โทเค็นเพื่อเรียกปลายทาง Google API

โปรดดูรายละเอียดที่หัวข้อการใช้ OAuth 2.0 สำหรับแอปพลิเคชันฝั่งไคลเอ็นต์

แอปพลิเคชันในอุปกรณ์ที่มีการป้อนข้อมูลแบบจำกัด

ปลายทาง Google OAuth 2.0 รองรับแอปพลิเคชันที่ทำงานบนอุปกรณ์ที่มีอินพุตจำกัด เช่น คอนโซลเกม กล้องวิดีโอ และเครื่องพิมพ์

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

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

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

ผู้ใช้เข้าสู่ระบบในอุปกรณ์แยกต่างหากที่มีเบราว์เซอร์

โปรดดูรายละเอียดที่หัวข้อการใช้ OAuth 2.0 สำหรับอุปกรณ์

บัญชีบริการ

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

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

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

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

โปรดดูรายละเอียดใน เอกสารประกอบเกี่ยวกับบัญชีบริการ

ขนาดโทเค็น

โทเค็นอาจมีขนาดแตกต่างกันไป โดยมีขีดจำกัดดังนี้

  • code รหัสการให้สิทธิ์
    256 ไบต์
  • contextual_token โทเค็นเพื่อการเข้าถึง
    2048 ไบต์
  • restore_page โทเค็นการรีเฟรช
    512 ไบต์

โทเค็นเพื่อการเข้าถึงที่แสดงผลโดย Security Token Service API ของ Google Cloud มีโครงสร้างคล้ายกับโทเค็นเพื่อการเข้าถึง OAuth 2.0 ของ Google API แต่มีขีดจำกัดขนาดโทเค็นที่แตกต่างกัน ดูรายละเอียดได้ที่ เอกสารประกอบเกี่ยวกับ API

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

การหมดอายุของโทเค็นการรีเฟรช

คุณต้องเขียนโค้ดเพื่อคาดการณ์ความเป็นไปได้ที่โทเค็นการรีเฟรชที่ได้รับอาจใช้งานไม่ได้อีกต่อไป โทเค็นการรีเฟรชอาจหยุดทำงานเนื่องจากสาเหตุใดสาเหตุหนึ่งต่อไปนี้

โปรเจ็กต์ Google Cloud Platform ที่มีหน้าจอขอความยินยอม OAuth ซึ่งกำหนดค่าไว้สำหรับประเภทผู้ใช้ภายนอกและสถานะการเผยแพร่เป็น "กำลังทดสอบ" จะได้รับโทเค็นการรีเฟรชที่หมดอายุใน 7 วัน เว้นแต่ว่าขอบเขต OAuth เพียงอย่างเดียวที่ขอจะเป็นชุดย่อยของชื่อ อีเมล และโปรไฟล์ผู้ใช้ (ผ่านขอบเขต userinfo.email, userinfo.profile, openid หรือเทียบเท่า OpenID Connect)

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

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

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

การจัดการนโยบายการควบคุมเซสชันสำหรับองค์กร Google Cloud Platform (GCP)

ผู้ดูแลระบบขององค์กร GCP อาจกำหนดให้ผู้ใช้ต้องตรวจสอบสิทธิ์ซ้ำบ่อยๆ ขณะเข้าถึงทรัพยากร GCP โดยใช้ฟีเจอร์การควบคุมเซสชันของ Google Cloud นโยบายนี้ส่งผลต่อการเข้าถึงคอนโซล Google Cloud, Google Cloud SDK (หรือที่เรียกว่า gcloud CLI) และแอปพลิเคชัน OAuth ของบุคคลที่สามที่ต้องใช้ขอบเขต Cloud Platform หากผู้ใช้มีนโยบายการควบคุมเซสชันอยู่ เมื่อระยะเวลาเซสชันหมดอายุ การเรียก API ของคุณจะแสดงข้อผิดพลาดคล้ายกับสิ่งที่เกิดขึ้นหากโทเค็นการรีเฟรชถูกเพิกถอน โดยการเรียกจะล้มเหลวพร้อมข้อผิดพลาดประเภท invalid_grant และสามารถใช้ช่อง error_subtype เพื่อแยกความแตกต่างระหว่างโทเค็นที่ถูกเพิกถอนกับความล้มเหลวเนื่องจากนโยบายการควบคุมเซสชัน (เช่น "error_subtype": "invalid_rapt") เนื่องจากระยะเวลาเซสชันอาจจำกัดมาก (ระหว่าง 1 ชั่วโมงถึง 24 ชั่วโมง) สถานการณ์นี้จึงต้องได้รับการจัดการอย่างเหมาะสมโดยการรีสตาร์ทเซสชันการตรวจสอบสิทธิ์

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

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

ไลบรารีของไคลเอ็นต์

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