OAuth 2.0 สำหรับแอปบนอุปกรณ์เคลื่อนที่และเดสก์ท็อป

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

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

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

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

ตัวเลือกอื่นๆ

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

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

ห้องสมุดและตัวอย่าง

เราขอแนะนำให้ใช้ไลบรารีและตัวอย่างต่อไปนี้เพื่อช่วยในการใช้งานขั้นตอน OAuth 2.0 ตามที่อธิบายไว้ในเอกสารนี้

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

เปิดใช้ 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 ที่ต้องการเปิดใช้ในรายการ ให้ใช้การค้นหาเพื่อ หากต้องการค้นหารหัสดังกล่าว หรือคลิกดูทั้งหมดในกลุ่มผลิตภัณฑ์นั้น
  4. เลือก API ที่ต้องการเปิดใช้ แล้วคลิกปุ่มเปิดใช้
  5. If prompted, enable billing.
  6. If prompted, read and accept the API's Terms of Service.

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

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

  1. Go to the Credentials page.
  2. คลิกสร้างข้อมูลเข้าสู่ระบบ > รหัสไคลเอ็นต์ OAuth
  3. ส่วนด้านล่างนี้อธิบายประเภทไคลเอ็นต์และวิธีการเปลี่ยนเส้นทางที่ รองรับเซิร์ฟเวอร์การให้สิทธิ์ เลือกประเภทไคลเอ็นต์ที่แนะนำสำหรับ แอปพลิเคชัน ให้ตั้งชื่อไคลเอ็นต์ OAuth และตั้งค่าช่องอื่นๆ ในแบบฟอร์มเป็น เหมาะสม
Android
  1. เลือกประเภทแอปพลิเคชัน Android
  2. ป้อนชื่อสำหรับไคลเอ็นต์ OAuth ชื่อนี้จะปรากฏใน Credentials page เพื่อระบุลูกค้า
  3. ป้อนชื่อแพ็กเกจของแอป Android ค่านี้จะระบุไว้ในฟิลด์ แอตทริบิวต์ package ขององค์ประกอบ <manifest> ในไฟล์ Manifest ของแอป
  4. ป้อนลายนิ้วมือสำหรับใบรับรองการลงนาม SHA-1 ของการเผยแพร่แอป
    • หากแอปของคุณใช้ App Signing โดย Google Play ให้คัดลอก SHA-1 ลายนิ้วมือจากหน้า App Signing ของ Play Console
    • หากคุณจัดการคีย์สโตร์และคีย์การรับรองของคุณเอง ให้ใช้ยูทิลิตีเครื่องมือคีย์ มาพร้อมกับ Java เพื่อพิมพ์ข้อมูลใบรับรองในรูปแบบที่มนุษย์อ่านได้ คัดลอก SHA1 ในส่วน Certificate fingerprints ของพารามิเตอร์ เอาต์พุตเครื่องมือคีย์ โปรดดู การตรวจสอบสิทธิ์ไคลเอ็นต์ใน สำหรับข้อมูลเพิ่มเติมในเอกสาร Google APIs สำหรับ Android
  5. (ไม่บังคับ) ยืนยันการเป็นเจ้าของ Android แอปพลิเคชัน
  6. คลิกสร้าง
iOS
  1. เลือกประเภทแอปพลิเคชัน iOS
  2. ป้อนชื่อสำหรับไคลเอ็นต์ OAuth ชื่อนี้จะปรากฏใน Credentials page เพื่อระบุลูกค้า
  3. ป้อนตัวระบุชุดซอฟต์แวร์สําหรับแอปของคุณ รหัสชุดคือค่าของฟิลด์ CFBundleIdentifier ในไฟล์ทรัพยากรรายการพร็อพเพอร์ตี้ข้อมูลของแอป (info.plist) ค่า แสดงมากที่สุดในแผง "ทั่วไป" หรือช่อง "และ" แผงความสามารถของ ผู้แก้ไขโปรเจ็กต์ Xcode รหัสชุดยังแสดงในส่วนข้อมูลทั่วไปของ หน้าข้อมูลแอปสำหรับแอปบน เว็บไซต์ App Store Connect ของ Apple
  4. (ไม่บังคับ)

    ป้อนรหัส App Store ของแอปหากมีการเผยแพร่แอปใน App Store ของ Apple รหัสร้านค้าคือ สตริงตัวเลขที่รวมอยู่ใน URL ของ Apple App Store ทั้งหมด

    1. เปิด แอป Apple App Store บนอุปกรณ์ iOS หรือ iPadOS
    2. ค้นหาแอปของคุณ
    3. เลือกปุ่มแชร์ (สัญลักษณ์สี่เหลี่ยมจัตุรัสและลูกศรขึ้น)
    4. เลือกคัดลอกลิงก์
    5. วางลิงก์ลงในเครื่องมือแก้ไขข้อความ รหัส App Store คือส่วนสุดท้ายของ URL

      เช่น https://apps.apple.com/app/google/id284815942

  5. (ไม่บังคับ)

    ป้อนรหัสทีม โปรดดู ค้นหารหัสทีม ในเอกสารประกอบของบัญชีนักพัฒนาแอป Apple เพื่อดูข้อมูลเพิ่มเติม

  6. คลิกสร้าง
