การใช้ 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 ไม่ได้มีข้อมูลลับ แต่แอปพลิเคชันเว็บเซิร์ฟเวอร์จําเป็น

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

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

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

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

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

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

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 APIs เช่น 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 ไบต์

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

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

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

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

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

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

ปัจจุบันมีโทเค็นการรีเฟรชได้ไม่เกิน 50 รายการต่อบัญชี 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_token ประเภทของข้อผิดพลาดย่อยอาจแยกความแตกต่างระหว่างโทเค็นการเพิกถอนและความล้มเหลวเนื่องจากนโยบายการควบคุมเซสชัน เนื่องจากเซสชันจะถูกจํากัดอย่างมาก (ระหว่าง 1 ชั่วโมงถึง 24 ชั่วโมง) สถานการณ์นี้จึงต้องได้รับการจัดการอย่างราบรื่นโดยเริ่มต้นเซสชันการตรวจสอบสิทธิ์อีกครั้ง

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

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

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

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