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

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

ข้อมูลเข้าสู่ระบบของไคลเอ็นต์ 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) แม้ว่าบุคคลใดก็ตามที่สกัดกั้นโทเค็นสำหรับผู้ถือแบบมาตรฐานจะใช้โทเค็นดังกล่าวได้ แต่โทเค็น DPoP จะเชื่อมโยงกับการเข้ารหัสลับกับคู่คีย์ที่ไม่ซ้ำกันซึ่งสร้างและเก็บไว้โดยไคลเอ็นต์

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

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

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

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

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

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

ใช้พารามิเตอร์สถานะ

ก่อนจัดการการตอบกลับ 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 สำหรับแพลตฟอร์มของคุณแทน

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

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

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

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

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

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

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