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

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

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

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

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

Open the API Library ใน Google API Console
If prompted, select a project, or create a new one.
ใช้หน้าคลังเพื่อค้นหาและเปิดใช้ API ของข้อมูลวิเคราะห์ YouTube และ Reporting API ของ YouTube แอปพลิเคชันจำนวนมากที่ดึงข้อมูล YouTube Analytics ยังทำงานร่วมกับ YouTube Data API ด้วย ค้นหา API อื่นๆ ที่แอปพลิเคชันจะใช้และเปิดใช้ API เหล่านั้นด้วย

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

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

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

Android

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

iOS

เลือกประเภทแอปพลิเคชัน iOS
ป้อนชื่อสำหรับไคลเอ็นต์ OAuth ชื่อนี้จะแสดงใน Credentials page ของโปรเจ็กต์เพื่อระบุลูกค้า
ป้อนตัวระบุชุดซอฟต์แวร์สําหรับแอปของคุณ รหัสชุดคือค่าของฟิลด์ CFBundleIdentifier ในไฟล์ทรัพยากรรายการพร็อพเพอร์ตี้ข้อมูลของแอป (info.plist) ค่า แสดงมากที่สุดในแผง "ทั่วไป" หรือช่อง "และ" แผงความสามารถของ ผู้แก้ไขโปรเจ็กต์ Xcode รหัสชุดยังแสดงในส่วนข้อมูลทั่วไปของ หน้าข้อมูลแอปสำหรับแอปบน เว็บไซต์ App Store Connect ของ Apple
ตรวจสอบว่าคุณใช้รหัสกลุ่มที่ถูกต้องสำหรับแอป เนื่องจากคุณจะเปลี่ยนไม่ได้หากใช้ฟีเจอร์ App Check
(ไม่บังคับ)
ป้อนรหัส 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 เพื่อดูข้อมูลเพิ่มเติม
หมายเหตุ: คุณต้องระบุช่องรหัสทีมหากคุณเปิดใช้ App Check ให้ลูกค้า
(ไม่บังคับ)
เปิดใช้ App Check สําหรับแอป iOS เมื่อเปิดใช้ App Check ระบบจะใช้บริการ App Attest ของ Apple เพื่อยืนยันว่าคําขอ OAuth 2.0 ที่มาจากไคลเอ็นต์ OAuth ของคุณนั้นถูกต้องและมาจากแอปของคุณ ซึ่งจะช่วยลดความความเสี่ยงในการแอบอ้างเป็นแอป ดูข้อมูลเพิ่มเติมเกี่ยวกับการเปิดใช้ App Check สำหรับแอป iOS
คลิกสร้าง

UWP

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

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

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

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

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

API ของข้อมูลวิเคราะห์ YouTube ใช้ขอบเขตต่อไปนี้

ขอบเขต
https://www.googleapis.com/auth/youtube	จัดการบัญชี YouTube ของคุณ
https://www.googleapis.com/auth/youtube.readonly	ดูบัญชี YouTube ของคุณ
https://www.googleapis.com/auth/youtubepartner	ดูและจัดการเนื้อหาของคุณและเนื้อหาที่เกี่ยวข้องบน YouTube
https://www.googleapis.com/auth/yt-analytics-monetary.readonly	ดูรายงาน YouTube Analytics ที่เป็นตัวเงินและไม่ใช่ตัวเงินสำหรับเนื้อหา YouTube ของคุณ
https://www.googleapis.com/auth/yt-analytics.readonly	ดูรายงาน YouTube Analytics สำหรับเนื้อหา YouTube ของคุณ

YouTube Reporting API ใช้ขอบเขตต่อไปนี้

ขอบเขต
https://www.googleapis.com/auth/yt-analytics-monetary.readonly	ดูรายงาน YouTube Analytics ที่เป็นตัวเงินและไม่ใช่ตัวเงินสำหรับเนื้อหา YouTube ของคุณ
https://www.googleapis.com/auth/yt-analytics.readonly	ดูรายงาน YouTube Analytics สำหรับเนื้อหา YouTube ของคุณ

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

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

การรับโทเค็นการเข้าถึง 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 โปรดทราบว่าเส้นทางควรขึ้นต้นด้วยเครื่องหมายทับเดี่ยว ซึ่งแตกต่างจาก URL ของ HTTP ปกติ

ที่อยู่ IP แบบวนซ้ำ

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

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

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

response_type

จำเป็น

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

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

scope

จำเป็น

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

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

API ของข้อมูลวิเคราะห์ YouTube ใช้ขอบเขตต่อไปนี้

