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

หมายเหตุ: การติดตั้งใช้งาน OAuth 2.0 ของ Google อยู่ภายใต้การควบคุมของ นโยบาย OAuth 2.0

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

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

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

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

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

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

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

• สำหรับแอป Android ให้ใช้ Android
• สำหรับแอป iOS และ macOS ให้ใช้ ประเภทไคลเอ็นต์ iOS
• code สำหรับ ฝั่งเซิร์ฟเวอร์ หรือ เว็บแอป JavaScript ให้ใช้ ประเภทไคลเอ็นต์ เว็บแอปพลิเคชัน อย่าใช้ไคลเอ็นต์ประเภทนี้กับแอปพลิเคชันอื่นๆ เช่น แอปเนทีฟหรือแอปบนอุปกรณ์เคลื่อนที่
• chrome_extension สำหรับส่วนขยาย Chrome ให้ใช้ประเภทไคลเอ็นต์ส่วนขยาย Chrome
• tv สำหรับอุปกรณ์อินพุตที่จำกัดเช่น ทีวีหรืออุปกรณ์แบบฝัง ให้ใช้ประเภทไคลเอ็นต์ทีวีและอุปกรณ์อินพุตที่จำกัด
• host สำหรับการโต้ตอบระหว่างเซิร์ฟเวอร์กับเซิร์ฟเวอร์ ให้ใช้บัญชีบริการ โดยไม่จำเป็นต้องใช้รหัสไคลเอ็นต์ 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 อาจไปอยู่ในไฟล์บันทึกที่ไม่ปลอดภัยอย่างสมบูรณ์ นอกจากนี้ การหลีกเลี่ยงการสร้างชื่อพารามิเตอร์ URI ที่ไม่จำเป็นยังเป็นแนวทางปฏิบัติแนะนำของ REST ด้วย

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

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

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

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

Scenarios

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

บัญชีบริการ

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

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

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

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

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

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

ขนาดโทเค็น

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

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

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

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

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

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

• shield_locked ผู้ใช้ เพิกถอนสิทธิ์เข้าถึงแอปของคุณ
• ไม่มีการใช้โทเค็นการรีเฟรชมา 6 เดือนแล้ว
• ผู้ใช้เปลี่ยนรหัสผ่านและโทเค็นการรีเฟรชมีขอบเขต Gmail
• บัญชีผู้ใช้มีโทเค็นการรีเฟรชที่ได้รับ (ใช้งานได้) เกินจำนวนสูงสุด
• ผู้ใช้ให้สิทธิ์เข้าถึงแอปของคุณตามระยะเวลาที่กำหนด และสิทธิ์เข้าถึงหมดอายุแล้ว
• หากผู้ดูแลระบบ ตั้งค่าบริการใดก็ตามที่ขอในขอบเขตของแอปเป็น "จำกัด" (ข้อผิดพลาด คือ admin_policy_enforced)
• cloud_lock สำหรับ Google Cloud Platform API \- เซสชันอาจมีระยะเวลานานเกินกว่าที่ผู้ดูแลระบบกำหนด

โปรเจ็กต์ 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 ง่ายขึ้น เราจะเพิ่มฟีเจอร์เพิ่มเติมลงในไลบรารีเมื่อเวลาผ่านไป

• Google Auth Library for Java
• Google API Client Library for Python
• Google API Client Library for Dart
• Google API Client Library for Go
• Google API Client Library for .NET
• Google API Client Library for Ruby
• Google API Client Library for PHP
• Google API Client Library for JavaScript
• GTMAppAuth - OAuth Client Library for Mac and iOS