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

หมายเหตุสำคัญ: ขั้นตอน OAuth 2.0 นี้รองรับขอบเขตที่จำกัด

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

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

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

ทางเลือกอื่นๆ

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

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

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

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

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

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

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

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

1. ไปที่หน้าลูกค้า
2. คลิกสร้างไคลเอ็นต์
3. เลือกประเภทแอปพลิเคชันทีวีและอุปกรณ์อินพุตแบบจำกัด
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 ต่อไปนี้

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

ตัวอย่าง

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

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

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

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

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

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

พร็อพเพอร์ตี้
device_code	ค่าที่ Google กำหนดโดยไม่ซ้ำกันเพื่อระบุอุปกรณ์ที่เรียกใช้แอปที่ขอสิทธิ์ให้สิทธิ์ ผู้ใช้จะให้สิทธิ์อุปกรณ์นั้นจากอุปกรณ์อื่นที่มีความสามารถในการป้อนข้อมูลที่สมบูรณ์ยิ่งขึ้น เช่น ผู้ใช้อาจใช้แล็ปท็อปหรือโทรศัพท์มือถือเพื่อให้สิทธิ์แอปที่ทำงานบนทีวี ในกรณีนี้ device_code จะระบุทีวี โค้ดนี้ช่วยให้อุปกรณ์ที่เรียกใช้แอปสามารถระบุได้อย่างปลอดภัยว่าผู้ใช้ได้ให้หรือปฏิเสธการเข้าถึง
expires_in	ระยะเวลาเป็นวินาทีที่ device_code และ user_code มีผล หากผู้ใช้ไม่ดำเนินการตามขั้นตอนการให้สิทธิ์จนเสร็จภายในระยะเวลาดังกล่าว และอุปกรณ์ของคุณไม่ได้ทำการสำรวจเพื่อดึงข้อมูลเกี่ยวกับการตัดสินใจของผู้ใช้ คุณอาจต้องเริ่มกระบวนการนี้ใหม่ตั้งแต่ขั้นตอนที่ 1
interval	ระยะเวลาเป็นวินาทีที่อุปกรณ์ควรรอระหว่างคำขอการสำรวจความคิดเห็น ตัวอย่างเช่น หากค่าเป็น 5 อุปกรณ์ควรส่งคำขอการสำรวจไปยังเซิร์ฟเวอร์การให้สิทธิ์ของ Google ทุกๆ 5 วินาที ดูรายละเอียดเพิ่มเติมได้ที่ขั้นตอนที่ 3
user_code	ค่าที่คำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ซึ่งระบุขอบเขตที่แอปพลิเคชันขอสิทธิ์เข้าถึงให้ Google ทราบ อินเทอร์เฟซผู้ใช้จะแนะนำให้ผู้ใช้ป้อนค่านี้ในอุปกรณ์แยกต่างหากที่มีความสามารถในการป้อนข้อมูลที่สมบูรณ์ยิ่งขึ้น จากนั้น Google จะใช้ค่านี้เพื่อแสดงชุดขอบเขตที่ถูกต้องเมื่อแจ้งให้ผู้ใช้ให้สิทธิ์เข้าถึงแอปพลิเคชันของคุณ
verification_url	URL ที่ผู้ใช้ต้องไปในอุปกรณ์อื่นเพื่อป้อน user_code และให้สิทธิ์หรือปฏิเสธการเข้าถึงแอปพลิเคชันของคุณ อินเทอร์เฟซผู้ใช้จะแสดงค่านี้ด้วย

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

{
  "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"
}

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

ขั้นตอนที่ 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

คำเตือน: ค่าทั้ง 2 ค่านี้อาจมีการเปลี่ยนแปลง และคุณไม่ควรฮาร์ดโค้ดค่าใดค่าหนึ่งในโค้ด ในทำนองเดียวกัน คุณไม่ควรแก้ไขค่าด้วยวิธีอื่นใดนอกเหนือจากการนำรูปแบบออกจาก verification_url

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

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

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

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