ขอบเขต
https://www.googleapis.com/auth/youtube	จัดการบัญชี YouTube ของคุณ
https://www.googleapis.com/auth/youtube.readonly	ดูบัญชี YouTube ของคุณ
https://www.googleapis.com/auth/youtubepartner	ดูและจัดการเนื้อหาของคุณและเนื้อหาที่เกี่ยวข้องบน YouTube
https://www.googleapis.com/auth/yt-analytics-monetary.readonly	ดูรายงาน YouTube Analytics ที่เป็นตัวเงินและไม่ใช่ตัวเงินสำหรับเนื้อหา YouTube ของคุณ
https://www.googleapis.com/auth/yt-analytics.readonly	ดูรายงาน YouTube Analytics สำหรับเนื้อหา YouTube ของคุณ

Reporting API ของ YouTube ใช้ขอบเขตต่อไปนี้

ขอบเขต
https://www.googleapis.com/auth/yt-analytics-monetary.readonly	ดูรายงาน YouTube Analytics ที่เป็นตัวเงินและไม่ใช่ตัวเงินสำหรับเนื้อหา YouTube ของคุณ
https://www.googleapis.com/auth/yt-analytics.readonly	ดูรายงาน YouTube Analytics สำหรับเนื้อหา YouTube ของคุณ

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

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

สำคัญ: ไคลเอ็นต์ OAuth ต้องป้องกัน CSRF ตามที่ระบุไว้ในข้อกำหนด OAuth2 วิธีหนึ่งในการทำเช่นนี้คือการใช้พารามิเตอร์ state เพื่อรักษาสถานะระหว่างคำขอการให้สิทธิ์กับการตอบกลับของเซิร์ฟเวอร์การให้สิทธิ์

login_hint

ไม่บังคับ

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

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

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

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

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

URL แต่ละรายการจะขอสิทธิ์เข้าถึงขอบเขตที่อนุญาตให้ดึงข้อมูลรายงาน YouTube Analytics ของผู้ใช้

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

สคีม URI ที่กําหนดเอง

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyt-analytics.readonly&
 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=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyt-analytics.readonly&
 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 จากเว็บไซต์ของคุณ นักพัฒนาแอปควรอนุญาตให้ลิงก์ทั่วไปเปิดในตัวแฮนเดิลลิงก์เริ่มต้นของระบบปฏิบัติการ ซึ่งรวมถึงตัวแฮนเดิล App Link ของ Android หรือแอปเบราว์เซอร์เริ่มต้น นอกจากนี้ ระบบยังรองรับไลบรารี Android Custom Tabs ด้วย

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

หากต้องการแลกเปลี่ยนรหัสการให้สิทธิ์เป็นโทเค็นการเข้าถึง ให้เรียกใช้ปลายทาง 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`

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

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

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

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

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

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

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

ตัวอย่าง HTTP GET

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

GET /youtube/analytics/v1/reports?ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

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

GET https://www.googleapis.com/youtube/analytics/v1/reports?access_token=access_token&ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views

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

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

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/analytics/v1/reports?ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views

หรือจะใช้ตัวเลือกพารามิเตอร์สตริงการค้นหาก็ได้

curl https://www.googleapis.com/youtube/analytics/v1/reports?access_token=access_token&ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views

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

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

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

ช่อง
`client_id`	รหัสไคลเอ็นต์ที่ได้รับจาก API Console
`client_secret`	รหัสลับไคลเอ็นต์ที่ได้รับจาก API Console (`client_secret` ใช้ไม่ได้กับคำขอจากลูกค้าที่ลงทะเบียนเป็น แอปพลิเคชัน Android, iOS หรือ Chrome)
`grant_type`	คุณต้องตั้งค่าช่องนี้เป็น `refresh_token` ตามที่ระบุไว้ในข้อกำหนดเฉพาะของ OAuth 2.0
`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 กลับมา ที่มีรหัสข้อผิดพลาด

วิธีการเปลี่ยนเส้นทางแอป

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

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

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

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

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

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

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

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

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

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

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

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

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

คัดลอก/วางด้วยตนเอง (เลิกใช้งาน)

ปกป้องแอปของคุณ

