ภาพรวม

ฉันต้องการสร้าง API (REST) ​​สำหรับแอปพลิเคชันของฉัน วัตถุประสงค์เริ่มต้น / หลักจะใช้เพื่อการบริโภคโดยแอพมือถือ (iPhone, Android, Symbian และอื่น ๆ ) ฉันได้ดูกลไกที่แตกต่างกันสำหรับการรับรองความถูกต้องและการอนุญาตสำหรับ API บนเว็บ (โดยศึกษาการใช้งานอื่น ๆ ) ฉันมีหัวของฉันห่อหุ้มแนวคิดพื้นฐานส่วนใหญ่ แต่ฉันยังคงมองหาคำแนะนำในบางพื้นที่ สิ่งสุดท้ายที่ฉันต้องการทำคือสร้างวงล้อใหม่ แต่ฉันไม่พบวิธีแก้ปัญหามาตรฐานใด ๆ ที่เหมาะกับเกณฑ์ของฉัน (แต่เกณฑ์ของฉันถูกเข้าใจผิด นอกจากนี้ฉันต้องการให้ API เหมือนกันสำหรับทุกแพลตฟอร์ม / แอปพลิเคชันที่ใช้งาน

oAuth

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

ความต้องการ

1. ผู้ใช้ป้อนชื่อผู้ใช้ / รหัสผ่านลงในแอปพลิเคชัน
2. การเรียก API ทุกครั้งจะมีการระบุโดยแอปพลิเคชันการโทร
3. ค่าโสหุ้ยถูกเก็บไว้ให้น้อยที่สุดและการตรวจสอบสิทธิ์นั้นใช้งานง่ายสำหรับนักพัฒนา
4. กลไกมีความปลอดภัยสำหรับผู้ใช้ปลายทาง (ไม่เปิดเผยข้อมูลการเข้าสู่ระบบของผู้ใช้) รวมถึงผู้พัฒนา (ไม่เปิดเผยข้อมูลรับรองแอปพลิเคชัน)
5. หากเป็นไปได้ไม่จำเป็นต้องมี https (ไม่ได้หมายความว่าเป็นข้อกำหนดที่ยาก)

ความคิดปัจจุบันของฉันเกี่ยวกับการนำไปใช้

นักพัฒนาภายนอกจะขอบัญชี API พวกเขาจะได้รับ apikey และ apisecret ทุกคำขอจะต้องมีอย่างน้อยสามพารามิเตอร์

• apikey - มอบให้กับผู้พัฒนาที่ลงทะเบียน
• timestamp - เพิ่มเป็นสองเท่าของตัวระบุที่ไม่ซ้ำกันสำหรับแต่ละข้อความสำหรับ apikey ที่กำหนด
• hash - แฮชของการประทับเวลา + apisecret

apikey จำเป็นต้องระบุแอปพลิเคชันที่ออกคำขอ การประทับเวลาทำหน้าที่คล้ายกับ oauth_nonce และหลีกเลี่ยง / บรรเทาการโจมตีซ้ำ แฮชทำให้แน่ใจว่าคำขอนั้นออกจริงจากเจ้าของ apikey ที่ให้ไว้

สำหรับคำขอที่ได้รับการรับรองความถูกต้อง (คำขอที่ทำในนามของผู้ใช้) ฉันยังไม่แน่ใจว่าจะไปกับเส้นทาง access_token หรือชื่อผู้ใช้และคำสั่งผสมแฮชของรหัสผ่าน ไม่ว่าจะด้วยวิธีใดในบางกรณีจำเป็นต้องใช้คอมโบ / ชื่อผู้ใช้ / รหัสผ่าน ดังนั้นเมื่อมีการแฮชข้อมูลหลายชิ้น (apikey, apisecret, timestamp) + รหัสผ่านจะถูกใช้ ฉันชอบความคิดเห็นเกี่ยวกับเรื่องนี้ FYI พวกเขาจะต้องแฮรหัสผ่านก่อนเพราะฉันจะไม่เก็บรหัสผ่านในระบบของฉันโดยไม่ต้องแฮช

ข้อสรุป

FYI, นี่ไม่ใช่คำขอสำหรับวิธีการสร้าง / โครงสร้าง API โดยทั่วไปเท่านั้นวิธีจัดการการรับรองความถูกต้องและการอนุญาตจากภายในแอปพลิเคชันเท่านั้น

คำถามสุ่ม / คำถามโบนัส

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

พูดถึง hashes แล้ว md5 กับ hmac-sha1 ล่ะ? มันมีความสำคัญจริง ๆ หรือไม่เมื่อค่าทั้งหมดถูกแฮชด้วยข้อมูลที่มีความยาวเพียงพอ (เช่น apisecret)

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

วิธีที่ฉันคิดเกี่ยวกับการทำส่วนล็อกอินของโครงการนี้คือ

1. ก่อนเข้าสู่ระบบผู้ใช้ร้องขอlogin_tokenจากเซิร์ฟเวอร์ สิ่งเหล่านี้ถูกสร้างขึ้นและเก็บไว้บนเซิร์ฟเวอร์ตามคำขอและอาจมีอายุการใช้งานที่ จำกัด

2. เพื่อเข้าสู่ระบบแอปพลิเคชันจะคำนวณแฮชของรหัสผ่านผู้ใช้จากนั้นแฮชรหัสผ่านด้วยlogin_tokenเพื่อรับค่าจากนั้นพวกเขาจะส่งคืนทั้งlogin_tokenแฮชและรวม

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

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

นั่นเป็นคำถามจำนวนมากในหนึ่งเดียวฉันเดาว่ามีบางคนที่ไม่สามารถอ่านจนจบ :)

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

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

