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

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

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

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

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

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

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

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

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

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

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

สถานการณ์

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

อุปกรณ์ปลายทางของ 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 Console ให้ระบุว่าเป็นแอปพลิเคชันที่ติดตั้ง จากนั้นเลือกประเภทแอปพลิเคชันเป็น Android, แอป Chrome, iOS, Universal Windows Platform (UWP) หรือแอปบนเดสก์ท็อป

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

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

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

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

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

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

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

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

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

ขนาดโทเค็น

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

  • รหัสการให้สิทธิ์: 256 ไบต์
  • โทเค็นเพื่อการเข้าถึง: 2048 ไบต์
  • โทเค็นการรีเฟรช: 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 Console, Google Cloud SDK (หรือที่เรียกว่า gcloud CLI) และแอปพลิเคชัน OAuth ของบุคคลที่สามที่ต้องใช้ขอบเขต Cloud Platform หากผู้ใช้มีนโยบายการควบคุมเซสชันอยู่ เมื่อถึงวันหมดอายุของระยะเวลาเซสชัน การเรียก API จะเกิดข้อผิดพลาดคล้ายกับสิ่งที่จะเกิดขึ้นเมื่อมีการเพิกถอนโทเค็นการรีเฟรช การเรียกจะล้มเหลวโดยมีข้อผิดพลาดประเภท invalid_grant ช่อง error_subtype สามารถใช้เพื่อแยกแยะระหว่างโทเค็นที่เพิกถอนกับความล้มเหลวเนื่องจากนโยบายการควบคุมเซสชันได้ (เช่น "error_subtype": "invalid_rapt") เนื่องจากระยะเวลาเซสชันจะมีการจัดการได้อย่างจำกัดมาก (ระหว่าง 4 ชั่วโมงในการตรวจสอบสิทธิ์จะต้องจัดการเซสชันใหม่อย่างผ่อนปรน 1 ชั่วโมง) การเริ่มเซสชันจะต้องถูกจำกัดอย่างมาก 1 ชั่วโมง การเริ่มเซสชันจะต้องถูกจำกัดอย่างมาก (ระหว่าง 4 ชั่วโมง) การเริ่มเซสชันจะต้องจัดการได้อย่างจำกัด

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

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

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

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