ยืนยันการเป็นเจ้าของแอป (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 ให้คลิกปุ่มยืนยันการเป็นเจ้าของเพื่อดำเนินการยืนยันให้เสร็จสมบูรณ์

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

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

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

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

App Check (iOS เท่านั้น)

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

เปิดใช้ App Check สําหรับไคลเอ็นต์ iOS

คุณต้องปฏิบัติตามข้อกำหนดต่อไปนี้เพื่อเปิดใช้ App Check สำหรับไคลเอ็นต์ iOS ให้เสร็จสมบูรณ์

คุณต้องระบุรหัสทีมสำหรับลูกค้า iOS
คุณต้องไม่ใช้ไวลด์การ์ดในรหัสชุด เนื่องจากสามารถจับคู่ได้มากกว่า 1 แอป ช่วงเวลานี้ หมายความว่ารหัสชุดต้องไม่มีเครื่องหมายดอกจัน (*)

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

หากต้องการเปิดใช้ App Check ให้เปิด ปุ่มเปิด/ปิดปกป้องไคลเอ็นต์ OAuth จากการละเมิดด้วย Firebase App Check ในมุมมองแก้ไข ของไคลเอ็นต์ iOS

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

คุณอาจเห็นข้อผิดพลาดที่เกี่ยวข้องกับฟีเจอร์ App Check เมื่อเปิดใช้ App Check สําหรับแอป iOS หากต้องการแก้ไขข้อผิดพลาดเหล่านี้ ให้ลองทำดังนี้

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

บังคับใช้ App Check สำหรับไคลเอ็นต์ iOS

การเปิดใช้ App Check สำหรับแอปจะไม่บล็อกคำขอที่ไม่รู้จักโดยอัตโนมัติ การบังคับใช้ การป้องกันนี้ ให้ไปที่มุมมองแก้ไขของไคลเอ็นต์ iOS คุณจะเห็นเมตริก App Check ทางด้านขวาของหน้าในส่วน Google Identity for iOS เมตริกประกอบด้วย ข้อมูลต่อไปนี้

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

ตรวจสอบเมตริกเหล่านี้เพื่อทำความเข้าใจว่าการใช้ App Check จะส่งผลต่อผู้ใช้อย่างไร

หากต้องการบังคับใช้ App Check ให้คลิกปุ่มบังคับใช้และยืนยันการเลือก เมื่อการบังคับใช้มีผลใช้งานอยู่ ระบบจะปฏิเสธคำขอที่ยังไม่ยืนยันทั้งหมดจากไคลเอ็นต์

หมายเหตุ: หลังจากเปิดใช้การบังคับใช้แล้ว ระบบอาจใช้เวลาถึง 15 นาทีเพื่อให้การเปลี่ยนแปลงมีผล

ยกเลิกการบังคับใช้ App Check กับไคลเอ็นต์ iOS

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

หากต้องการยกเลิกการบังคับใช้ App Check สำหรับไคลเอ็นต์ iOS ให้ไปที่มุมมองแก้ไขของไคลเอ็นต์ iOS และ คลิกปุ่มยกเลิกการบังคับใช้ และยืนยันการเลือกของคุณ

หมายเหตุ: หลังจากยกเลิกการบังคับใช้ App Check แล้ว ระบบอาจใช้เวลาถึง 15 นาทีก่อนที่การเปลี่ยนแปลงจะมีผล

ปิดใช้ App Check สำหรับไคลเอ็นต์ iOS

การปิดใช้ App Check สําหรับแอปจะหยุดการตรวจสอบและการบังคับใช้ App Check ทั้งหมด พิจารณา ยกเลิกการบังคับใช้ App Check แทนเพื่อให้ติดตามได้ต่อไป เมตริกของลูกค้า

หากต้องการปิดใช้ App Check สําหรับไคลเอ็นต์ iOS ให้ไปที่มุมมองแก้ไขของไคลเอ็นต์ iOS แล้วปิดปุ่มสลับปกป้องไคลเอ็นต์ OAuth จากการละเมิดด้วย Firebase App Check

หมายเหตุ: หลังจากปิดใช้ App Check แล้ว อาจใช้เวลาถึง 15 นาทีเพื่อให้การเปลี่ยนแปลงมีผล

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

แนวทางปฏิบัติแนะนำในปัจจุบันของ 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

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

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

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

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

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

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

Android

iOS

UWP

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

การรับโทเค็นการเข้าถึง 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: เปลี่ยนรหัสการให้สิทธิ์เป็นโทเค็นรีเฟรชและโทเค็นการเข้าถึง

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

ตัวอย่าง HTTP GET

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

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

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

วิธีการเปลี่ยนเส้นทางแอป

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

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

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

เปิดใช้สกีม URI ที่กําหนดเอง

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

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

คัดลอก/วางด้วยตนเอง (เลิกใช้งาน)

ปกป้องแอปของคุณ

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

Android

Chrome

App Check (iOS เท่านั้น)

เปิดใช้ App Check สําหรับไคลเอ็นต์ iOS

บังคับใช้ App Check สำหรับไคลเอ็นต์ iOS

ยกเลิกการบังคับใช้ App Check กับไคลเอ็นต์ iOS

ปิดใช้ App Check สำหรับไคลเอ็นต์ iOS

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

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

`admin_policy_enforced`

`disallowed_useragent`

`org_internal`

`invalid_grant`

`redirect_uri_mismatch`

`invalid_request`

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