บริการเว็บ RESTful - จะตรวจสอบสิทธิ์คำขอจากบริการอื่นได้อย่างไร?

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

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

ตัวเลือกที่ฉันคิดได้ (หรือได้รับการแนะนำให้ฉัน):

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

2. กำหนดรหัสแอปพลิเคชันถาวรสำหรับบริการไคลเอ็นต์ซึ่งอาจเป็นรหัสแอปพลิเคชันด้วย เท่าที่ฉันเข้าใจนี่ก็เหมือนกับการมี username + password ด้วยรหัสและรหัสนี้ฉันสามารถตรวจสอบสิทธิ์แต่ละคำขอหรือสร้างโทเค็นการตรวจสอบสิทธิ์เพื่อพิสูจน์ตัวตนคำขอเพิ่มเติม ไม่ว่าจะด้วยวิธีใดฉันไม่ชอบตัวเลือกนี้เพราะใครก็ตามที่ได้รับรหัสแอปพลิเคชันและคีย์สามารถแอบอ้างเป็นลูกค้าได้

3. ฉันสามารถเพิ่มการตรวจสอบที่อยู่ IP ในตัวเลือกก่อนหน้าได้ ซึ่งจะทำให้คำขอปลอมทำได้ยากขึ้น

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

5. อย่างอื่น - ต้องมีวิธีแก้ปัญหาอื่น ๆ หรือไม่?

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

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

ฉันไม่คิดว่าจุด A สำหรับโซลูชันใบรับรองไคลเอ็นต์ของคุณยากที่จะแก้ไข คุณเพียงแค่ใช้สาขา if (client side certificat) { check it } else { http basic auth }ฉันไม่ใช่ผู้เชี่ยวชาญด้าน java และฉันไม่เคยทำงานกับมันเพื่อทำใบรับรองฝั่งไคลเอ็นต์ อย่างไรก็ตาม Google ฉบับย่อนำเราไปสู่บทช่วยสอนนี้ซึ่งจะดูตรงซอยของคุณ

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

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

หลังจากอ่านคำถามของคุณฉันจะบอกว่าสร้างโทเค็นพิเศษเพื่อทำตามคำขอ โทเค็นนี้จะอยู่ในช่วงเวลาที่กำหนด (บอกว่าในหนึ่งวัน)

นี่คือตัวอย่างจากการสร้างโทเค็นการตรวจสอบความถูกต้อง:

(day * 10) + (month * 100) + (year (last 2 digits) * 1000)

ตัวอย่างเช่น 3 มิถุนายน 2554

(3 * 10) + (6 * 100) + (11 * 1000) = 
30 + 600 + 11000 = 11630

จากนั้นเชื่อมต่อกับรหัสผ่านของผู้ใช้ตัวอย่างเช่น "my4wesomeP4ssword!"

11630my4wesomeP4ssword!

จากนั้นทำ MD5 ของสตริงนั้น:

05a9d022d621b64096160683f3afe804

คุณเรียกคำขอเมื่อใดให้ใช้โทเค็นนี้เสมอ

https://mywebservice.com/?token=05a9d022d621b64096160683f3afe804&op=getdata

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

หวังว่าจะช่วยได้

:)

มีหลายวิธีที่คุณสามารถทำได้

1. RESTful purists ต้องการให้คุณใช้การรับรองความถูกต้องพื้นฐานและส่งข้อมูลรับรองในทุกคำขอ เหตุผลของพวกเขาคือไม่มีใครเก็บรัฐใด ๆ

2. ฝ่ายบริการลูกค้าสามารถจัดเก็บคุกกี้ซึ่งเก็บรักษารหัสเซสชันไว้ โดยส่วนตัวแล้วฉันไม่คิดว่าสิ่งนี้น่ารังเกียจเหมือนคนเจ้าระเบียบบางคนที่ฉันได้ยินมา - อาจมีราคาแพงในการตรวจสอบสิทธิ์ซ้ำแล้วซ้ำเล่า ดูเหมือนว่าคุณจะไม่ชอบความคิดนี้มากเกินไป

3. จากคำอธิบายของคุณดูเหมือนว่าคุณอาจสนใจOAuth2ประสบการณ์ของฉันจนถึงตอนนี้จากที่ฉันเคยเห็นมาคือมันค่อนข้างสับสนและมีเลือดออก มีการใช้งานอยู่ที่นั่น แต่มีน้อยและอยู่ไกล ใน Java ฉันเข้าใจว่าได้รวมเข้ากับโมดูลความปลอดภัยของ Spring3 แล้ว ( บทช่วยสอนของพวกเขาเขียนไว้อย่างดี) ฉันรอดูว่าจะมีส่วนขยายในRestletหรือไม่ แต่จนถึงตอนนี้แม้ว่าจะมีการเสนอและอาจอยู่ในตู้อบ แต่ก็ยังไม่ได้รวมเข้าด้วยกันอย่างสมบูรณ์

