การยืนยันขอบเขตที่ละเอียดอ่อน

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

ข้อกำหนดนี้จะมีผลกับแอปของคุณหรือไม่นั้นส่วนใหญ่ขึ้นอยู่กับ 2 ปัจจัยต่อไปนี้

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

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

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

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

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

ทำความเข้าใจขอบเขตที่ละเอียดอ่อน

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

ทำความเข้าใจการใช้ขอบเขต

  • ตรวจสอบขอบเขตที่แอปใช้หรือต้องการใช้ หากต้องการดูการใช้ขอบเขตที่มีอยู่ ให้ตรวจสอบซอร์สโค้ดของแอปเพื่อดูขอบเขตที่ส่งพร้อมกับคำขอการให้สิทธิ์
  • พิจารณาว่าขอบเขตที่ขอแต่ละรายการจำเป็นสำหรับการดำเนินการที่ต้องการของฟีเจอร์แอป และใช้สิทธิ์ขั้นต่ำที่จำเป็นในการให้บริการฟีเจอร์ โดยปกติแล้ว Google API จะมี เอกสารอ้างอิงเกี่ยวกับ หน้า Google Developers ของผลิตภัณฑ์สำหรับปลายทาง ซึ่งรวมถึงขอบเขตที่จำเป็นในการเรียกปลายทางหรือพร็อพเพอร์ตี้ที่เฉพาะเจาะจงภายใน ดูข้อมูลเพิ่มเติมเกี่ยวกับขอบเขตที่จำเป็นของ การเข้าถึงสำหรับปลายทาง API ที่แอปของคุณเรียกใช้ได้ในเอกสารอ้างอิงของปลายทางเหล่านั้น
  • คุณต้องใช้ข้อมูลที่ได้รับจาก Google API ตามนโยบายของ API และในลักษณะที่คุณแสดงต่อผู้ใช้ในการดำเนินการของแอปและใน นโยบายความเป็นส่วนตัว
  • ดูเอกสารประกอบ API เพื่อดูข้อมูลเพิ่มเติมเกี่ยวกับแต่ละขอบเขต รวมถึง สถานะที่อาจเกิดขึ้น
  • ประกาศขอบเขตทั้งหมดที่แอปใช้ใน หน้าการเข้าถึงข้อมูลของ Cloud Console ระบบจะจัดกลุ่มขอบเขตที่คุณระบุเป็นหมวดหมู่ที่ละเอียดอ่อนหรือจำกัด เพื่อไฮไลต์การยืนยันเพิ่มเติมที่จำเป็น
  • ค้นหาสโคปที่ดีที่สุดที่ตรงกับข้อมูลที่การผสานรวมใช้ ทำความเข้าใจการใช้งาน ยืนยันอีกครั้งว่าทุกอย่างยังคงทำงานได้ในสภาพแวดล้อมการทดสอบ แล้วเตรียมส่งเพื่อรับการ ยืนยัน
ตารางจะแสดงชื่อ API, ขอบเขตที่มีความละเอียดอ่อนอย่างใดอย่างหนึ่ง และคำอธิบายเกี่ยวกับขอบเขต
รูปที่ 1 ตัวอย่างขอบเขตที่ละเอียดอ่อนซึ่งแสดงในหน้าขอบเขตการกำหนดค่าหน้าจอขอความยินยอม OAuth

ขั้นตอนการเตรียมพร้อมสำหรับการยืนยัน

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

  1. ยืนยันว่าแอปของคุณไม่ได้อยู่ภายใต้กรณีการใช้งานใดๆ ในส่วนข้อยกเว้นของข้อกำหนดในการยืนยัน
  2. ตรวจสอบว่าแอปของคุณเป็นไปตามข้อกำหนดด้านการสร้างแบรนด์ของ API หรือผลิตภัณฑ์ที่เชื่อมโยง เช่น ดูหลักเกณฑ์การใช้แบรนด์ สำหรับขอบเขต Google Sign-In
  3. ยืนยันการเป็นเจ้าของโดเมนที่ได้รับอนุญาตของโปรเจ็กต์ภายใน Google Search Console ใช้บัญชี Google ที่เชื่อมโยงกับโปรเจ็กต์คอนโซล API เป็น เจ้าของหรือผู้แก้ไข
  4. ตรวจสอบว่าข้อมูลการสร้างแบรนด์ทั้งหมดในหน้าจอขอความยินยอม OAuth เช่น ชื่อแอป อีเมลสนับสนุน URI ของหน้าแรก URI ของนโยบายความเป็นส่วนตัว ฯลฯ แสดงตัวตนของแอปอย่างถูกต้อง

ข้อกำหนดของหน้าแรกของแอปพลิเคชัน

