วิธีจัดการกับการรับรองความถูกต้องในสถาปัตยกรรม RESTful ไคลเอนต์ - เซิร์ฟเวอร์เป็นเรื่องของการอภิปราย
โดยทั่วไปสามารถทำได้ใน SOA ผ่าน HTTP โลกผ่าน:
- HTTP การตรวจสอบขั้นพื้นฐานผ่าน HTTPS;
- คุกกี้และการจัดการเซสชัน
- โทเค็นในส่วนหัว HTTP (เช่นOAuth 2.0 + JWT);
- การตรวจสอบแบบสอบถามด้วยพารามิเตอร์ลายเซ็นเพิ่มเติม
คุณจะต้องปรับหรือผสมผสานเทคนิคเหล่านั้นให้ดีขึ้นเพื่อให้เข้ากับสถาปัตยกรรมซอฟต์แวร์ของคุณอย่างดีที่สุด
แต่ละรูปแบบการรับรองความถูกต้องมีข้อดีและข้อเสียของตนเองขึ้นอยู่กับวัตถุประสงค์ของนโยบายความปลอดภัยและสถาปัตยกรรมซอฟต์แวร์ของคุณ
HTTP การตรวจสอบขั้นพื้นฐานผ่าน HTTPS
โซลูชันแรกนี้ใช้ HTTPS โปรโตคอลมาตรฐานซึ่งเว็บเซอร์วิสส่วนใหญ่ใช้
GET /spec.html HTTP/1.1
Host: www.example.org
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
เป็นเรื่องง่ายที่จะติดตั้งใช้งานได้ตามค่าเริ่มต้นในเบราว์เซอร์ทั้งหมด แต่มีข้อบกพร่องบางอย่างที่รู้จักเช่นหน้าต่างการตรวจสอบสิทธิ์ที่น่ากลัวที่แสดงบนเบราว์เซอร์ซึ่งจะคงอยู่ (ไม่มีคุณสมบัติเหมือน LogOut) และความจริงที่ว่าชื่อผู้ใช้และรหัสผ่านถูกส่ง (ผ่าน HTTPS) ไปยังเซิร์ฟเวอร์ (ควรมีความปลอดภัยมากกว่าเพื่อให้รหัสผ่านอยู่ที่ฝั่งไคลเอ็นต์เท่านั้นในระหว่างการป้อนคีย์บอร์ดและถูกเก็บเป็นแฮชที่ปลอดภัยบนเซิร์ฟเวอร์) .
เราอาจใช้การรับรองความถูกต้องแบบแยกย่อยแต่ต้องใช้ HTTPS ด้วยเนื่องจากมีความเสี่ยงต่อการโจมตีแบบMiMหรือReplayและเฉพาะกับ HTTP
เซสชันผ่านคุกกี้
ความจริงแล้วเซสชันที่จัดการบนเซิร์ฟเวอร์นั้นไม่ไร้สัญชาติอย่างแท้จริง
ความเป็นไปได้อย่างหนึ่งคือการรักษาข้อมูลทั้งหมดภายในเนื้อหาของคุกกี้ และตามการออกแบบคุกกี้นั้นจะถูกจัดการที่ฝั่งเซิร์ฟเวอร์ (ที่จริงแล้วไคลเอนต์ไม่ได้พยายามตีความข้อมูลคุกกี้นี้: มันแค่ส่งกลับไปที่เซิร์ฟเวอร์ในแต่ละคำขอที่ต่อเนื่อง) แต่ข้อมูลคุกกี้นี้เป็นข้อมูลสถานะแอปพลิเคชันดังนั้นลูกค้าควรจัดการไม่ใช่เซิร์ฟเวอร์ในโลกไร้สัญชาติ
GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123
เทคนิคคุกกี้นั้นเชื่อมโยงกับ HTTP ดังนั้นจึงไม่สงบจริง ๆ ซึ่งควรเป็นโปรโตคอลอิสระ IMHO มีความเสี่ยงต่อการโจมตีMiMหรือReplay
ได้รับผ่าน Token (OAuth2)
อีกทางเลือกหนึ่งคือการใส่โทเค็นภายในส่วนหัว HTTP เพื่อให้การรับรองความถูกต้อง นี่คือสิ่งที่OAuth 2.0 ทำตัวอย่างเช่น ดูRFC 6749 :
GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Bearer mF_9.B5f-4.1JqM
ในระยะสั้นนี้จะคล้ายกับคุกกี้และเป็นปัญหาเดียวกัน: ไม่ไร้สัญชาติอาศัยรายละเอียดการส่ง HTTP และอาจมีจุดอ่อนด้านความปลอดภัยจำนวนมากรวมถึง MiM และ Replay ดังนั้นจะใช้งานผ่าน HTTPS เท่านั้น โดยทั่วไปแล้วJWTจะใช้เป็นโทเค็น
การรับรองความถูกต้องของแบบสอบถาม
การรับรองความถูกต้องของแบบสอบถามประกอบด้วยการลงนามคำขอ RESTful แต่ละรายการผ่านพารามิเตอร์เพิ่มเติมบางอย่างใน URI ดูบทความนี้อ้างอิง
มันถูกกำหนดเช่นนี้ในบทความนี้:
เคียวรี REST ทั้งหมดต้องถูกพิสูจน์ตัวตนโดยการลงนามพารามิเตอร์เคียวรีเรียงลำดับตามตัวอักษรพิมพ์เล็กโดยใช้หนังสือรับรองไพรเวตเป็นโทเค็นการลงนาม การลงชื่อควรเกิดขึ้นก่อนที่ URL จะเข้ารหัสสตริงข้อความค้นหา
เทคนิคนี้อาจเข้ากันได้กับสถาปัตยกรรมไร้สัญชาติมากขึ้นและยังสามารถนำไปใช้กับการจัดการเซสชันแบบเบา (ใช้เซสชันในหน่วยความจำแทนการคงอยู่ของ DB)
ตัวอย่างเช่นนี่คือตัวอย่าง URI ทั่วไปจากลิงก์ด้านบน:
GET /object?apiKey=Qwerty2010
ควรถ่ายทอดเช่นนี้:
GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789
สตริงที่กำลังเซ็นชื่อคือ/object?apikey=Qwerty2010×tamp=1261496500และลายเซ็นต์คือแฮช SHA256 ของสตริงนั้นโดยใช้คอมโพเนนต์ส่วนตัวของคีย์ API
การแคชข้อมูลฝั่งเซิร์ฟเวอร์สามารถใช้ได้เสมอ ตัวอย่างเช่นในกรอบงานของเราเราแคชการตอบสนองในระดับ SQL ไม่ใช่ระดับ URI ดังนั้นการเพิ่มพารามิเตอร์พิเศษนี้จะไม่ทำลายกลไกแคช
ดูบทความนี้สำหรับรายละเอียดบางอย่างเกี่ยวกับการรับรองความถูกต้อง RESTful ในไคลเอนต์ - เซิร์ฟเวอร์ ORM / SOA / MVC เฟรมเวิร์กของเราตาม JSON และ REST เนื่องจากเราอนุญาตการสื่อสารไม่เพียง แต่ผ่าน HTTP / 1.1 แต่ยังมีชื่อไปยัง pipes หรือข้อความ GDI (ในเครื่อง) เราจึงพยายามใช้รูปแบบการรับรองความถูกต้อง RESTful อย่างแท้จริงและไม่พึ่งพา HTTP เฉพาะ (เช่นส่วนหัวหรือคุกกี้)
หมายเหตุภายหลัง : การเพิ่มลายเซ็นใน URI นั้นถือเป็นแนวทางปฏิบัติที่ไม่ดี (เช่นในกรณีที่มันจะปรากฏในบันทึกของเซิร์ฟเวอร์ http) ดังนั้นจึงต้องมีการลดลงเช่น TTL ที่เหมาะสมเพื่อหลีกเลี่ยงการเล่นซ้ำ แต่ถ้าบันทึก http ของคุณถูกบุกรุกคุณจะมีปัญหาด้านความปลอดภัยที่ใหญ่ขึ้นอย่างแน่นอน
ในทางปฏิบัติการรับรองความถูกต้องของโทเค็น MAC สำหรับ OAuth 2.0อาจเป็นการปรับปรุงอย่างมากเกี่ยวกับรูปแบบปัจจุบัน "ที่ได้รับจากโทเค็น" แต่นี่ยังคงเป็นงานที่อยู่ระหว่างดำเนินการและเชื่อมโยงกับการส่ง HTTP
ข้อสรุป
สรุปได้ว่า REST ไม่เพียงใช้ HTTP เท่านั้นแม้ว่าในทางปฏิบัติจะใช้งานผ่าน HTTP เป็นส่วนใหญ่ REST สามารถใช้เลเยอร์การสื่อสารอื่น ๆ ดังนั้นการรับรองความถูกต้อง RESTful ไม่ได้เป็นเพียงคำพ้องความหมายของการรับรองความถูกต้อง HTTP สิ่งที่ Google ตอบ มันไม่ควรใช้กลไก HTTP เลย แต่จะต้องแยกจากเลเยอร์การสื่อสาร และถ้าคุณใช้การสื่อสาร HTTP ด้วยความคิดริเริ่ม Let's Encryptไม่มีเหตุผลที่จะไม่ใช้ HTTPS ที่เหมาะสมซึ่งเป็นสิ่งจำเป็นนอกเหนือไปจากรูปแบบการตรวจสอบความถูกต้องใด ๆ