แนวทางปฏิบัติแนะนำ

จัดการข้อมูลเข้าสู่ระบบของไคลเอ็นต์อย่างปลอดภัย

ข้อมูลเข้าสู่ระบบไคลเอ็นต์ OAuth จะระบุตัวตนของแอปและควรได้รับการจัดการอย่างระมัดระวัง จัดเก็บข้อมูลเข้าสู่ระบบเหล่านี้ในที่เก็บข้อมูลที่ปลอดภัยเท่านั้น เช่น ใช้เครื่องมือจัดการข้อมูลลับอย่าง Google Cloud Secret Manager อย่าฮาร์ดโค้ดข้อมูลเข้าสู่ระบบ ส่งไปยังที่เก็บโค้ด หรือเผยแพร่ต่อสาธารณะ

จัดการโทเค็นผู้ใช้อย่างปลอดภัย

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

เพิกถอนโทเค็นทันทีที่ ไม่จำเป็นต้องใช้แล้ว และลบโทเค็นออกจากระบบอย่างถาวร

นอกจากนี้ โปรดพิจารณาแนวทางปฏิบัติแนะนำต่อไปนี้สำหรับแพลตฟอร์มของคุณด้วย

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

จัดการการเพิกถอนและการหมดอายุของโทเค็นการรีเฟรช

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

ใช้การให้สิทธิ์แบบเพิ่มทีละส่วน

ใช้การให้สิทธิ์ แบบเพิ่มทีละรายการเพื่อขอขอบเขต OAuth ที่เหมาะสมเมื่อแอปพลิเคชันของคุณต้องการฟังก์ชันการทำงาน

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

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

ตัวอย่างเช่น แอปพลิเคชันของคุณอาจใช้รูปแบบต่อไปนี้

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

จัดการความยินยอมสำหรับขอบเขตหลายรายการ

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

หากฟังก์ชันพื้นฐานของแอปต้องใช้ขอบเขตหลายรายการ โปรดอธิบายให้ผู้ใช้ทราบก่อน ขอความยินยอม

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

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

ใช้เบราว์เซอร์ที่ปลอดภัย

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

การสร้างและการกำหนดค่าไคลเอ็นต์ OAuth ด้วยตนเอง

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

สำหรับเวิร์กโฟลว์อัตโนมัติ ให้พิจารณาใช้บัญชีบริการแทน

นำไคลเอ็นต์ OAuth ที่ไม่ได้ใช้ออก

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

เพื่อลดความเสี่ยงจากไคลเอ็นต์ที่ไม่ได้ใช้เพิ่มเติม ไคลเอ็นต์ OAuth 2.0 ที่ไม่ได้ใช้งานเป็นเวลา 6 เดือนจะ ถูกลบโดยอัตโนมัติ

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