สำหรับ hashing, sha1 นั้นดีกว่านิดหน่อย แต่อย่าไปยุ่งเกี่ยวกับเรื่องนี้ - อุปกรณ์อะไรก็ตามที่สามารถใช้งานได้ง่ายและรวดเร็ว (ในแง่ของประสิทธิภาพ) อาจจะใช้ได้

หวังว่าจะช่วยโชคดี :)

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

สมมติว่าเป็นกรณีนี้จากนั้นฉันจะเข้าใกล้ดังต่อไปนี้ (แต่ 'cos ฉันเป็นนักพัฒนา Java ดังนั้น C # คนที่แต่งตัวประหลาดจะทำมันแตกต่างกัน):

บริการรับรองความถูกต้อง RESTful และการอนุญาต

1. สิ่งนี้จะทำงานผ่าน HTTPS เท่านั้นเพื่อป้องกันการดักฟัง
2. มันจะขึ้นอยู่กับการรวมกันของRESTEasy , Spring SecurityและCAS (สำหรับการลงชื่อเพียงครั้งเดียวในหลาย ๆ แอปพลิเคชัน)
3. มันจะทำงานกับทั้งเบราว์เซอร์และแอปพลิเคชันไคลเอนต์ที่เปิดใช้งานเว็บ
4. จะมีอินเทอร์เฟซการจัดการบัญชีบนเว็บเพื่อให้ผู้ใช้สามารถแก้ไขรายละเอียดและผู้ดูแลระบบ (สำหรับแอปพลิเคชันเฉพาะ) เพื่อเปลี่ยนระดับการอนุญาต

ไลบรารี / แอ็พพลิเคชันความปลอดภัยฝั่งไคลเอ็นต์

1. สำหรับแต่ละแพลตฟอร์มที่รองรับ (เช่น Symbian, Android, iOS ฯลฯ ) สร้างการใช้งานที่เหมาะสมของห้องสมุดความปลอดภัยในภาษาดั้งเดิมของแพลตฟอร์ม (เช่น Java, ObjectiveC, C ฯลฯ )
2. ห้องสมุดควรจัดการรูปแบบคำขอ HTTPS โดยใช้ API ที่มีอยู่สำหรับแพลตฟอร์มที่กำหนด (เช่น Java ใช้ URLConnection เป็นต้น)
3. ผู้ใช้ทั่วไปของการรับรองความถูกต้องและการอนุญาต (นั่นคือทั้งหมด) จะโค้ดไปยังอินเทอร์เฟซที่เฉพาะเจาะจงและจะไม่ดีใจถ้ามีการเปลี่ยนแปลงเพื่อให้แน่ใจว่ามันมีความยืดหยุ่นมาก ติดตามตัวเลือกการออกแบบที่มีอยู่เช่น Spring Security

ดังนั้นตอนนี้มุมมองจาก 30,000 ฟุตเสร็จสมบูรณ์คุณจะทำอย่างไร ไม่ใช่เรื่องยากที่จะสร้างระบบรับรองความถูกต้องและการอนุญาตตามเทคโนโลยีที่อยู่ในรายการด้านเซิร์ฟเวอร์ด้วยเบราว์เซอร์ไคลเอ็นต์ เมื่อใช้ร่วมกับ HTTPS เฟรมเวิร์กจะจัดเตรียมกระบวนการที่ปลอดภัยโดยอิงตามโทเค็นที่ใช้ร่วมกัน (โดยปกติจะแสดงเป็นคุกกี้) ที่สร้างขึ้นโดยกระบวนการรับรองความถูกต้องและใช้เมื่อใดก็ตามที่ผู้ใช้ต้องการทำบางสิ่ง โทเค็นนี้จะแสดงโดยไคลเอนต์ไปยังเซิร์ฟเวอร์เมื่อใดก็ตามที่คำขอเกิดขึ้น

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

1. แอปพลิเคชันไคลเอนต์มี Access Control List (ACL) ที่กำหนดไว้ซึ่งควบคุมการเข้าถึงรันไทม์ไปยังการเรียกใช้เมธอด ตัวอย่างเช่นผู้ใช้ที่กำหนดสามารถอ่านคอลเลกชันจากวิธีการ แต่ ACL ของพวกเขาอนุญาตให้เข้าถึงวัตถุที่มี Q ในชื่อของพวกเขาดังนั้นข้อมูลบางอย่างในคอลเลกชันที่ดึง quiety โดยความปลอดภัย interceptor ใน Java สิ่งนี้ตรงไปตรงมาคุณเพียงแค่ใช้คำอธิบายประกอบ Spring Security บนรหัสการโทรและใช้กระบวนการตอบสนอง ACL ที่เหมาะสม ในภาษาอื่นคุณเป็นของคุณเองและอาจจำเป็นต้องจัดเตรียมรหัสความปลอดภัยสำเร็จรูปที่โทรเข้าสู่ห้องสมุดความปลอดภัยของคุณ หากภาษารองรับ AOP (Aspect Oriented Programming) ให้ใช้อย่างเต็มที่สำหรับสถานการณ์นี้
2. ห้องสมุดความปลอดภัยเก็บรายการที่ได้รับอนุญาตทั้งหมดไว้ในหน่วยความจำส่วนตัวสำหรับแอปพลิเคชันปัจจุบันเพื่อให้ไม่ต้องเชื่อมต่อ ขึ้นอยู่กับความยาวของเซสชันการเข้าสู่ระบบนี่อาจเป็นการดำเนินการครั้งเดียวที่ไม่เคยทำซ้ำ

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

หวังว่านี่จะช่วยและขอให้โชคดีกับกิจการของคุณ หากคุณต้องการข้อมูลเพิ่มเติมแจ้งให้เราทราบ - ฉันได้เขียนแอปพลิเคชันบนเว็บบางส่วนตาม Spring Security, ACLs และอื่น ๆ

ทวิตเตอร์จ่าหน้าปัญหาโปรแกรมภายนอกใน oAuth โดยการสนับสนุนที่แตกต่างที่พวกเขาเรียกxauth น่าเสียดายที่มีชื่ออื่น ๆ อีกมากมายที่มีชื่อนี้อยู่แล้วดังนั้นจึงอาจสร้างความสับสนให้กับการเรียงลำดับ

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

ไม่ว่าในกรณีใดฉันต้องการเห็นด้วยกับสัญชาตญาณของคุณและของผู้ตอบคำถามอื่น ๆ ที่นี่: อย่าพยายามสร้างสิ่งใหม่ตั้งแต่เริ่มต้น โพรโทคอลความปลอดภัยสามารถเริ่มต้นได้ง่าย แต่มักจะทำได้ยากและยิ่งซับซ้อนก็ยิ่งทำให้ผู้พัฒนาบุคคลที่สามของคุณมีโอกาสน้อยลงที่จะสามารถนำมาใช้กับพวกเขาได้ โปรโตคอลสมมุติฐานของคุณคล้ายกับ o (x) Auth - api_key / api_secret, nonce, sha1 hashing - แต่แทนที่จะสามารถใช้หนึ่งในห้องสมุดที่มีอยู่จำนวนมากที่นักพัฒนาของคุณจะต้องม้วนเอง

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

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

ในการแก้ปัญหาที่เสนอคุณพูดถึงว่าอย่างน้อยสามพารามิเตอร์จะต้อง:

• apikey - มอบให้กับนักพัฒนาเมื่อลงทะเบียน
• timestamp - เพิ่มเป็นสองเท่าของตัวระบุที่ไม่ซ้ำกันสำหรับแต่ละข้อความสำหรับ apikey ที่กำหนด
• hash - แฮชของการประทับเวลา + apisecret

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

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

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

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

ยิ่งไปกว่านั้นคุณสามารถเริ่มต้นทำงานในโดเมนของงานประจำวันของฉันได้อย่างง่ายดาย อย่างไรก็ตามมันเป็นอีกแง่มุมหนึ่งของการรักษาความปลอดภัย API ที่ฉันคิดว่ามีความสำคัญและต้องการตั้งค่าสถานะ