UWP
  1. เลือกประเภทแอปพลิเคชัน Universal Windows Platform
  2. ป้อนชื่อสำหรับไคลเอ็นต์ OAuth ชื่อนี้จะปรากฏใน Credentials page เพื่อระบุลูกค้า
  3. ป้อนรหัส Microsoft Store แบบ 12 อักขระของแอป คุณจะเห็นค่านี้ใน ศูนย์พาร์ทเนอร์ Microsoft ใน ข้อมูลระบุตัวตนของแอป ในส่วนการจัดการแอป
  4. คลิกสร้าง

สำหรับแอป UWP รูปแบบ URI ที่กำหนดเองต้องมีความยาวไม่เกิน 39 อักขระ

ชุดรูปแบบ URI ที่กำหนดเอง (Android, iOS, UWP)

รูปแบบ URI ที่กำหนดเองคือรูปแบบของ Deep Link ที่ใช้รูปแบบที่กำหนดเองในการเปิดแอป

ทางเลือกอื่นนอกจากการใช้รูปแบบ URI ที่กำหนดเองใน Android

ใช้เมนู SDK ของ Google Sign-In สำหรับ Android ซึ่งจะส่งการตอบกลับ OAuth 2.0 ไปยังแอปของคุณโดยตรง ทำให้ไม่จำเป็นต้องมี URI การเปลี่ยนเส้นทาง

วิธีย้ายข้อมูลไปยัง Google Sign-In สำหรับ Android SDK

หากคุณกำลังใช้รูปแบบที่กำหนดเองสำหรับการผสานรวม OAuth ใน Android คุณจะต้องดำเนินการต่อไปนี้ ดำเนินการด้านล่างนี้ให้เสร็จสมบูรณ์เพื่อย้ายข้อมูลไปใช้ Google Sign-In ที่แนะนำสำหรับ Android SDK

  1. อัปเดตโค้ดเพื่อใช้ Google Sign-In SDK
  2. ปิดใช้การรองรับสคีมที่กำหนดเองในคอนโซล Google API