ตรวจสอบว่าหน้าแรกเป็นไปตามข้อกำหนดต่อไปนี้

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

ข้อกำหนดของลิงก์นโยบายความเป็นส่วนตัวของแอปพลิเคชัน

ตรวจสอบว่านโยบายความเป็นส่วนตัวของแอปเป็นไปตามข้อกำหนดต่อไปนี้

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

วิธีส่งแอปเพื่อขอรับการยืนยันแบรนด์

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

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

หากต้องการส่งเพื่อรับการยืนยัน ให้ทำตามขั้นตอนต่อไปนี้

  1. ตรวจสอบว่าแอปของคุณเป็นไปตามข้อกำหนดในการให้บริการของ Google APIs และนโยบายข้อมูลผู้ใช้ของบริการ Google API
  2. โปรดอัปเดตบทบาทเจ้าของและผู้แก้ไขของบัญชีที่เชื่อมโยงกับโปรเจ็กต์ รวมถึงอีเมลสนับสนุนผู้ใช้และข้อมูลติดต่อของนักพัฒนาแอปใน หน้าจอขอความยินยอม OAuth ใน Cloud Console วิธีนี้จะช่วยให้สมาชิกที่เหมาะสมในทีมของคุณได้รับการแจ้งเตือนเกี่ยวกับข้อกำหนดใหม่
  3. ไปที่ Cloud Console หน้าการสร้างแบรนด์ OAuth
  4. คลิกปุ่มตัวเลือกโปรเจ็กต์

  5. ในกล่องโต้ตอบเลือกจากที่ปรากฏขึ้น ให้เลือกโปรเจ็กต์ หากไม่พบโปรเจ็กต์แต่ทราบรหัสโปรเจ็กต์ คุณสามารถสร้าง URL ในเบราว์เซอร์ได้ในรูปแบบต่อไปนี้ 

    https://console.developers.google.com/auth/branding?project=[PROJECT_ID]

    แทนที่ [PROJECT_ID] ด้วยรหัสโปรเจ็กต์ที่ต้องการใช้

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

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

  11. ใช้ปุ่มเพิ่มหรือนำขอบเขตออกเพื่อประกาศขอบเขตทั้งหมด ที่แอปของคุณขอ ระบบจะกรอกข้อมูลชุดขอบเขตเริ่มต้นที่จำเป็นสำหรับ Google Sign-In ไว้ล่วงหน้าในส่วนขอบเขตที่ไม่ละเอียดอ่อน ระบบจะจัดประเภทขอบเขตที่เพิ่มเป็นขอบเขตที่ไม่ละเอียดอ่อน sensitive, or <a href="/identity/protocols/oauth2/production-readiness/restricted-scope-verification"

    restricted

  12. ระบุลิงก์สูงสุด 3 รายการไปยังเอกสารประกอบที่เกี่ยวข้องสำหรับฟีเจอร์ที่เกี่ยวข้องในแอป

  13. ระบุข้อมูลเพิ่มเติมที่ขอเกี่ยวกับแอปของคุณในขั้นตอนถัดไป

    1. Prepare a detailed justification for each requested sensitive scope, as well as an explanation for why a narrower scope isn't sufficient. For example: "My app will use https://www.googleapis.com/auth/calendar to show a user's Google calendar data on the scheduling screen of my app. This lets users manage their schedules through my app and sync the changes with their Google calendar."

    2. Prepare a video that fully demonstrates how a user initiates and grants access to the requested scopes and shows, in detail, the usage of the granted sensitive and restricted scopes in the app. Upload the video to YouTube Studio and set its Visibility as Unlisted. You need to provide a link to the demonstration video in the YouTube link field.

      1. Show the OAuth grant process that users will experience, in English. This includes the consent flow and, if you use Google Sign-In, the sign-in flow.
      2. Show that the OAuth consent screen correctly displays the App Name.
      3. Show that the browser address bar of the OAuth consent screen correctly includes your app's OAuth client ID.
      4. To show how the data will be used, demonstrate the functionality that's enabled by each sensitive scope that you request.

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

ข้อยกเว้นสำหรับข้อกำหนดในการยืนยัน

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

การใช้งานส่วนตัว

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

โปรเจ็กต์ที่ใช้ในระดับการพัฒนา การทดสอบ หรือการจัดเตรียม

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

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

ข้อความเตือนว่า Google ยังไม่ได้ยืนยันแอปที่อยู่ระหว่างการทดสอบ
รูปภาพ 2 หน้าจอคำเตือนสำหรับผู้ทดสอบ

ข้อมูลที่บริการเป็นเจ้าของเท่านั้น

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

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

ใช้ภายในเท่านั้น

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

การติดตั้งทั่วทั้งโดเมน

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

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