การใช้ 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 เมื่อคุณทําตามระดับสูง ให้ทําตามขั้นตอนต่อไปนี้

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 ปฏิทิน API ได้หลายครั้งสําหรับการดําเนินการที่คล้ายกัน

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

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

สถานการณ์

เว็บแอปพลิเคชัน

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

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

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

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

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