โปรดทำตามขั้นตอนด้านล่างเพื่อย้ายข้อมูลไปยัง SDK สำหรับ Android ของ Google Sign-In

  1. อัปเดตโค้ดเพื่อใช้ Google Sign-In Android SDK ดังนี้
    1. ตรวจสอบโค้ดเพื่อระบุตำแหน่งของคุณ การส่งคำขอไปยังเซิร์ฟเวอร์ OAuth 2.0 ของ Google หากใช้สคีมที่กำหนดเอง คำขอของคุณจะมีลักษณะดังต่อไปนี้
        https://accounts.google.com/o/oauth2/v2/auth?
        scope=<SCOPES>&
        response_type=code&
        &state=<STATE>&
        redirect_uri=com.example.app:/oauth2redirect&
        client_id=<CLIENT_ID>
        
      com.example.app:/oauth2redirect คือ URI การเปลี่ยนเส้นทางรูปแบบที่กำหนดเองใน ตัวอย่างด้านบน โปรดดู คำจำกัดความพารามิเตอร์ redirect_uri สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับรูปแบบ ของค่ารูปแบบ URI ที่กำหนดเอง
    2. บันทึกพารามิเตอร์คำขอ scope และ client_id ซึ่ง คุณต้องกำหนดค่า SDK ของ Google Sign-In
    3. ทำตาม เริ่มผสานรวม Google Sign-In ในแอป Android วิธีการตั้งค่า SDK คุณสามารถข้าม ขั้นตอนรับรหัสไคลเอ็นต์ OAuth 2.0 ของเซิร์ฟเวอร์แบ็กเอนด์เหมือนที่ใช้ซ้ำ client_id ที่ดึงมาจากขั้นตอนก่อนหน้า
    4. ทำตาม การเปิดใช้การเข้าถึง API ฝั่งเซิร์ฟเวอร์ วิธีทำ ซึ่งรวมถึงขั้นตอนต่อไปนี้
      1. ใช้เมธอด getServerAuthCode เพื่อเรียกข้อมูลรหัสการให้สิทธิ์สำหรับ ขอบเขตที่คุณขอสิทธิ์
      2. ส่งรหัสการตรวจสอบสิทธิ์ไปยังแบ็กเอนด์ของแอปเพื่อแลกเปลี่ยนกับสิทธิ์เข้าถึงและ รีเฟรช โทเค็น
      3. ใช้โทเค็นเพื่อการเข้าถึงที่เรียกดูเพื่อเรียก Google APIs ในนามของผู้ใช้
  2. ปิดใช้การรองรับสคีมที่กำหนดเองในคอนโซล Google API ดังนี้
    1. ไปที่ ข้อมูลเข้าสู่ระบบ OAuth 2.0 แล้วเลือกไคลเอ็นต์ Android
    2. ไปที่ส่วนการตั้งค่าขั้นสูง ยกเลิกการเลือก ช่องทำเครื่องหมายเปิดใช้สคีม URI ที่กำหนดเอง แล้วคลิกบันทึกไปยัง ปิดใช้งานการสนับสนุนรูปแบบ URI ที่กำหนดเอง
กำลังเปิดใช้รูปแบบ URI ที่กำหนดเอง
หากทางเลือกที่แนะนำไม่ได้ผลสำหรับคุณ คุณสามารถเปิดใช้งานรูปแบบ URI ที่กำหนดเอง ไคลเอ็นต์ Android โดยทำตามวิธีการด้านล่าง
  1. ไปที่ รายการข้อมูลเข้าสู่ระบบ OAuth 2.0 และ เลือกไคลเอ็นต์ Android ของคุณ
  2. ไปยังส่วนการตั้งค่าขั้นสูง ตรวจสอบ ช่องทำเครื่องหมายเปิดใช้สคีม URI ที่กำหนดเอง แล้วคลิกบันทึกเพื่อเปิดใช้ การสนับสนุนรูปแบบ URI ที่กำหนดเอง
ทางเลือกในการใช้รูปแบบ URI ที่กำหนดเองในแอป Chrome

ใช้เมนู Chrome Identity API ซึ่งจะส่งการตอบกลับ OAuth 2.0 ไปยังแอปของคุณโดยตรง ทำให้ไม่จำเป็นต้องมี URI การเปลี่ยนเส้นทาง

ยืนยันการเป็นเจ้าของแอป (Android, Chrome)

คุณสามารถยืนยันการเป็นเจ้าของแอปพลิเคชันของคุณเพื่อลดความเสี่ยงในการแอบอ้างเป็นแอป

Android

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

  • คุณต้องมีแอปพลิเคชันที่ลงทะเบียนใน Google Play Console ด้วย ชื่อแพ็กเกจและลายนิ้วมือรับรองการลงนาม SHA-1 ในฐานะไคลเอ็นต์ OAuth ของ Android ที่คุณใช้ ดำเนินการยืนยันให้เสร็จสมบูรณ์สำหรับ
  • คุณต้องมีสิทธิ์ผู้ดูแลระบบสำหรับแอปใน Google Play Console ดูข้อมูลเพิ่มเติม เกี่ยวกับการจัดการการเข้าถึงใน Google Play Console

ในส่วนยืนยันการเป็นเจ้าของแอปของไคลเอ็นต์ Android ให้คลิก ปุ่มยืนยันการเป็นเจ้าของเพื่อให้กระบวนการยืนยันเสร็จสมบูรณ์

หากการยืนยันสำเร็จ ระบบจะแสดงการแจ้งเตือนเพื่อยืนยันว่าดำเนินการสำเร็จ ของกระบวนการยืนยันตัวตน ไม่เช่นนั้น ข้อความแสดงข้อผิดพลาดจะปรากฏขึ้น