ฉันเชื่อว่าแนวทาง:

1. คำขอแรกลูกค้าส่ง id / passcode
2. แลกเปลี่ยน id / pass สำหรับโทเค็นที่ไม่ซ้ำกัน
3. ตรวจสอบโทเค็นสำหรับแต่ละคำขอที่ตามมาจนกว่าจะหมดอายุ

ค่อนข้างเป็นมาตรฐานไม่ว่าคุณจะใช้งานอย่างไรและรายละเอียดทางเทคนิคเฉพาะอื่น ๆ

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

หวังว่านี่จะช่วยได้

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

หากคุณได้สร้างหน่วยงานรับรองที่ลงนามด้วยตนเองและออกใบรับรองลูกค้าให้กับบริการลูกค้าแต่ละรายคุณจะมีวิธีง่ายๆในการตรวจสอบสิทธิ์บริการเหล่านั้น

ขึ้นอยู่กับเว็บเซิร์ฟเวอร์ที่คุณใช้ควรมีวิธีการระบุการรับรองความถูกต้องของไคลเอ็นต์ที่จะยอมรับใบรับรองไคลเอ็นต์ แต่ไม่จำเป็นต้องใช้ ตัวอย่างเช่นใน Tomcat เมื่อระบุตัวเชื่อมต่อ https คุณสามารถตั้งค่า "clientAuth = want" แทน "true" หรือ "false" จากนั้นคุณต้องแน่ใจว่าได้เพิ่มใบรับรอง CA ที่ลงนามด้วยตนเองไปยัง Truststore ของคุณ (โดยค่าเริ่มต้นคือไฟล์ cacerts ใน JRE ที่คุณใช้เว้นแต่คุณจะระบุไฟล์อื่นในการกำหนดค่าเว็บเซิร์ฟเวอร์ของคุณ) ดังนั้นใบรับรองที่เชื่อถือได้เท่านั้นจึงจะเป็นใบรับรองที่ออกจาก CA ของคุณลงนามด้วยตนเอง

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

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

5. อย่างอื่น - ต้องมีวิธีแก้ปัญหาอื่น ๆ หรือไม่?

คุณพูดถูกมี! และเรียกว่า JWT (JSON Web Tokens)

JSON Web Token (JWT) เป็นมาตรฐานแบบเปิด (RFC 7519) ที่กำหนดวิธีที่กะทัดรัดและมีอยู่ในตัวสำหรับการส่งข้อมูลอย่างปลอดภัยระหว่างฝ่ายต่างๆในรูปแบบวัตถุ JSON ข้อมูลนี้สามารถตรวจสอบและเชื่อถือได้เนื่องจากมีการลงนามแบบดิจิทัล JWT สามารถลงนามได้โดยใช้ความลับ (ด้วยอัลกอริทึม HMAC) หรือคู่คีย์สาธารณะ / ส่วนตัวโดยใช้ RSA

ฉันขอแนะนำเป็นอย่างยิ่งให้ดู JWT เป็นวิธีแก้ปัญหาที่ง่ายกว่ามากเมื่อเปรียบเทียบกับวิธีแก้ปัญหาอื่น ๆ

https://jwt.io/introduction/

คุณสามารถสร้างเซสชันบนเซิร์ฟเวอร์และแชร์sessionIdระหว่างไคลเอนต์และเซิร์ฟเวอร์ด้วยการเรียก REST แต่ละครั้ง

1. ตรวจสอบสิทธิ์คำขอ REST ครั้งแรก: /authenticate. ส่งคืนการตอบกลับ (ตามรูปแบบไคลเอนต์ของคุณ) ด้วยsessionId: ABCDXXXXXXXXXXXXXX;

2. ร้านนี้sessionIdอยู่ในMapกับเซสชั่นที่เกิดขึ้นจริง Map.put(sessionid, session)หรือใช้SessionListenerสร้างและทำลายกุญแจสำหรับคุณ

   public void sessionCreated(HttpSessionEvent arg0) {
     // add session to a static Map 
   }
   
   public void sessionDestroyed(HttpSessionEvent arg0) {
     // Remove session from static map
   }
   

3. รับ sessionid ทุกครั้งที่เรียก REST เช่นURL?jsessionid=ABCDXXXXXXXXXXXXXX(หรือวิธีอื่น ๆ );

4. ดึงHttpSessionข้อมูลจากแผนที่โดยใช้sessionId;
5. ตรวจสอบคำร้องขอสำหรับเซสชันนั้นหากเซสชันทำงานอยู่
6. ส่งการตอบกลับหรือข้อความแสดงข้อผิดพลาด

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

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