การใช้ 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 ปฏิทิน 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 APIs ในนามของผู้ใช้ปลายทาง และบางครั้งอาจต้องได้รับคํายินยอมจากผู้ใช้)

ข้อมูลเข้าสู่ระบบของบัญชีบริการซึ่งคุณได้รับมาจาก 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 1 บัญชีหรือ 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 ชั่วโมง) โดยต้องไม่เกิน 1 ชั่วโมง

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

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

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

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