โปรดลองทำตามขั้นตอนต่อไปนี้เพื่อแก้ไขการยืนยันที่ไม่สำเร็จ

  • ตรวจสอบว่าแอปที่จะยืนยันเป็นแอปที่ลงทะเบียนใน Google Play Console
  • โปรดตรวจสอบว่าคุณมีสิทธิ์ระดับผู้ดูแลระบบสำหรับแอปใน Google Play Console
Chrome

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

ในส่วนยืนยันการเป็นเจ้าของแอปของไคลเอ็นต์ส่วนขยาย Chrome ให้คลิก ปุ่มยืนยันการเป็นเจ้าของ เพื่อให้กระบวนการยืนยันเสร็จสมบูรณ์

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

หากการยืนยันสำเร็จ ระบบจะแสดงการแจ้งเตือนเพื่อยืนยันว่าดำเนินการสำเร็จ ของกระบวนการยืนยันตัวตน ไม่เช่นนั้น ข้อความแสดงข้อผิดพลาดจะปรากฏขึ้น

โปรดลองทำตามขั้นตอนต่อไปนี้เพื่อแก้ไขการยืนยันที่ไม่สำเร็จ

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

ที่อยู่ IP แบบ Loopback (macOS, Linux, Windows สำหรับเดสก์ท็อป)

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

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

การใช้งานที่แนะนำ แอปบนเดสก์ท็อปสำหรับ macOS, Linux และ Windows (ไม่ใช่แอป Universal Windows Platform)
ค่าแบบฟอร์ม ตั้งค่าประเภทแอปพลิเคชันเป็นแอปบนเดสก์ท็อป

คัดลอก/วางด้วยตนเอง

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

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

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

เอกสารขอบเขต API ของ OAuth 2.0 จะมีข้อมูลแบบเต็ม รายการขอบเขตที่คุณอาจใช้เพื่อเข้าถึง Google APIs

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

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

ขั้นตอนที่ 1: สร้างตัวตรวจสอบโค้ดและการยืนยันตัวตน

Google รองรับคีย์พิสูจน์สำหรับการแลกเปลี่ยนโค้ด (PKCE) เพื่อให้โฟลว์แอปที่ติดตั้งมีความปลอดภัยยิ่งขึ้น ระบบจะสร้างตัวตรวจสอบโค้ดที่ไม่ซ้ำกันขึ้นสำหรับ คำขอการให้สิทธิ์ และค่าที่เปลี่ยนรูปแบบแล้วซึ่งเรียกว่า "code_challenge" จะส่งไปยัง เซิร์ฟเวอร์การให้สิทธิ์เพื่อรับรหัสการให้สิทธิ์

สร้างตัวตรวจสอบโค้ด

