OAuth 2.0 สำหรับแอปพลิเคชันทีวีและอุปกรณ์อินพุตที่จำกัด

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

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

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

ทางเลือก

หากคุณกำลังเขียนแอปสำหรับแพลตฟอร์ม เช่น Android, iOS, macOS, Linux หรือ Windows (รวมถึง Universal Windows Platform) ที่มีสิทธิ์เข้าถึงเบราว์เซอร์และความสามารถในการป้อนข้อมูลแบบเต็ม ให้ใช้โฟลว์ OAuth 2.0 สำหรับแอปพลิเคชันบนอุปกรณ์เคลื่อนที่ และเดสก์ท็อป (คุณควรใช้โฟลว์นั้นแม้ว่าแอปจะเป็นเครื่องมือบรรทัดคำสั่งที่ไม่มีอินเทอร์เฟซแบบกราฟิกก็ตาม)

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

ข้อกำหนดเบื้องต้น

เปิดใช้ API สำหรับโปรเจ็กต์

แอปพลิเคชันใดก็ตามที่เรียกใช้ Google API จะต้องเปิดใช้ API เหล่านั้นใน API Console

วิธีเปิดใช้ API สำหรับโปรเจ็กต์

1. Open the API Library ใน Google API Console
2. If prompted, select a project, or create a new one.
3. ใช้หน้าไลบรารีเพื่อค้นหาและเปิดใช้ YouTube Data API ค้นหา API อื่นๆ ที่แอปพลิเคชันของคุณจะใช้และเปิดใช้ API เหล่านั้นด้วย

สร้างข้อมูลเข้าสู่ระบบการให้สิทธิ์

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

1. Go to the Credentials page.
2. คลิกสร้างไคลเอ็นต์
3. เลือกประเภทแอปพลิเคชัน TV และอุปกรณ์อินพุตที่จำกัด
4. ตั้งชื่อไคลเอ็นต์ OAuth 2.0 แล้วคลิกสร้าง

ระบุขอบเขตการเข้าถึง

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

ก่อนที่จะเริ่มใช้การให้สิทธิ์ OAuth 2.0 เราขอแนะนำให้คุณระบุขอบเขต ที่แอปจะต้องได้รับสิทธิ์เข้าถึง

YouTube Data API เวอร์ชัน 3 ใช้ขอบเขตต่อไปนี้

ดูรายการขอบเขตที่อนุญาตสำหรับแอปหรืออุปกรณ์ที่ติดตั้ง

การขอโทเค็นเพื่อการเข้าถึง OAuth 2.0

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

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

รูปภาพด้านล่างแสดงกระบวนการนี้

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

ขั้นตอนที่ 1: ขอรหัสอุปกรณ์และรหัสผู้ใช้

ในขั้นตอนนี้ อุปกรณ์จะส่งคำขอ HTTP POST ไปยังเซิร์ฟเวอร์การให้สิทธิ์ของ Google ที่ https://oauth2.googleapis.com/device/code ซึ่งระบุแอปพลิเคชันของคุณ รวมถึงขอบเขตการเข้าถึงที่แอปพลิเคชันต้องการเข้าถึงในนามของผู้ใช้ คุณควรดึงข้อมูล URL นี้จากเอกสารการค้นพบโดยใช้ค่าข้อมูลเมตา device_authorization_endpoint ระบุพารามิเตอร์คำขอ HTTP ต่อไปนี้

ตัวอย่าง

ข้อมูลโค้ดต่อไปนี้แสดงคำขอตัวอย่าง

POST /device/code HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=client_id&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.force-ssl

ตัวอย่างนี้แสดงcurlคำสั่งในการส่งคำขอเดียวกัน

curl -d "client_id=client_id&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.force-ssl" \
     https://oauth2.googleapis.com/device/code

ขั้นตอนที่ 2: จัดการการตอบกลับของเซิร์ฟเวอร์การให้สิทธิ์

เซิร์ฟเวอร์การให้สิทธิ์จะแสดงการตอบกลับอย่างใดอย่างหนึ่งต่อไปนี้

การตอบกลับที่สำเร็จ

หากคำขอถูกต้อง การตอบกลับจะเป็นออบเจ็กต์ JSON ที่มีพร็อพเพอร์ตี้ต่อไปนี้

ข้อมูลโค้ดต่อไปนี้แสดงตัวอย่างการตอบกลับ

{
  "device_code": "4/4-GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8",
  "user_code": "GQVQ-JKEC",
  "verification_url": "https://www.google.com/device",
  "expires_in": 1800,
  "interval": 5
}

การตอบกลับเมื่อเกินโควต้า

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

{
  "error_code": "rate_limit_exceeded"
}

ในกรณีดังกล่าว ให้ใช้กลยุทธ์การหยุดชั่วคราวเพื่อลดอัตราคำขอ

ขั้นตอนที่ 3: แสดงรหัสผู้ใช้

แสดง verification_url และ user_code ที่ได้รับในขั้นตอนที่ 2 ต่อผู้ใช้ ทั้ง 2 ค่าสามารถมีอักขระที่พิมพ์ได้จากชุดอักขระ US-ASCII เนื้อหา ที่คุณแสดงต่อผู้ใช้ควรแนะนำให้ผู้ใช้ไปที่ verification_url ในอุปกรณ์อื่นและป้อน user_code

