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

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

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

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

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

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

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

สถานการณ์

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

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

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

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

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

โปรดดูรายละเอียดที่หัวข้อการใช้ OAuth 2.0 สำหรับแอปพลิเคชันเว็บเซิร์ฟเวอร์

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

ปลายทาง OAuth 2.0 ของ Google รองรับแอปพลิเคชันที่ติดตั้งในอุปกรณ์ต่างๆ เช่น คอมพิวเตอร์ อุปกรณ์เคลื่อนที่ และแท็บเล็ต เมื่อสร้างรหัสไคลเอ็นต์ผ่าน ให้ระบุว่าเป็นแอปพลิเคชันที่ติดตั้งไว้ แล้วเลือก Android, แอป Chrome, iOS, Universal Windows Platform (UWP) หรือแอปบนเดสก์ท็อปเป็นประเภทแอปพลิเคชัน

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

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

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

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

โปรดดูรายละเอียดที่หัวข้อ การใช้ OAuth 2.0 สําหรับแอปพลิเคชันที่ติดตั้ง

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

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

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

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

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

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

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

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