Google มุ่งมั่นที่จะพัฒนาความเท่าเทียมทางเชื้อชาติให้กับชุมชนคนผิวดำ ดูวิธีการ
หน้านี้ได้รับการแปลโดย Cloud Translation API
Switch to English

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

Google API ใช้ โปรโตคอล 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 ไม่ต้องการความลับ แต่มีแอปพลิเคชันเว็บเซิร์ฟเวอร์

2. รับโทเค็นการเข้าถึงจากเซิร์ฟเวอร์การอนุญาตของ Google

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

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

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

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

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

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

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

ขนาดโทเค็น

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

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

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

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

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

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

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

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

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