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

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

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

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

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

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

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

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

จำกัดผู้ส่งโทเค็นด้วย DPoP

หากต้องการปกป้องแอปพลิเคชันของคุณจากการขโมยโทเค็นและการโจมตีแบบ Replay ให้พิจารณาจำกัดผู้ส่งโทเค็นโดยใช้ DPoP (Demonstrating Proof-of-Possession) แม้ว่าโทเค็น Bearer มาตรฐานจะใช้ได้โดยบุคคลที่สามที่ดักรับโทเค็น แต่โทเค็น DPoP จะเชื่อมโยงกับคู่คีย์ที่ไม่ซ้ำกันซึ่งไคลเอ็นต์สร้างและเก็บไว้ด้วยการเข้ารหัส

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

DPoP ทำงานร่วมกับ PKCE เพื่อให้การปกป้องที่ครอบคลุม ดังนี้

• PKCE จะปกป้องรหัสการให้สิทธิ์ในระหว่างขั้นตอนการเปลี่ยนเส้นทางเริ่มต้น
• DPoP จะปกป้องโทเค็นการรีเฟรชที่มีอายุการใช้งานยาวนาน ซึ่งจะป้องกันการโจมตีแบบ Replay หากโทเค็นถูกบุกรุก

เราขอแนะนำอย่างยิ่งให้ใช้ DPoP หากแอปพลิเคชันของคุณมีลักษณะดังนี้

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

ดูวิธีการโดยละเอียดในการสร้างหลักฐาน DPoP และขอโทเค็นที่เชื่อมโยงกับ DPoP ได้ใน เอกสารประกอบ DPoP

ใช้พารามิเตอร์ `state`

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

การใช้พารามิเตอร์ state จะช่วยให้มั่นใจได้ว่าผู้ใช้เป็นผู้ส่งคำขอ ไม่ใช่สคริปต์ที่เป็นอันตราย และลดความเสี่ยงของการโจมตีแบบปลอมแปลงคำขอข้ามเว็บไซต์ (CSRF)

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

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

ใช้การให้สิทธิ์ทีละส่วน

ใช้การให้สิทธิ์ ทีละส่วนเพื่อขอขอบเขต 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 Cloud เพื่อยอมรับข้อกำหนดในการให้บริการอย่างชัดแจ้ง กำหนดค่า ไคลเอ็นต์ OAuth และเตรียมพร้อมสำหรับการยืนยัน OAuth

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

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

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

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

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