การใช้ 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 ที่เหมาะสมกับแพลตฟอร์มที่แอปจะทำงาน เช่น

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/ วิธีการของ Google People API people.updateContact ต้องมีขอบเขตที่ได้รับอนุญาตเป็น 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 สำหรับแอปพลิเคชันเว็บ เซิร์ฟเวอร์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

บัญชีบริการ

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

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

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

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

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

ขนาดโทเค็น

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

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

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

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

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

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

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

ปัจจุบันมีการจำกัดโทเค็นการรีเฟรช 100 รายการต่อบัญชี Google 1 บัญชีต่อรหัสไคลเอ็นต์ 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 ง่ายขึ้น และเราจะเพิ่มฟีเจอร์อื่นๆ ลงในคลังเมื่อเวลาผ่านไป