ข้อมูลลับของไคลเอ็นต์ใน OAuth 2.0

ในการใช้ google drive api ฉันต้องเล่นกับการรับรองความถูกต้องโดยใช้ OAuth2.0 และฉันมีคำถามสองสามข้อเกี่ยวกับเรื่องนี้

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

2. ในแอปพลิเคชันมือถือเราสามารถฝังมุมมองเว็บลงในแอปของเราได้ และง่ายต่อการแยกช่องรหัสผ่านใน webview เนื่องจากแอปที่ขออนุญาตเป็น "เบราว์เซอร์" จริงๆ ดังนั้น OAuth ในแอปพลิเคชันมือถือจึงไม่มีประโยชน์ที่แอปพลิเคชันไคลเอนต์ไม่สามารถเข้าถึงข้อมูลรับรองผู้ใช้ของผู้ให้บริการ?

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

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

   ตัวอย่างเช่นมีข้อบกพร่องบางอย่างในไลบรารีของ Facebook สำหรับ Android ซึ่งมีการรั่วไหลของโทเค็นไปยังบันทึกคุณสามารถดูข้อมูลเพิ่มเติมได้ที่นี่ http://attack-secure.com/all-your-facebook-access-tokens-are-belong -to- เรา และนี่https://www.youtube.com/watch?v=twyL7Uxe6sk โดยรวมแล้วควรระมัดระวังเป็นพิเศษในการใช้งานไลบรารีของบุคคลที่สาม (โดยทั่วไปแล้ว แต่ถ้าการจี้โทเค็นเป็นข้อกังวลใหญ่ของคุณให้เพิ่มความระมัดระวังเป็นพิเศษ)

2. ฉันคุยโวเกี่ยวกับจุดที่ 2 มาระยะหนึ่งแล้ว ฉันได้ดำเนินการแก้ไขปัญหาบางอย่างในแอปของฉันเพื่อแก้ไขหน้าคำยินยอม (เช่นการเปลี่ยนการซูมและการออกแบบให้พอดีกับแอป) แต่ไม่มีอะไรหยุดฉันจากการอ่านค่าจากช่องต่างๆในมุมมองเว็บด้วยชื่อผู้ใช้และรหัสผ่าน ดังนั้นฉันจึงเห็นด้วยอย่างยิ่งกับประเด็นที่สองของคุณและพบว่ามันเป็น "ข้อบกพร่อง" ที่ยิ่งใหญ่ในข้อกำหนด OAuth ชี้ว่า "แอปไม่สามารถเข้าถึงข้อมูลรับรองผู้ใช้" ในข้อมูลจำเพาะเป็นเพียงความฝันและทำให้ผู้ใช้รู้สึกปลอดภัยที่ผิดพลาด ... นอกจากนี้ฉันเดาว่าผู้คนมักจะสงสัยเมื่อแอปขอ Facebook, Twitter, Dropbox หรือข้อมูลรับรองอื่น ๆ ฉันสงสัยว่าคนธรรมดาหลายคนอ่านข้อมูลจำเพาะของ OAuth และพูดว่า "ตอนนี้ฉันปลอดภัยแล้ว" แต่ใช้สามัญสำนึกแทนและโดยทั่วไปจะไม่ใช้แอปที่พวกเขาไม่เชื่อถือ

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

1. ลูกค้าต้องได้รับรหัสการอนุญาตโดยตรงจากผู้ใช้ไม่ใช่จากบริการ

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

2. URL การเปลี่ยนเส้นทางถูกลงทะเบียนด้วยรหัสไคลเอ็นต์ / ความลับ

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

ตอบคำถามที่ 2: Google API ด้วยเหตุผลด้านความปลอดภัยกำหนดว่าการตรวจสอบสิทธิ์ / ลงชื่อเข้าใช้ไม่สามารถทำได้ภายในแอปเอง (เช่นไม่อนุญาตให้มีการดูเว็บ) และต้องดำเนินการภายนอกแอปโดยใช้เบราว์เซอร์เพื่อความปลอดภัยที่ดีขึ้นซึ่งจะอธิบายเพิ่มเติมด้านล่าง: https: //developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html