ออกแบบอินเทอร์เฟซผู้ใช้ (UI) โดยคำนึงถึงกฎต่อไปนี้

• user_code
  • ต้องแสดง user_code ในช่องที่รองรับอักขระขนาด "W" 15 ตัว ได้ กล่าวคือ หากคุณแสดงโค้ด WWWWWWWWWWWWWWW ได้อย่างถูกต้อง แสดงว่า UI ของคุณใช้ได้ และเราขอแนะนำให้ใช้ค่าสตริงดังกล่าวเมื่อทดสอบวิธีที่ user_code แสดงใน UI
  • user_code คำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ และไม่ควรแก้ไขไม่ว่าในลักษณะใดก็ตาม เช่น การเปลี่ยนตัวพิมพ์เล็ก/ตัวพิมพ์ใหญ่หรือการแทรกอักขระการจัดรูปแบบอื่นๆ
• verification_url
  • พื้นที่ที่คุณแสดง verification_url ต้องกว้างพอที่จะ รองรับสตริง URL ที่มีความยาว 40 อักขระ
  • คุณไม่ควรแก้ไข verification_url ไม่ว่าในทางใดก็ตาม ยกเว้นในกรณีที่ต้องการ นำรูปแบบออกเพื่อแสดง หากวางแผนที่จะนำรูปแบบ (เช่น https://) ออกจาก URL เพื่อเหตุผลในการแสดงผล โปรดตรวจสอบว่าแอปของคุณรองรับทั้งรูปแบบ http และ https

ขั้นตอนที่ 4: ตรวจสอบเซิร์ฟเวอร์การให้สิทธิ์ของ Google

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

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

URL ของปลายทางที่จะสำรวจคือ https://oauth2.googleapis.com/token คำขอการสำรวจ มีพารามิเตอร์ต่อไปนี้

ตัวอย่าง

ข้อมูลโค้ดต่อไปนี้แสดงคำขอตัวอย่าง

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=client_id&
client_secret=client_secret&
device_code=device_code&
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code

ตัวอย่างนี้แสดงcurlคำสั่งในการส่งคำขอเดียวกัน

curl -d "client_id=client_id&client_secret=client_secret& \
         device_code=device_code& \
         grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code" \
         -H "Content-Type: application/x-www-form-urlencoded" \
         https://oauth2.googleapis.com/token

ขั้นตอนที่ 5: ผู้ใช้ตอบกลับคำขอสิทธิ์เข้าถึง

รูปภาพต่อไปนี้แสดงหน้าเว็บที่คล้ายกับสิ่งที่ผู้ใช้เห็นเมื่อไปยัง verification_url ที่คุณแสดงในขั้นตอนที่ 3

หลังจากป้อน user_code และลงชื่อเข้าใช้ Google (หากยังไม่ได้ลงชื่อเข้าใช้) ผู้ใช้จะเห็นหน้าจอขอความยินยอมเหมือนกับที่แสดงด้านล่าง

ขั้นตอนที่ 6: จัดการการตอบกลับคำขอการสำรวจ

เซิร์ฟเวอร์การให้สิทธิ์ของ Google จะตอบสนองต่อคำขอการสำรวจแต่ละรายการด้วยการตอบกลับอย่างใดอย่างหนึ่งต่อไปนี้

ให้สิทธิ์เข้าถึงแล้ว

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

ในกรณีนี้ การตอบกลับจาก API จะมีช่องต่อไปนี้

ข้อมูลโค้ดต่อไปนี้แสดงตัวอย่างการตอบกลับ

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "openid https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email",
  "token_type": "Bearer",
  "refresh_token": "1/xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

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

การเข้าถึงถูกปฏิเสธ

หากผู้ใช้ปฏิเสธที่จะให้สิทธิ์เข้าถึงอุปกรณ์ การตอบสนองของเซิร์ฟเวอร์จะมีรหัสสถานะการตอบสนอง HTTP 403 (Forbidden) การตอบสนองจะมีข้อผิดพลาดต่อไปนี้

{
  "error": "access_denied",
  "error_description": "Forbidden"
}

รอการให้สิทธิ์

หากผู้ใช้ยังไม่เสร็จสิ้นขั้นตอนการให้สิทธิ์ เซิร์ฟเวอร์จะแสดงรหัสสถานะการตอบกลับ HTTP 428 (Precondition Required) การตอบกลับจะมีข้อผิดพลาดต่อไปนี้

{
  "error": "authorization_pending",
  "error_description": "Precondition Required"
}

การสำรวจบ่อยเกินไป

หากอุปกรณ์ส่งคำขอแบบสำรวจบ่อยเกินไป เซิร์ฟเวอร์จะแสดง403 รหัสสถานะการตอบกลับ HTTP (Forbidden) การตอบกลับจะมีข้อผิดพลาดต่อไปนี้

{
  "error": "slow_down",
  "error_description": "Forbidden"
}

ข้อผิดพลาดอื่นๆ

นอกจากนี้ เซิร์ฟเวอร์การให้สิทธิ์ยังแสดงข้อผิดพลาดหากคำขอการสำรวจขาดพารามิเตอร์ที่จำเป็น หรือมีค่าพารามิเตอร์ที่ไม่ถูกต้อง คำขอเหล่านี้มักจะมีรหัสสถานะการตอบกลับ HTTP 400 (Bad Request) หรือ 401 (Unauthorized) ข้อผิดพลาดเหล่านี้ ได้แก่

การเรียก Google APIs

หลังจากที่แอปพลิเคชันได้รับโทเค็นเพื่อการเข้าถึงแล้ว คุณจะใช้โทเค็นเพื่อเรียก Google API ในนามของบัญชีผู้ใช้ที่ระบุได้ หากได้รับขอบเขตการเข้าถึงที่ API ต้องการ โดยให้ใส่โทเค็นเพื่อการเข้าถึงในคำขอไปยัง API โดยใส่พารามิเตอร์การค้นหา access_token หรือค่าส่วนหัว HTTP Authorization Bearer หากเป็นไปได้ เราขอแนะนำให้ใช้ส่วนหัว HTTP เนื่องจากสตริงการค้นหามักจะปรากฏในบันทึกของเซิร์ฟเวอร์ ในกรณีส่วนใหญ่ คุณสามารถใช้ไลบรารีของไคลเอ็นต์เพื่อตั้งค่าการเรียกไปยัง Google API ได้ (เช่น เมื่อเรียกใช้ YouTube Live Streaming API)

โปรดทราบว่า YouTube Live Streaming API ไม่รองรับโฟลว์บัญชีบริการ เนื่องจากไม่มีวิธีลิงก์บัญชีบริการกับบัญชี YouTube การพยายามให้สิทธิ์คำขอด้วยขั้นตอน นี้จะทำให้เกิดข้อผิดพลาด NoLinkedYouTubeAccount

คุณลองใช้ Google APIs ทั้งหมดและดูขอบเขตของ API ได้ที่ OAuth 2.0 Playground

ตัวอย่าง HTTP GET

การเรียกไปยัง liveBroadcasts.list ปลายทาง (YouTube Live Streaming API) โดยใช้ส่วนหัว HTTP Authorization: Bearer อาจมีลักษณะดังนี้ โปรดทราบว่าคุณต้องระบุโทเค็นเพื่อการเข้าถึงของคุณเอง

GET /youtube/v3/liveBroadcasts?part=id%2Csnippet&mine=true HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

ต่อไปนี้คือการเรียก API เดียวกันสำหรับผู้ใช้ที่ได้รับการตรวจสอบสิทธิ์โดยใช้พารามิเตอร์สตริงการค้นหา access_token

GET https://www.googleapis.com/youtube/v3/liveBroadcasts?access_token=access_token&part=id%2Csnippet&mine=true

ตัวอย่างของ curl

คุณทดสอบคำสั่งเหล่านี้ได้ด้วยแอปพลิเคชันบรรทัดคำสั่ง curl ต่อไปนี้คือตัวอย่างที่ใช้ตัวเลือกส่วนหัว HTTP (แนะนำ)

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/v3/liveBroadcasts?part=id%2Csnippet&mine=true

หรืออีกทางเลือกหนึ่งคือตัวเลือกพารามิเตอร์สตริงการค้นหา

curl https://www.googleapis.com/youtube/v3/liveBroadcasts?access_token=access_token&part=id%2Csnippet&mine=true

การรีเฟรชโทเค็นเพื่อการเข้าถึง

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

หากต้องการรีเฟรชโทเค็นการเข้าถึง แอปพลิเคชันของคุณจะส่งคำขอ HTTPS POST ไปยังเซิร์ฟเวอร์การให้สิทธิ์ของ Google (https://oauth2.googleapis.com/token) ซึ่งมีพารามิเตอร์ต่อไปนี้

ข้อมูลโค้ดต่อไปนี้แสดงคำขอตัวอย่าง

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=your_client_id&
client_secret=your_client_secret&
refresh_token=refresh_token&
grant_type=refresh_token

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

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

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

การเพิกถอนโทเค็น

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

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

หากต้องการเพิกถอนโทเค็นโดยอัตโนมัติ แอปพลิเคชันของคุณจะส่งคำขอไปยัง https://oauth2.googleapis.com/revoke และรวมโทเค็นเป็นพารามิเตอร์

curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
        https://oauth2.googleapis.com/revoke?token={token}

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

หากการเพิกถอนดำเนินการสำเร็จ รหัสสถานะ HTTP ของการตอบกลับจะเป็น 200 สำหรับเงื่อนไขข้อผิดพลาด ระบบจะแสดงรหัสสถานะ HTTP 400 พร้อมกับรหัสข้อผิดพลาด

ขอบเขตที่อนุญาต

ระบบรองรับขั้นตอน OAuth 2.0 สำหรับอุปกรณ์เฉพาะขอบเขตต่อไปนี้

การเข้าถึงตามเวลา

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

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