หน้านี้ได้รับการแปลโดย Cloud Translation API

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

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

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 API จะต้องเปิดใช้ API ดังกล่าวใน API Console

วิธีเปิดใช้ API สำหรับโปรเจ็กต์ของคุณ

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

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

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

Go to the Credentials page.
คลิกสร้างข้อมูลเข้าสู่ระบบ > รหัสไคลเอ็นต์ OAuth
หัวข้อด้านล่างอธิบายประเภทไคลเอ็นต์และวิธีเปลี่ยนเส้นทางที่เซิร์ฟเวอร์การให้สิทธิ์ของ Google รองรับ เลือกประเภทไคลเอ็นต์ที่แนะนำสำหรับแอปพลิเคชัน ตั้งชื่อไคลเอ็นต์ OAuth และตั้งค่าช่องอื่นๆ ในแบบฟอร์มตามความเหมาะสม

Android

เลือกประเภทแอปพลิเคชัน Android
ป้อนชื่อสำหรับไคลเอ็นต์ OAuth ชื่อนี้จะแสดงใน Credentials page ของโปรเจ็กต์เพื่อระบุไคลเอ็นต์
ป้อนชื่อแพ็กเกจของแอป Android ค่านี้จะอยู่ในแอตทริบิวต์ package ขององค์ประกอบ <manifest> ในไฟล์ Manifest ของแอป
ป้อนลายนิ้วมือสำหรับใบรับรองที่ลงนามด้วย SHA-1 ของการเผยแพร่แอป
- หากแอปใช้ App Signing โดย Google Play ให้คัดลอกลายนิ้วมือ SHA-1 จากหน้า App Signing ของ Play Console
- หากคุณจัดการคีย์สโตร์และคีย์การลงชื่อของคุณเอง ให้ใช้ยูทิลิตีkeytoolที่มากับ Java เพื่อพิมพ์ข้อมูลใบรับรองในรูปแบบที่มนุษย์อ่านได้ คัดลอกค่า SHA1 ในส่วน Certificate fingerprints ของเอาต์พุต keytool ดูข้อมูลเพิ่มเติมที่การตรวจสอบสิทธิ์ไคลเอ็นต์ในเอกสารประกอบเกี่ยวกับ Google APIs สำหรับ Android
(ไม่บังคับ) ยืนยันการเป็นเจ้าของแอปพลิเคชัน Android
คลิกสร้าง

iOS

เลือกประเภทแอปพลิเคชัน iOS
ป้อนชื่อสำหรับไคลเอ็นต์ OAuth ชื่อนี้จะแสดงใน Credentials page ของโปรเจ็กต์เพื่อระบุไคลเอ็นต์
ป้อน Bundle ID ของแอป รหัส Bundle คือค่าของคีย์ CFBundleIdentifier ในไฟล์ทรัพยากรรายการพร็อพเพอร์ตี้ข้อมูลของแอป (info.plist) ค่านี้มักแสดงในแผง General หรือแผง Signing & Capabilities ของเครื่องมือแก้ไขโปรเจ็กต์ Xcode รหัสชุดจะแสดงในส่วนข้อมูลทั่วไปของหน้าข้อมูลแอปสำหรับแอปในเว็บไซต์ App Store Connect ของ Apple ด้วย
(ไม่บังคับ)
ป้อนรหัส 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
(ไม่บังคับ)
ป้อนรหัสทีม ดูข้อมูลเพิ่มเติมได้ที่ค้นหารหัสทีมในเอกสารของบัญชีนักพัฒนาแอป Apple
คลิกสร้าง

CANNOT TRANSLATE

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

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

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

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

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

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

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

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

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

อัปเดตรหัสเพื่อใช้ 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 ซึ่งคุณจะต้องกำหนดค่า Google Sign-In SDK
  หมายเหตุ: หากคุณใช้ไลบรารีของบุคคลที่สาม ให้ตรวจสอบไฟล์การกำหนดค่าของไลบรารีเพื่อค้นหาข้อมูลเหล่านี้
3. ทำตาม เริ่มผสานรวม Google Sign-In เข้ากับแอป Android ของคุณ เพื่อตั้งค่า SDK คุณสามารถข้ามขั้นตอนรับรหัสไคลเอ็นต์ OAuth 2.0 ของเซิร์ฟเวอร์แบ็กเอนด์ได้เหมือนการนํา client_id ที่ได้จากขั้นตอนก่อนหน้ามาใช้ซ้ำ
4. ทำตามวิธีการ เปิดใช้การเข้าถึง API ฝั่งเซิร์ฟเวอร์ ซึ่งรวมถึงขั้นตอนต่อไปนี้
  1. ใช้เมธอด getServerAuthCode เพื่อเรียกข้อมูลรหัสการให้สิทธิ์สำหรับขอบเขตที่คุณกำลังขอสิทธิ์
  2. ส่งรหัสการตรวจสอบสิทธิ์ไปยังแบ็กเอนด์ของแอปเพื่อแลกเปลี่ยนกับโทเค็นเพื่อการเข้าถึงและรีเฟรช
  3. ใช้โทเค็นเพื่อการเข้าถึงที่ได้รับมาในการเรียก Google APIs ในนามของผู้ใช้
  หมายเหตุ: หากแอปพลิเคชันไม่จำเป็นต้องใช้การเข้าถึงแบบออฟไลน์ ให้ทำตาม วิธีการเหล่านี้แทนเพื่อขอสิทธิ์เข้าถึง API ฝั่งไคลเอ็นต์
