1.1: การลิงก์บัญชี OAuth
บทนำและผลกระทบทางธุรกิจ
หากต้องการใช้ประโยชน์จาก Google APIs คุณต้องใช้ OAuth เพื่อให้สิทธิ์การผสานรวม สิทธิ์เข้าถึงที่จำเป็นของผู้ขายในการเริ่มต้นใช้งานข้อมูลที่แสดงฟรีและโฆษณาแบบชำระเงิน
แอปพลิเคชันต้องใช้ OAuth 2.0 เพื่อให้สิทธิ์คำขอ ระบบไม่รองรับโปรโตคอลการให้สิทธิ์อื่นๆ
คำแนะนำ UX
เป้าหมาย: ให้ผู้ขายได้รับอนุญาตให้แชร์ ในการใช้ข้อมูลของแอป Google
หลักการออกแบบ: ขอสิทธิ์ที่ถูกต้องในเวลาที่เหมาะสม หากผู้ขายไม่ให้สิทธิ์ ให้ล้มเหลวอย่างแนบเนียน
ระบบจะแจ้งให้ผู้ขายระบุสิทธิ์การเข้าถึง ดูตัวอย่างวิธีใช้วิธีการเหล่านี้ให้ผู้ขายเห็น
เมื่อผู้ขายทำตามขั้นตอนเบื้องต้นเหล่านี้แล้ว มีผลลัพธ์ที่เป็นไปได้ 3 แบบดังนี้
ผลลัพธ์ #1: หากผู้ขายยอมรับสิทธิ์ทั้งหมด สิ่งที่จะเกิดขึ้นมีดังนี้
หากผู้ขายให้สิทธิ์โดยสมบูรณ์ ก็จะเลือกทุกช่อง และได้รับแจ้งให้ดำเนินการตามขั้นตอนการเริ่มต้นใช้งานต่อ
ผลลัพธ์ #2: หากผู้ขายไม่ยอมรับ Google Ads
ผู้ขายเลือกช่องทั้งหมดยกเว้นสิทธิ์ ที่เกี่ยวข้องกับ Google Ads ลูกค้าจะดำเนินการขั้นตอนการเริ่มต้นใช้งานต่อไปและหลังจากนั้น เมื่อสร้างบัญชี Google Ads ใหม่หรือเชื่อมต่อกับ บัญชีที่มีอยู่แล้ว จะมีข้อความแจ้งอีกครั้งเพื่อให้อนุญาต:
ผลลัพธ์ #3: หากไม่ได้ทำเครื่องหมายที่ข้อมูลผลิตภัณฑ์หรือการยืนยันเว็บไซต์ ผู้ขายถูกบล็อกไม่ให้ดำเนินการต่อ
ตัวเลือกก่อนหน้านี้ทั้งหมดจะแสดงข้อความแสดงข้อผิดพลาดเดียวกัน
คำแนะนำทางเทคนิค
เลือกคำขอการให้สิทธิ์ด้วย OAuth 2.0
การเลือกวิธีการตรวจสอบสิทธิ์ของผู้ขายทำได้ 2 วิธีดังนี้
OAuth 2.0 สำหรับบัญชีที่ไม่ใช่บริการ (แนะนำอย่างยิ่ง) | OAuth 2.0 สำหรับบัญชีบริการ |
---|---|
ไคลเอ็นต์ OAuth 2.0 จะระบุแอปพลิเคชันและช่วยให้ผู้ใช้ปลายทางให้สิทธิ์แอปพลิเคชันของคุณในการเข้าถึงข้อมูล Google ของตนแบบจำกัด วิธีนี้จะช่วยให้แอปพลิเคชันของคุณเข้าถึง Google Cloud API ในนามของผู้ใช้ปลายทางได้ รายการที่ระบุจะทำให้โทเค็นเพื่อการเข้าถึงใช้งานไม่ได้ ซึ่งควรนำมาพิจารณาในโค้ด: ● ผู้ใช้เพิกถอนสิทธิ์เข้าถึง ● ผู้ใช้เปลี่ยนรหัสผ่าน ● มีจำนวนโทเค็นการรีเฟรชที่ได้รับอนุญาตเกินขีดจำกัด ● ไม่ได้ใช้โทเค็นการรีเฟรชภายใน 6 เดือน |
บัญชีบริการคือบัญชีพิเศษของ Google ที่แอปพลิเคชันสามารถใช้เพื่อเข้าถึง Google API แบบเป็นโปรแกรมโดยใช้ OAuth 2.0 ซึ่งใช้ขั้นตอน OAuth 2.0 ที่ไม่ต้องใช้การอนุมัติจากมนุษย์ แต่จะใช้ไฟล์คีย์ที่มีเพียงแอปพลิเคชันของคุณเท่านั้นที่เข้าถึงได้ หมายเหตุ: แอปพลิเคชันที่ใช้บัญชีบริการในการตรวจสอบสิทธิ์มีสิทธิ์เข้าถึงเฉพาะบัญชี Merchant Center ของตนเองเท่านั้น หากคุณเขียนแอปพลิเคชันของบุคคลที่สามที่ต้องการสิทธิ์เข้าถึงของไคลเอ็นต์ สำหรับบัญชี Merchant Center โปรดดูคำแนะนำเกี่ยวกับคำขอการให้สิทธิ์แทน หมายเหตุ: จำเป็นต้องมีโปรเจ็กต์ที่อยู่ในระบบคลาวด์และอนุญาตให้สร้างบัญชีบริการได้สูงสุด 100 บัญชี ดูเอกสารประกอบ |
ตั้งค่าขั้นตอน OAuth
กรอบการให้สิทธิ์ OAuth 2.0 ช่วยให้แอปพลิเคชันของบุคคลที่สามสามารถรับ การเข้าถึงบริการ HTTP แบบจำกัด ไม่ว่าจะในนามของเจ้าของทรัพยากรโดย การจัดการการโต้ตอบด้านการอนุมัติระหว่างเจ้าของทรัพยากรและ HTTP หรือบริการ หรือโดยการอนุญาตให้แอปพลิเคชันของบุคคลที่สามรับสิทธิ์เข้าถึงด้วยตัวเอง แทน
เนื่องจากแอปของคุณเข้าถึงข้อมูลที่มีการป้องกัน (ไม่ใช่ข้อมูลสาธารณะ) จึงต้องมี OAuth 2.0 รหัสไคลเอ็นต์ Google APIs ใช้โปรโตคอล OAuth 2.0 สำหรับการตรวจสอบสิทธิ์และ การกันวงเงิน Google รองรับสถานการณ์ทั่วไปของ OAuth 2.0 เช่น สำหรับเว็บ เซิร์ฟเวอร์ ที่ติดตั้ง และแอปพลิเคชันฝั่งไคลเอ็นต์
ดูข้อมูลเพิ่มเติม
สิ่งที่ควรทราบเกี่ยวกับการใช้ OAuth สำหรับ Content API for Shopping มีดังนี้
ตรวจสอบว่าตั้งค่า Access_type เป็นแบบออฟไลน์แล้ว: โทเค็นเพื่อการเข้าถึง หมดอายุเป็นระยะและกลายเป็นข้อมูลเข้าสู่ระบบที่ไม่ถูกต้องสำหรับ API ที่เกี่ยวข้อง อีกครั้ง
รีเฟรชโทเค็นเพื่อการเข้าถึง: คุณสามารถทำได้โดยไม่ต้องแจ้งผู้ใช้ (รวมถึงเมื่อผู้ใช้ไม่อยู่) หากคุณร้องขอ เข้าถึงขอบเขตแบบออฟไลน์ ที่เชื่อมโยงกับโทเค็น (ดูข้อมูลเพิ่มเติม)
การใช้ OAuth ในไลบรารี: เราขอแนะนำให้คุณใช้ ไลบรารีของไคลเอ็นต์ Google API
ขอบเขต: คุณต้องขอให้ผู้ขายให้สิทธิ์การอ่านและ สิทธิ์การเขียนในบัญชี Google ด้วย OAuth ของ Google Merchant Center ขอบเขต: https://www.googleapis.com/auth/content
คุณใช้ OAuth เพื่อรับข้อมูลโปรไฟล์ผู้ใช้หลักได้
ขอบเขตที่จะใช้ในการผสานรวม
ขึ้นอยู่กับประเภทการผสานรวมที่คุณวางแผนจะสร้าง เราขอแนะนำให้ขอขอบเขตที่จำเป็นทั้งหมดในขณะนี้
โปรแกรม | ขอบเขต | รูปแบบใดเป็นขอบเขตที่จำเป็น |
---|---|---|
Content API | https://www.googleapis.com/auth/content |
ข้อมูลที่แสดงฟรี |
การยืนยันเว็บไซต์ | https://www.googleapis.com/auth/siteverification |
ข้อมูลที่แสดงฟรีและ โฆษณาจากสปอนเซอร์ |
โฆษณา | https://www.googleapis.com/auth/adwords |
ข้อมูลที่แสดงฟรีและ โฆษณาจากสปอนเซอร์ |
ตรวจสอบว่าผู้ขายให้สิทธิ์เข้าถึง OAuth หรือไม่
ผู้ขายต้องเลือกช่องในขั้นตอนความยินยอม OAuth เพื่ออนุญาตให้คุณ สิทธิ์เข้าถึงขอบเขตเฉพาะ: หากไม่มีขอบเขตที่จำเป็น ให้อธิบาย ถึงผู้ขายถึงเหตุผลที่จำเป็นต้องมีข้อกำหนดเหล่านี้และขอสิทธิ์อีกครั้ง (รายละเอียดเพิ่มเติม) ไม่มีสิทธิ์เข้าถึงสิทธิ์เหล่านี้ทั้งหมด เพื่อป้องกันไม่ให้ผู้ขายเริ่มต้นใช้งานโดยสมบูรณ์
เรียกใช้ปลายทาง API ต่อไปนี้เพื่อตรวจสอบขอบเขตที่ได้รับอนุญาต
https://www.oauth2.googleapis.com/token
URL จะแสดงข้อมูลต่อไปนี้
- access_token
- ขอบเขตที่ให้แก่ผู้ใช้
- เวลาก่อนที่โทเค็นจะหมดอายุ
ขอบเขตที่ละเอียดอ่อนและขั้นตอนการยืนยัน OAuth
ระบบจะพิจารณาบางขอบเขตที่ API OAuth ใช้งาน มีความละเอียดอ่อนและต้องมีกระบวนการยืนยัน ข้อมูลเพิ่มเติม และดูตัวอย่างได้ที่ OAuth สำหรับ Content API
ขอบเขตที่มีความละเอียดอ่อนของแอปเพื่อให้เป็นไปตามนโยบาย: ต้องตรวจสอบว่าแอปเป็นไปตามข้อกำหนด ตามนโยบายข้อมูลผู้ใช้ของบริการ API ของ Google คุณต้องยอมรับข้อกำหนดในการให้บริการของ API ด้วย
ยืนยันว่าแอปของคุณไม่ได้อยู่ภายใต้ Use Case ใดๆ ที่ระบุไว้ใน ข้อยกเว้นของข้อกำหนดในการยืนยัน
ยืนยันการเป็นเจ้าของโดเมนที่ได้รับอนุญาตของโปรเจ็กต์โดยใช้การค้นหา คอนโซล ใช้บัญชีที่เป็นเจ้าของโปรเจ็กต์หรือผู้แก้ไขโปรเจ็กต์ ของโปรเจ็กต์ Cloud Console
ตรวจสอบว่าข้อมูลการสร้างแบรนด์ทั้งหมดในหน้าจอขอความยินยอม OAuth ตรงกันและ ที่ถูกต้อง เช่น ชื่อโปรเจ็กต์ที่แสดงต่อผู้ใช้, อีเมลสนับสนุน, URL หน้าแรก และ URL นโยบายความเป็นส่วนตัว แสดงถึงตัวตนของแอปอย่างถูกต้อง
ขอขอบเขตที่มีความละเอียดอ่อนกับแอปโดยใช้กระบวนการยืนยัน ทำตามขั้นตอนซึ่งคุณต้องกรอกแบบฟอร์ม ระบุเหตุผลรองรับและส่งวิดีโอ