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

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

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

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

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

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