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

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

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

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

ทางเลือก

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

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

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

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

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

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

1. Open the API Library ใน Google API Console
2. If prompted, select a project, or create a new one.
3. ซึ่ง API Library แสดง API ทั้งหมดที่พร้อมใช้งาน โดยจัดกลุ่มตามตระกูลผลิตภัณฑ์ และความนิยม หากไม่เห็น API ที่ต้องการเปิดใช้ในรายการ ให้ใช้การค้นหาเพื่อ ค้นหา หรือคลิกดูทั้งหมดในกลุ่มผลิตภัณฑ์ที่ API นั้นๆ อยู่
4. เลือก API ที่ต้องการเปิดใช้ แล้วคลิกปุ่มเปิดใช้
5. If prompted, enable billing.
6. If prompted, read and accept the API's Terms of Service.

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

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

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

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

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

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

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

การขอโทเค็นเพื่อการเข้าถึง 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=email%20profile

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

curl -d "client_id=client_id&scope=email%20profile"
https://oauth2.googleapis.com/device/code

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

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

หากคำขอถูกต้อง การตอบกลับจะเป็นออบเจ็กต์ 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 APIs ในนามของผู้ใช้ได้ (พร็อพเพอร์ตี้ 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 ได้ (เช่น เมื่อเรียกใช้ Drive Files API)

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

ตัวอย่าง HTTP GET

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

GET /drive/v2/files HTTP/1.1 Host: www.googleapis.com Authorization: Bearer access_token

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

GET https://www.googleapis.com/drive/v2/files?access_token=access_token

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

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

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

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

curl https://www.googleapis.com/drive/v2/files?access_token=access_token

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

โทเค็นเพื่อการเข้าถึงจะหมดอายุเป็นระยะๆ และกลายเป็นข้อมูลเข้าสู่ระบบที่ไม่ถูกต้องสำหรับคำขอ 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& 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 สำหรับอุปกรณ์เฉพาะขอบเขตต่อไปนี้

OpenID Connect การลงชื่อเข้าใช้ด้วย Google

• email
• openid
• profile

Drive API

• https://www.googleapis.com/auth/drive.appdata
• https://www.googleapis.com/auth/drive.file

YouTube API

• https://www.googleapis.com/auth/youtube
• https://www.googleapis.com/auth/youtube.readonly

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

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

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

การติดตั้งใช้งานการป้องกันแบบครอบคลุมหลายบริการ

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

ตัวอย่างประเภทเหตุการณ์ที่บริการการปกป้องข้ามบัญชีของ Google ส่งไปยังแอปของคุณมีดังนี้

• https://schemas.openid.net/secevent/risc/event-type/sessions-revoked
• https://schemas.openid.net/secevent/oauth/event-type/token-revoked
• https://schemas.openid.net/secevent/risc/event-type/account-disabled

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