Google มุ่งมั่นที่จะพัฒนาความเท่าเทียมทางเชื้อชาติสำหรับชุมชนคนผิวดำ ดูวิธีการ

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

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

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

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

ขั้นตอนพื้นฐาน

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

1. ขอรับ OAuth 2.0 ข้อมูลประจำตัวจาก Google API Console

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

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

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

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

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

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

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

3. ตรวจสอบขอบเขตการเข้าถึงที่ได้รับจากผู้ใช้

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

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

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

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

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

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

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

สถานการณ์

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

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

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

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

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

ดูรายละเอียด การใช้ OAuth 2.0 สำหรับการใช้งานเว็บเซิร์ฟเวอร์

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

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

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

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

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

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

ดูรายละเอียด การใช้ OAuth 2.0 สำหรับการติดตั้งโปรแกรม

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

ตำแหน่งข้อมูล OAuth 2.0 ของ Google รองรับแอปพลิเคชัน JavaScript ที่ทำงานในเบราว์เซอร์

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

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

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

ดูรายละเอียด การใช้ OAuth 2.0 สำหรับการประยุกต์ใช้ฝั่งไคลเอ็นต์

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

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

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

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

สำหรับรายละเอียดโปรดดูที่ เอกสารบริการบัญชี

ขนาดโทเค็น

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

  • รหัสการให้สิทธิ์: 256 ไบต์
  • โทเค็นการเข้าถึง: 2048 ไบต์
  • โทเค็นการรีเฟรช: 512 ไบต์

โทเค็นกลับโดย Google Cloud ของ การรักษาความปลอดภัย Token API บริการ มีโครงสร้างคล้ายกับ Google API OAuth 2.0 ราชสกุลเข้าถึง แต่มีข้อ จำกัด ที่แตกต่างกันขนาดโทเค็น สำหรับรายละเอียดโปรดดู เอกสาร API

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

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

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

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

โครงการ Google Cloud Platform ที่มีหน้าจอคำยินยอม OAuth ที่กำหนดค่าไว้สำหรับประเภทผู้ใช้ภายนอก และสถานะการเผยแพร่เป็น "การทดสอบ" จะได้รับโทเค็นการรีเฟรชซึ่งจะหมดอายุใน 7 วัน

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

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

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

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

ผู้ดูแลระบบขององค์กร GCP อาจต้อง reauthentication บ่อยของผู้ใช้ในขณะที่พวกเขาเข้าถึงทรัพยากร GCP โดยใช้ คุณลักษณะ Google Cloud ควบคุมเซสชั่น นี้ส่งผลกระทบต่อการเข้าถึงนโยบายกับ Google Cloud คอนโซลที่ Google Cloud SDK (ยังเป็นที่รู้จักในฐานะ CLI GCloud) และโปรแกรมใด ๆ OAuth ของบุคคลที่สามที่ต้องมีขอบเขตแพลตฟอร์มคลาวด์ หากผู้ใช้มีนโยบายควบคุมเซสชั่นในสถานที่นั้นในระยะเวลาหมดอายุของเซสชั่นที่เรียก API ของคุณจะเกิดข้อผิดพลาดออกมาคล้ายกับสิ่งที่จะเกิดขึ้นถ้ารีเฟรชโทเค็นถูกเพิกถอน - สายจะล้มเหลวด้วยข้อผิดพลาดประเภท invalid_token ; ประเภทข้อผิดพลาดย่อยสามารถใช้เพื่อแยกแยะระหว่างโทเค็นการเพิกถอนและความล้มเหลวเนื่องจากนโยบายการควบคุมเซสชัน เนื่องจากระยะเวลาของเซสชันอาจมีจำกัดมาก (ระหว่าง 1 ชั่วโมงถึง 24 ชั่วโมง) สถานการณ์นี้จึงต้องได้รับการจัดการอย่างงดงามด้วยการเริ่มเซสชันการตรวจสอบสิทธิ์ใหม่

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

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

ห้องสมุดลูกค้า

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