พารามิเตอร์
client_id	รหัสไคลเอ็นต์สำหรับแอปพลิเคชันของคุณ คุณดูค่านี้ได้ในหน้าไคลเอ็นต์ของ Cloud Console
client_secret	รหัสลับไคลเอ็นต์สำหรับ client_id ที่ระบุ คุณดูค่านี้ได้ในหน้าไคลเอ็นต์ของ Cloud Console
device_code	device_code ที่เซิร์ฟเวอร์การให้สิทธิ์แสดงผลในขั้นตอนที่ 2
grant_type	ตั้งค่านี้เป็น urn:ietf:params:oauth:grant-type:device_code

ตัวอย่าง

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

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

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

{
  "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"
}

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

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

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

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

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

ข้อผิดพลาด	รหัสสถานะ HTTP	คำอธิบาย
admin_policy_enforced	400	บัญชี Google ไม่สามารถให้สิทธิ์ขอบเขตที่ขออย่างน้อย 1 รายการเนื่องจากนโยบายของผู้ดูแลระบบ Google Workspace ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีที่ผู้ดูแลระบบอาจจำกัดการเข้าถึงขอบเขตจนกว่าจะมีการให้สิทธิ์เข้าถึงรหัสไคลเอ็นต์ OAuth ของคุณอย่างชัดแจ้งได้ที่บทความช่วยเหลือสำหรับผู้ดูแลระบบ Google Workspace เรื่องควบคุมว่าจะให้แอปของบุคคลที่สามและแอปภายในรายการใดเข้าถึงข้อมูล Google Workspace ได้บ้าง
invalid_client	401	ไม่พบไคลเอ็นต์ OAuth เช่น ข้อผิดพลาดนี้จะเกิดขึ้นหากค่าพารามิเตอร์ client_id ไม่ถูกต้อง ประเภทไคลเอ็นต์ OAuth ไม่ถูกต้อง ตรวจสอบว่าได้ตั้งค่าประเภทแอปพลิเคชันสำหรับรหัสไคลเอ็นต์เป็นทีวีและอุปกรณ์อินพุตแบบจำกัด
invalid_grant	400	ค่าพารามิเตอร์ code ไม่ถูกต้อง มีการอ้างสิทธิ์แล้ว หรือแยกวิเคราะห์ไม่ได้
unsupported_grant_type	400	ค่าพารามิเตอร์ grant_type ไม่ถูกต้อง
org_internal	403	รหัสไคลเอ็นต์ OAuth ในคำขอเป็นส่วนหนึ่งของโปรเจ็กต์ที่จำกัดการเข้าถึงบัญชี Google ใน องค์กร Google Cloud ที่เฉพาะเจาะจง ยืนยันการกำหนดค่าประเภทผู้ใช้สำหรับแอปพลิเคชัน OAuth

การเรียก Google API

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

คุณลองใช้ Google APIs ทั้งหมดและดูขอบเขตได้ที่ 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) ซึ่งมีพารามิเตอร์ต่อไปนี้ในเนื้อหาคำขอ

ชื่อ	ค่า
client_id	รหัสไคลเอ็นต์ที่ได้จากคอนโซล API
client_secret	ไม่บังคับ รหัสลับไคลเอ็นต์ที่ได้จากคอนโซล API
grant_type	ตามที่กำหนดไว้ในข้อกำหนด OAuth 2.0 ค่าของช่องนี้ต้องตั้งค่าเป็น refresh_token
refresh_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 ทั้งหมดที่เคยให้สิทธิ์แก่โปรเจ็กต์ออก ซึ่งจะทำให้โทเค็นการเข้าถึงหรือโทเค็นการรีเฟรชที่ออกให้สำหรับไคลเอ็นต์ทั้งหมดที่ลงทะเบียนภายใต้โปรเจ็กต์นั้นใช้งานไม่ได้

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

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

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

OpenID Connect, Google Sign-In

• email
• openid
• profile

Drive API

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

API ของ YouTube

• 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

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