ปิดใช้การรองรับรูปแบบที่กําหนดเองในคอนโซล Google API โดยทำดังนี้
1. ไปที่รายการข้อมูลเข้าสู่ระบบ OAuth 2.0 แล้วเลือกไคลเอ็นต์ Android ของคุณ
2. ไปที่ส่วนการตั้งค่าขั้นสูง ยกเลิกการเลือกช่องทำเครื่องหมายเปิดใช้สคีม URI ที่กำหนดเอง แล้วคลิกบันทึกเพื่อปิดใช้การสนับสนุนรูปแบบ URI ที่กำหนดเอง

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

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

ไปที่รายการข้อมูลเข้าสู่ระบบ OAuth 2.0 แล้วเลือกไคลเอ็นต์ Android ของคุณ
ไปที่หัวข้อการตั้งค่าขั้นสูง เลือกช่องทำเครื่องหมายเปิดใช้สคีม 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 เว็บสโตร์ที่มีรหัสรายการเดียวกับไคลเอ็นต์ OAuth ของส่วนขยาย Chrome ที่คุณกำลังจะยืนยัน
คุณต้องเป็นผู้เผยแพร่รายการใน Chrome เว็บสโตร์ ดูข้อมูลเพิ่มเติมเกี่ยวกับการจัดการการเข้าถึงในหน้าแดชบอร์ดสำหรับนักพัฒนาซอฟต์แวร์ Chrome เว็บสโตร์

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

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

วิธีแก้ไขการยืนยันที่ไม่สำเร็จมีดังนี้

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

ที่อยู่ IP ของ Loopback (macOS, Linux, เดสก์ท็อป Windows)

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

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

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

หมายเหตุ: ดูคำจำกัดความพารามิเตอร์ redirect_uri เพื่อดูข้อมูลเพิ่มเติมเกี่ยวกับที่อยู่ IP แบบ Loopback นอกจากนี้ คุณอาจใช้ localhost แทน IP แบบ Loopback ได้ด้วย แต่การกำหนดค่านี้อาจทำให้เกิดปัญหากับไฟร์วอลล์ของไคลเอ็นต์ ไฟร์วอลล์ส่วนใหญ่อนุญาตให้ใช้การสื่อสารแบบวนซ้ำ

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

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

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

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

เอกสารขอบเขต OAuth 2.0 API มีรายการขอบเขตทั้งหมดที่คุณอาจใช้เพื่อเข้าถึง Google APIs

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

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

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

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

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

สร้างเครื่องมือยืนยันโค้ด

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

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

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

ระบบรองรับการสร้างภารกิจโค้ด 2 วิธี

วิธีการสร้างความท้าทายของโค้ด
S256 (แนะนำ)	การทดสอบโค้ดคือแฮช Base64URL (ที่ไม่มีระยะห่างจากขอบ) แฮช SHA256 ที่เข้ารหัสของเครื่องมือตรวจสอบโค้ด `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 ของ Loopback

http://127.0.0.1:port หรือ http://[::1]:port

ค้นหาแพลตฟอร์มสำหรับที่อยู่ IP แบบ Loopback ที่เกี่ยวข้องและเริ่ม Listener ของ HTTP บนพอร์ตแบบสุ่มที่พร้อมใช้งาน ให้แทนที่ 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 หลังจากที่ผู้ใช้ให้ความยินยอมหรือปฏิเสธคำขอเข้าถึงของแอปพลิเคชันของคุณ

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

login_hint

ไม่บังคับ

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

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

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

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

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

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

ขั้นตอนที่ 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 แบบฝังที่นโยบาย OAuth 2.0 ของ Google ไม่อนุญาต

Android

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

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

iOS

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

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

`org_internal`

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

`invalid_grant`

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

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

`redirect_uri_mismatch`

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

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

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

`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` เสมอ

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

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

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

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

คุณลองใช้ Google 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 ขีดจำกัดต่อชุดค่าผสมไคลเอ็นต์/ผู้ใช้ และอีก 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 สำหรับแอปที่มาพร้อมเครื่องได้กำหนดแนวทางปฏิบัติที่ดีที่สุดไว้หลายอย่างไว้ที่นี่

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

ไลบรารีและตัวอย่าง

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

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

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

Android

iOS

CANNOT TRANSLATE

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

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

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

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

Android

Chrome

ที่อยู่ IP ของ Loopback (macOS, Linux, เดสก์ท็อป Windows)

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

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

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

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

สร้างเครื่องมือยืนยันโค้ด

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

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

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

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

ที่อยู่ IP ของ Loopback

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

ข้อผิดพลาด

admin_policy_enforced

disallowed_useragent

Android

iOS

org_internal

invalid_grant

redirect_uri_mismatch

invalid_request

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

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

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

ตัวอย่าง HTTP GET

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

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

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

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

`admin_policy_enforced`

`disallowed_useragent`

`org_internal`

`invalid_grant`

`redirect_uri_mismatch`

`invalid_request`

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