code_verifier เป็นสตริงแบบสุ่มการเข้ารหัสที่มีเอนโทรปีสูงซึ่งใช้สตริงที่ไม่ได้สงวนไว้ อักขระ [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~" มีความยาวอย่างน้อย 43 อักขระ และมีความยาวได้สูงสุด 128 อักขระ

ตัวตรวจสอบโค้ดควรมีเอนโทรปีเพียงพอที่จะทำให้ไม่สามารถคาดเดาค่าได้จริง

สร้างระบบทดสอบโค้ด

ระบบรองรับการทดสอบโค้ด 2 วิธีด้วยกัน

วิธีการสร้างชาเลนจ์โค้ด
S256 (แนะนำ) ระบบทดสอบโค้ดคือแฮช SHA256 ที่เข้ารหัส Base64URL (ไม่มีระยะห่างจากขอบ) ของโค้ด เครื่องมือตรวจสอบ
code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
ธรรมดา การทดสอบโค้ดเป็นค่าเดียวกันกับตัวตรวจสอบโค้ดที่สร้างขึ้นข้างต้น
code_challenge = code_verifier

ขั้นตอนที่ 2: ส่งคำขอไปยังเซิร์ฟเวอร์ OAuth 2.0 ของ Google

ในการรับการให้สิทธิ์จากผู้ใช้ ให้ส่งคำขอไปยังเซิร์ฟเวอร์การให้สิทธิ์ของ Google ที่ https://accounts.google.com/o/oauth2/v2/auth ปลายทางนี้จัดการการค้นหาเซสชันที่ใช้งานอยู่ ตรวจสอบสิทธิ์ผู้ใช้และได้รับความยินยอมจากผู้ใช้ ปลายทางจะเข้าถึงได้ผ่าน SSL เท่านั้น ปฏิเสธการเชื่อมต่อ HTTP (ไม่ใช่ SSL)

เซิร์ฟเวอร์การให้สิทธิ์สนับสนุนพารามิเตอร์สตริงข้อความค้นหาต่อไปนี้สำหรับการติดตั้ง แอปพลิเคชัน:

พารามิเตอร์
client_id จำเป็น

รหัสไคลเอ็นต์สำหรับแอปพลิเคชันของคุณ คุณสามารถค้นหาค่านี้ใน API Console Credentials page

redirect_uri จำเป็น

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

ค่าต้องตรงกับ URI การเปลี่ยนเส้นทางที่ได้รับอนุญาตรายการใดรายการหนึ่งสำหรับ OAuth 2.0 ซึ่งคุณกำหนดค่าในบัญชีของไคลเอ็นต์ API Console Credentials pageหากค่านี้ไม่ตรงกับ URI ที่ได้รับอนุญาต คุณจะได้รับข้อผิดพลาด redirect_uri_mismatch

ตารางด้านล่างแสดงค่าพารามิเตอร์ redirect_uri ที่เหมาะสมสำหรับ แต่ละวิธีดังนี้

ค่า redirect_uri
รูปแบบ URI ที่กำหนดเอง com.example.app:redirect_uri_path

หรือ

com.googleusercontent.apps.123:redirect_uri_path
  • com.example.app เป็นสัญลักษณ์ DNS แบบย้อนกลับของโดเมนภายใต้ การควบคุมของคุณ รูปแบบที่กำหนดเองต้องมีเครื่องหมายจุดจึงจะใช้ได้
  • com.googleusercontent.apps.123 เป็นสัญลักษณ์ DNS แบบย้อนกลับของ รหัสไคลเอ็นต์
  • redirect_uri_path เป็นคอมโพเนนต์เส้นทางที่ไม่บังคับ เช่น /oauth2redirect โปรดทราบว่าเส้นทางควรเริ่มต้นด้วยแท็กเดียว เครื่องหมายทับ ซึ่งต่างจาก HTTP URL ทั่วไป
ที่อยู่ IP แบบวนซ้ำ http://127.0.0.1:port หรือ วันที่ http://[::1]:port

ค้นหาแพลตฟอร์มสำหรับที่อยู่ IP ของ Loopback ที่เกี่ยวข้องและเริ่ม HTTP Listener บนพอร์ตที่ใช้ได้แบบสุ่ม แทนที่ port ด้วยค่าจริง หมายเลขพอร์ตที่แอปรับการฟัง

โปรดทราบว่าการรองรับตัวเลือกการเปลี่ยนเส้นทางที่อยู่ IP แบบ Loopback ในอุปกรณ์เคลื่อนที่ คือ เลิกใช้งานแล้ว

response_type จำเป็น

กำหนดว่าปลายทาง Google OAuth 2.0 ส่งรหัสการให้สิทธิ์กลับมาหรือไม่

ตั้งค่าพารามิเตอร์เป็น code สำหรับแอปพลิเคชันที่ติดตั้งไว้

scope จำเป็น

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

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

code_challenge แนะนำ

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

code_challenge_method แนะนำ

ระบุวิธีการที่ใช้ในการเข้ารหัส code_verifier ที่จะใช้ ในระหว่างการแลกเปลี่ยนรหัสการให้สิทธิ์ พารามิเตอร์นี้ต้องใช้กับ code_challenge ที่อธิบายไว้ข้างต้น ค่าของ code_challenge_method ค่าเริ่มต้นคือ plain หากไม่มีอยู่ในคำขอที่มี code_challenge ค่าที่รองรับสำหรับพารามิเตอร์นี้คือ S256 หรือ plain

state แนะนำ

ระบุค่าสตริงที่แอปพลิเคชันใช้เพื่อรักษาสถานะระหว่าง คำขอการให้สิทธิ์ และการตอบกลับของเซิร์ฟเวอร์การให้สิทธิ์ เซิร์ฟเวอร์จะแสดงผลค่าที่แน่นอนที่คุณส่งเป็นคู่ name=value ใน ตัวระบุส่วนย่อยของ URL (#) ของ redirect_uriหลังจากที่ผู้ใช้ยินยอมหรือปฏิเสธ คำขอเข้าถึง

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

login_hint ไม่บังคับ

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

ตั้งค่าพารามิเตอร์เป็นอีเมลหรือตัวระบุ sub ซึ่งก็คือ เทียบเท่ากับรหัส Google ของผู้ใช้

ตัวอย่าง URL การให้สิทธิ์

แท็บด้านล่างแสดงตัวอย่าง URL การให้สิทธิ์สำหรับตัวเลือก URI การเปลี่ยนเส้นทางที่แตกต่างกัน

URL จะเหมือนกันยกเว้นค่าของพารามิเตอร์ redirect_uri URL ยังมีพารามิเตอร์ response_type และ client_id ที่จำเป็นด้วย เป็นพารามิเตอร์ state ที่ไม่บังคับ แต่ละ URL จะมีตัวแบ่งบรรทัดและช่องว่างสำหรับ ความอ่านง่าย

รูปแบบ URI ที่กำหนดเอง

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=com.example.app%3A/oauth2redirect&
 client_id=client_id

ที่อยู่ IP แบบ Loopback

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=http%3A//127.0.0.1%3A9004&
 client_id=client_id

ขั้นตอนที่ 3: Google แจ้งขอความยินยอมจากผู้ใช้

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

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

ข้อผิดพลาด

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

admin_policy_enforced

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

disallowed_useragent

ปลายทางการให้สิทธิ์แสดงภายใน User Agent แบบฝังซึ่ง Google ไม่อนุญาต นโยบาย OAuth 2.0

Android

นักพัฒนาแอป Android อาจพบข้อความแสดงข้อผิดพลาดนี้เมื่อเปิดคำขอการให้สิทธิ์ใน android.webkit.WebView นักพัฒนาแอปควรใช้ไลบรารี Android แทน เช่น Google Sign-In สำหรับ Android หรือ AppAuth สำหรับ Android

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

iOS

นักพัฒนา iOS และ macOS อาจพบข้อผิดพลาดนี้เมื่อเปิดคำขอการให้สิทธิ์ใน WKWebView นักพัฒนาซอฟต์แวร์ควรใช้ไลบรารี iOS แทน เช่น Google Sign-In สำหรับ iOS หรือ OpenID Foundation AppAuth สำหรับ iOS

นักพัฒนาเว็บอาจพบข้อผิดพลาดนี้เมื่อแอป iOS หรือ macOS เปิดเว็บลิงก์ทั่วไปใน User Agent ที่ฝังและผู้ใช้ไปยังปลายทางการให้สิทธิ์ OAuth 2.0 ของ Google จาก เว็บไซต์ของคุณ นักพัฒนาควรอนุญาตให้ลิงก์ทั่วไปเปิดในเครื่องจัดการลิงก์เริ่มต้นของ ซึ่งมีทั้ง Universal Link หรือแอปเบราว์เซอร์เริ่มต้น SFSafariViewController ก็เป็นตัวเลือกที่รองรับเช่นกัน

org_internal

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

invalid_grant

หากคุณใช้ ตัวตรวจสอบโค้ดและ คำถาม พารามิเตอร์ code_callenge ไม่ถูกต้องหรือขาดหายไป ตรวจสอบว่า ตั้งค่าพารามิเตอร์ code_challenge อย่างถูกต้องแล้ว

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

redirect_uri_mismatch

redirect_uri ที่ส่งผ่านในคำขอการให้สิทธิ์ไม่ตรงกับรายการที่ได้รับอนุญาต URI การเปลี่ยนเส้นทางสำหรับรหัสไคลเอ็นต์ OAuth ตรวจสอบ URI การเปลี่ยนเส้นทางที่ได้รับอนุญาตใน Google API Console Credentials page

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

พารามิเตอร์ redirect_uri อาจอ้างถึงขั้นตอนนอกย่านความถี่ (OOB) ของ OAuth ที่ เลิกใช้งานแล้วและไม่มีการรองรับอีกต่อไป โปรดดู คำแนะนำในการย้ายข้อมูลเพื่ออัปเดต การผสานรวม

invalid_request

เกิดข้อผิดพลาดบางอย่างกับคำขอของคุณ ซึ่งอาจเกิดจากสาเหตุหลายประการ ดังนี้

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

ขั้นตอนที่ 4: จัดการการตอบกลับของเซิร์ฟเวอร์ OAuth 2.0

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

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

ขั้นตอนที่ 5: รหัสการให้สิทธิ์ของ Exchange สำหรับการรีเฟรชและการเข้าถึง โทเค็น

หากต้องการแลกเปลี่ยนรหัสการให้สิทธิ์สำหรับโทเค็นเพื่อการเข้าถึง โปรดเรียก https://oauth2.googleapis.com/token ปลายทาง แล้วตั้งค่าพารามิเตอร์ต่อไปนี้

ช่อง
client_id รหัสไคลเอ็นต์ที่ได้รับจาก API Console Credentials page
client_secret รหัสลับไคลเอ็นต์ที่ได้รับจาก API Console Credentials page
code รหัสการให้สิทธิ์ที่ส่งคืนจากคำขอเริ่มต้น
code_verifier ตัวตรวจสอบโค้ดที่คุณสร้าง ขั้นตอนที่ 1
grant_type ตามที่ให้คำจำกัดความไว้ใน OAuth 2.0 ข้อมูลจำเพาะ ค่าของช่องนี้ต้องตั้งค่าเป็น authorization_code
redirect_uri หนึ่งใน URI การเปลี่ยนเส้นทางที่แสดงอยู่สำหรับโครงการของคุณใน API Console Credentials page สำหรับ client_id

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

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

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your_client_id&
client_secret=your_client_secret&
redirect_uri=http://127.0.0.1:9004&
grant_type=authorization_code

Google ตอบสนองต่อคำขอนี้โดยแสดงผลออบเจ็กต์ JSON ที่มีการเข้าถึงเป็นระยะเวลาสั้นๆ และโทเค็นการรีเฟรช

คำตอบจะมีช่องต่อไปนี้

ช่อง
access_token โทเค็นที่แอปพลิเคชันของคุณส่งเพื่อให้สิทธิ์คำขอ Google API
expires_in อายุการใช้งานที่เหลือของโทเค็นเพื่อการเข้าถึงเป็นวินาที
id_token หมายเหตุ: ระบบจะแสดงผลพร็อพเพอร์ตี้นี้เมื่อคำขอมีขอบเขตข้อมูลประจำตัวเท่านั้น เช่น openid, profile หรือ email ค่าคือ JSON Web Token (JWT) ที่มีข้อมูลประจำตัวที่ลงนามแบบดิจิทัลเกี่ยวกับ ผู้ใช้
refresh_token โทเค็นที่คุณสามารถใช้เพื่อรับโทเค็นเพื่อการเข้าถึงใหม่ โทเค็นการรีเฟรชจะใช้ได้จนถึง ผู้ใช้เพิกถอนการเข้าถึง โปรดทราบว่าระบบจะส่งคืนโทเค็นการรีเฟรชสำหรับแอปพลิเคชันที่ติดตั้งไว้เสมอ
scope ขอบเขตการเข้าถึงที่ access_token อนุญาตซึ่งแสดงเป็นรายการ สตริงที่คั่นด้วยช่องว่างและคำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่
token_type ประเภทของโทเค็นที่แสดงผล ปัจจุบัน ค่าของช่องนี้จะกำหนดไว้เป็น Bearer

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

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "token_type": "Bearer",
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

การเรียกใช้ Google APIs

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

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

ช่อง
client_id รหัสไคลเอ็นต์ที่ได้รับจาก API Console
client_secret รหัสลับไคลเอ็นต์ที่ได้รับจาก API Console (client_secret ใช้ไม่ได้กับคำขอจากลูกค้าที่ลงทะเบียนเป็น แอปพลิเคชัน Android, iOS หรือ Chrome)
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&
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",
  "token_type": "Bearer"
}

โปรดทราบว่าการออกโทเค็นการรีเฟรชมีขีดจำกัด 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 กลับมา ที่มีรหัสข้อผิดพลาด

อ่านเพิ่มเติม

หลักปฏิบัติปัจจุบันของ IETF OAuth 2.0 สำหรับ แอปที่มาพร้อมเครื่องมีแนวทางปฏิบัติแนะนำมากมายที่ระบุไว้ในเอกสารฉบับนี้

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

ขั้นตอนเพิ่มเติมที่คุณควรทำเพื่อปกป้องผู้ใช้ของคุณ บัญชีกำลังใช้ข้ามบัญชี ป้องกันโดยใช้บริการการป้องกันแบบครอบคลุมหลายบริการของ 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

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