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

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 ที่อธิบายไว้ในเอกสารนี้

ไลบรารี AppAuth สำหรับ Android
ไลบรารี AppAuth สำหรับ iOS
OAuth สําหรับแอป: ตัวอย่างสําหรับ Windows

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

เปิดใช้ 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 ที่ต้องการเปิดใช้ แล้วคลิกปุ่มเปิดใช้
If prompted, enable billing.
If prompted, read and accept the API's Terms of Service.

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

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

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

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

การรับโทเค็นการเข้าถึง 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 (แนะนำ)	การทดสอบโค้ดคือแฮช SHA256 ที่เข้ารหัส Base64URL (ไม่มีตัวคั่นกลาง) ของผู้ตรวจสอบโค้ด `code_challenge` = BASE64URL-ENCODE(SHA256(ASCII(`code_verifier`)))
plain	รหัสยืนยันมีค่าเดียวกับโปรแกรมตรวจสอบรหัสที่สร้างไว้ด้านบน `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 คือนิพจน์ Reverse DNS ของโดเมนที่คุณควบคุม รูปแบบที่กำหนดเองต้องมีระยะเวลาจึงจะใช้งานได้
com.googleusercontent.apps.123 คือนิพจน์ DNS แบบย้อนกลับของรหัสไคลเอ็นต์
redirect_uri_path คือคอมโพเนนต์เส้นทางที่ไม่บังคับ เช่น /oauth2redirect โปรดทราบว่าเส้นทางควรขึ้นต้นด้วยเครื่องหมายทับเดี่ยว ซึ่งแตกต่างจาก URL ของ HTTP ปกติ

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

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

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

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

response_type

จำเป็น

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

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

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

login_hint

ไม่บังคับ

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

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

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

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

`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 จากเว็บไซต์ของคุณ นักพัฒนาแอปควรอนุญาตให้ลิงก์ทั่วไปเปิดในตัวแฮนเดิลลิงก์เริ่มต้นของระบบปฏิบัติการ ซึ่งรวมถึงตัวแฮนเดิล App Link ของ Android หรือแอปเบราว์เซอร์เริ่มต้น นอกจากนี้ ระบบยังรองรับตัวเลือกไลบรารี Android Custom Tabs ด้วย

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 อาจหมายถึงขั้นตอนการส่งผ่านข้อมูลนอกแบนด์ (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/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

ขั้นตอนที่ 6: ตรวจสอบขอบเขตที่ผู้ใช้ให้สิทธิ์

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

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

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

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

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

หลังจากแอปพลิเคชันได้รับโทเค็นการเข้าถึงแล้ว คุณจะใช้โทเค็นดังกล่าวเพื่อเรียกใช้ Google API ในนามของบัญชีผู้ใช้ที่ระบุได้ หากได้รับสิทธิ์เข้าถึงขอบเขตที่ API กำหนด โดยใส่โทเค็นการเข้าถึงในคำขอไปยัง API โดยใส่พารามิเตอร์การค้นหา access_token หรือค่าส่วนหัว HTTP Authorization Bearer หากเป็นไปได้ เราขอแนะนำให้ใช้ส่วนหัว HTTP เนื่องจากสตริงการค้นหามีแนวโน้มที่จะปรากฏในบันทึกของเซิร์ฟเวอร์ ในกรณีส่วนใหญ่ คุณสามารถใช้ไลบรารีของไคลเอ็นต์เพื่อตั้งค่าการเรียกใช้ Google API (เช่น เมื่อเรียกใช้ 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`	คุณต้องตั้งค่าช่องนี้เป็น `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 https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

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

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

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

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

หากต้องการเพิกถอนโทเค็นแบบเป็นโปรแกรม แอปพลิเคชันของคุณจะต้องส่งคำขอไปที่ https://oauth2.googleapis.com/revoke และระบุโทเค็นเป็นพารามิเตอร์ ดังนี้

curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
        https://oauth2.googleapis.com/revoke?token={token}

โทเค็นอาจเป็นโทเค็นการเข้าถึงหรือโทเค็นการรีเฟรชก็ได้ หากโทเค็นเป็นโทเค็นการเข้าถึงและมีโทเค็นการรีเฟรชที่เกี่ยวข้อง ระบบจะเพิกถอนโทเค็นการรีเฟรชด้วย

หากการเพิกถอนดำเนินการเสร็จสมบูรณ์ รหัสสถานะ HTTP ของการตอบกลับจะเป็น 200 สำหรับเงื่อนไขข้อผิดพลาด ระบบจะแสดงรหัสสถานะ HTTP 400 พร้อมกับรหัสข้อผิดพลาด

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

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

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

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

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

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

ขั้นตอนที่ 6: ตรวจสอบขอบเขตที่ผู้ใช้ให้สิทธิ์

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

ตัวอย่าง HTTP GET

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

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

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

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

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

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

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

เปิดใช้สกีม 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`