คำถามติดแท็ก restful-authentication

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

745 rest  authentication  restful-authentication  rest-security 

การใช้เซสชันใน RESTful API เป็นการละเมิด RESTfulness หรือไม่ ฉันได้เห็นความคิดเห็นมากมายไปในทิศทางใดทิศทางหนึ่ง แต่ฉันไม่มั่นใจว่าช่วงการประชุมนั้นสงบเงียบ จากมุมมองของฉัน: ไม่รับรองความถูกต้องสำหรับ RESTfulness (ไม่เช่นนั้นจะมีการใช้งานเล็กน้อยในบริการ RESTful) การตรวจสอบความถูกต้องจะกระทำโดยการส่งโทเค็นการตรวจสอบความถูกต้องในคำขอโดยปกติจะเป็นส่วนหัว โทเค็นการรับรองความถูกต้องนี้จะต้องได้รับอย่างใดและอาจถูกเพิกถอนซึ่งในกรณีนี้จะต้องมีการต่ออายุ โทเค็นการตรวจสอบความถูกต้องจะต้องมีการตรวจสอบโดยเซิร์ฟเวอร์ (มิฉะนั้นจะไม่ได้รับการตรวจสอบ) ดังนั้นเซสชันจะละเมิดสิ่งนี้อย่างไร ฝั่งไคลเอ็นต์เซสชันจะรับรู้โดยใช้คุกกี้ คุกกี้เป็นเพียงส่วนหัว HTTP พิเศษ คุกกี้เซสชันสามารถรับและเพิกถอนได้ตลอดเวลา คุกกี้เซสชั่นสามารถมีชีวิตที่ไม่มีที่สิ้นสุดถ้าจำเป็น รหัสเซสชัน (โทเค็นการตรวจสอบความถูกต้อง) ได้รับการตรวจสอบความถูกต้องของฝั่งเซิร์ฟเวอร์ คุกกี้เซสชันนั้นเหมือนกับกลไกการตรวจสอบความถูกต้อง HTTP ส่วนหัวอื่น ๆ ยกเว้นว่าจะใช้Cookieส่วนหัวแทนAuthorizationส่วนหัวกรรมสิทธิ์อื่น ๆ หากไม่มีการเชื่อมต่อเซสชันกับฝั่งเซิร์ฟเวอร์ค่าคุกกี้เหตุใดจึงทำให้เกิดความแตกต่าง การใช้งานฝั่งเซิร์ฟเวอร์ไม่จำเป็นต้องเกี่ยวข้องกับไคลเอนต์ตราบใดที่เซิร์ฟเวอร์ทำงาน RESTful ดังนั้นคุกกี้ด้วยตัวเองไม่ควรทำ API RESTlessและเซสชันเป็นเพียงคุกกี้ให้กับลูกค้า สมมติฐานของฉันผิดหรือเปล่า? อะไรที่ทำให้เซสชันคุกกี้ไม่สงบ ?

491 session  rest  cookies  restful-authentication 

ฉันกำลังออกแบบบริการเว็บ RESTful ที่ผู้ใช้ต้องเข้าถึง แต่ยังรวมถึงบริการเว็บและแอปพลิเคชันอื่น ๆ ด้วย คำขอที่เข้ามาทั้งหมดจะต้องได้รับการตรวจสอบสิทธิ์ การสื่อสารทั้งหมดเกิดขึ้นผ่าน HTTPS การรับรองความถูกต้องของผู้ใช้จะทำงานตามโทเค็นการตรวจสอบความถูกต้องซึ่งได้มาจากการโพสต์ชื่อผู้ใช้และรหัสผ่าน (ผ่านการเชื่อมต่อ SSL) ไปยังทรัพยากร/ เซสชันที่ให้บริการโดยบริการ ในกรณีของไคลเอ็นต์บริการบนเว็บไม่มีผู้ใช้ปลายทางอยู่เบื้องหลังบริการไคลเอ็นต์ การร้องขอจะเริ่มต้นโดยงานตามกำหนดการเหตุการณ์หรือการทำงานของคอมพิวเตอร์อื่น ๆ รายชื่อบริการเชื่อมต่อเป็นที่รู้จักล่วงหน้า (แน่นอนฉันเดา) ฉันจะตรวจสอบสิทธิ์คำขอเหล่านี้ที่มาจากบริการอื่น ๆ (เว็บ) ได้อย่างไร? ฉันต้องการให้ขั้นตอนการตรวจสอบสิทธิ์ง่ายที่สุดในการนำไปใช้กับบริการเหล่านั้น แต่ไม่ต้องเสียค่าใช้จ่ายด้านความปลอดภัย อะไรคือมาตรฐานและแนวทางปฏิบัติที่ดีที่สุดสำหรับสถานการณ์เช่นนี้ ตัวเลือกที่ฉันคิดได้ (หรือได้รับการแนะนำให้ฉัน): ให้บริการไคลเอ็นต์หันมาใช้ชื่อผู้ใช้และรหัสผ่าน "ปลอม" และตรวจสอบสิทธิ์ในลักษณะเดียวกับผู้ใช้ ฉันไม่ชอบตัวเลือกนี้ - มันไม่ถูกต้อง กำหนดรหัสแอปพลิเคชันถาวรสำหรับบริการไคลเอ็นต์ซึ่งอาจเป็นรหัสแอปพลิเคชันด้วย เท่าที่ฉันเข้าใจนี่ก็เหมือนกับการมี username + password ด้วยรหัสและรหัสนี้ฉันสามารถตรวจสอบสิทธิ์แต่ละคำขอหรือสร้างโทเค็นการตรวจสอบสิทธิ์เพื่อพิสูจน์ตัวตนคำขอเพิ่มเติม ไม่ว่าจะด้วยวิธีใดฉันไม่ชอบตัวเลือกนี้เพราะใครก็ตามที่ได้รับรหัสแอปพลิเคชันและคีย์สามารถแอบอ้างเป็นลูกค้าได้ ฉันสามารถเพิ่มการตรวจสอบที่อยู่ IP ในตัวเลือกก่อนหน้าได้ ซึ่งจะทำให้คำขอปลอมทำได้ยากขึ้น ใบรับรองไคลเอ็นต์ ตั้งค่าผู้ออกใบรับรองของฉันเองสร้างใบรับรองหลักและสร้างใบรับรองไคลเอ็นต์สำหรับบริการไคลเอ็นต์ แม้ว่าจะมีปัญหาสองประการดังนี้ก) ฉันจะยังอนุญาตให้ผู้ใช้ตรวจสอบสิทธิ์โดยไม่มีใบรับรองได้อย่างไรและ b) …

117 web-services  authentication  rest  restful-authentication  client-certificates 

ฉันกำลังพัฒนา REST-API ซึ่ง HTTP-Basic ได้รับการป้องกันสำหรับสภาพแวดล้อมการพัฒนา เนื่องจากการตรวจสอบความถูกต้องจริงผ่านโทเค็นฉันยังคงพยายามหาวิธีส่งส่วนหัวการอนุญาตสองรายการ ฉันได้ลองสิ่งนี้แล้ว: curl -i http://dev.myapp.com/api/users \ -H "Authorization: Basic Ym9zY236Ym9zY28=" \ -H "Authorization: Bearer mytoken123" ตัวอย่างเช่นฉันสามารถปิดใช้งาน HTTP-Authentication สำหรับ IP ของฉันได้ แต่เนื่องจากโดยปกติแล้วฉันจะทำงานในสภาพแวดล้อมที่แตกต่างกันด้วยไดนามิก IPs นี่ไม่ใช่ทางออกที่ดี ฉันขาดอะไรไปหรือเปล่า?

115 rest  curl  basic-authentication  access-token  restful-authentication 

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

115 django  rest  restful-authentication  django-rest-framework 

คำถามนี้มีคำตอบอยู่แล้วที่นี่ : ที่เก็บ JWT ในเบราว์เซอร์? จะป้องกัน CSRF ได้อย่างไร? (5 คำตอบ) ปิดให้บริการใน4 เดือนที่ผ่านมา สำหรับวัตถุประสงค์ของการรักษาความปลอดภัย REST API ที่ใช้ JWT ตามวัสดุบางอย่าง (เช่นนี้คู่มือและคำถาม ) ที่ JWT สามารถเก็บไว้ในทั้งlocalStorageหรือคุกกี้ ตามความเข้าใจของฉัน: localStorageอยู่ภายใต้ XSS และโดยทั่วไปไม่แนะนำให้เก็บข้อมูลที่ละเอียดอ่อนใด ๆ ไว้ในนั้น ด้วยคุกกี้เราสามารถใช้แฟล็ก "httpOnly" ซึ่งช่วยลดความเสี่ยงของ XSS ได้ อย่างไรก็ตามหากเราต้องการอ่าน JWT จากคุกกี้ในแบ็กเอนด์เราจะต้องอยู่ภายใต้ CSRF ตามหลักฐานข้างต้น - จะเป็นการดีที่สุดหากเราเก็บ JWT ไว้ในคุกกี้ ในทุกการร้องขอไปยังเซิร์ฟเวอร์ JWT จะถูกอ่านจากคุกกี้และเพิ่มในส่วนหัวการอนุญาตโดยใช้โครงร่างของผู้ถือ จากนั้นเซิร์ฟเวอร์สามารถตรวจสอบ JWT ในส่วนหัวของคำขอได้ (ตรงข้ามกับการอ่านจากคุกกี้) …

105 security  cookies  local-storage  jwt  restful-authentication 

ฉันใช้ node กับ express + พังพอนและพยายามใช้ passport.js กับ api ที่สงบ ฉันยังคงได้รับข้อยกเว้นนี้หลังจากการตรวจสอบสิทธิ์สำเร็จ (ฉันเห็น URL เรียกกลับบนเบราว์เซอร์): /Users/naorye/dev/naorye/myproj/node_modules/mongoose/lib/utils.js:419 throw err; ^ Error: passport.initialize() middleware not in use at IncomingMessage.req.login.req.logIn (/Users/naorye/dev/naorye/myproj/node_modules/passport/lib/passport/http/request.js:30:30) at Context.module.exports.delegate.success (/Users/naorye/dev/naorye/myproj/node_modules/passport/lib/passport/middleware/authenticate.js:194:13) at Context.actions.success (/Users/naorye/dev/naorye/myproj/node_modules/passport/lib/passport/context/http/actions.js:21:25) at verified (/Users/naorye/dev/naorye/myproj/node_modules/passport-facebook/node_modules/passport-oauth/lib/passport-oauth/strategies/oauth2.js:133:18) at Promise.module.exports.passport.use.GitHubStrategy.clientID (/Users/naorye/dev/naorye/myproj/config/passport.js:91:24) at Promise.onResolve (/Users/naorye/dev/naorye/myproj/node_modules/mongoose/node_modules/mpromise/lib/promise.js:162:8) at Promise.EventEmitter.emit (events.js:96:17) at Promise.emit (/Users/naorye/dev/naorye/myproj/node_modules/mongoose/node_modules/mpromise/lib/promise.js:79:38) at Promise.fulfill …

104 node.js  express  mongoose  restful-authentication  passport.js 

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

103 rest  restful-authentication  graphql 

ฉันกำลังสร้าง RESTful API สำหรับหนึ่งในแอปพลิเคชันที่ฉันดูแลอยู่ ขณะนี้เรากำลังมองหาสิ่งต่างๆที่ต้องการการเข้าถึงและความปลอดภัยที่มีการควบคุมมากขึ้น ในขณะที่ศึกษาวิธีการรักษาความปลอดภัย API ฉันพบความคิดเห็นที่แตกต่างกันเล็กน้อยเกี่ยวกับรูปแบบที่จะใช้ ฉันเคยเห็นแหล่งข้อมูลบางแห่งบอกว่า HTTP-Auth เป็นวิธีที่จะไปในขณะที่คนอื่น ๆ ชอบคีย์ API และแม้แต่คนอื่น ๆ (รวมถึงคำถามที่ฉันพบที่นี่ใน SO) สาบานด้วย OAuth จากนั้นคนที่ชอบพูดว่าคีย์ API บอกว่า OAuth ออกแบบมาสำหรับแอปพลิเคชันที่เข้าถึงในนามของผู้ใช้ (ตามที่ฉันเข้าใจเช่นการลงชื่อเข้าใช้ไซต์ที่ไม่ใช่ Facebook โดยใช้บัญชี Facebook ของคุณ) และไม่ใช่สำหรับผู้ใช้ที่เข้าถึงทรัพยากรโดยตรงบนไซต์ที่พวกเขาสมัครไว้โดยเฉพาะ (เช่นไคลเอนต์ Twitter อย่างเป็นทางการที่เข้าถึงเซิร์ฟเวอร์ Twitter) อย่างไรก็ตามคำแนะนำสำหรับ OAuth ดูเหมือนจะเป็นความต้องการขั้นพื้นฐานที่สุดในการตรวจสอบสิทธิ์ คำถามของฉันคือ - สมมติว่ามันทำผ่าน HTTPS ทั้งหมดแล้วความแตกต่างในทางปฏิบัติระหว่างทั้งสามมีอะไรบ้าง? เมื่อใดที่ควรพิจารณาคนอื่น ๆ

101 security  api  restful-authentication 

ฉันอ่านข้อมูลเกี่ยวกับ REST และมีคำถามมากมายเกี่ยวกับ SO เกี่ยวกับเรื่องนี้รวมถึงเว็บไซต์และบล็อกอื่น ๆ อีกมากมาย แม้ว่าฉันไม่เคยเห็นคำถามเฉพาะนี้ถาม ... ด้วยเหตุผลบางอย่างฉันไม่สามารถคิดเกี่ยวกับแนวคิดนี้ได้ ... หากฉันกำลังสร้าง RESTful API และฉันต้องการรักษาความปลอดภัยหนึ่งในวิธีที่ฉันเห็นคือการใช้โทเค็นความปลอดภัย เมื่อฉันใช้ API อื่น ๆ มีโทเค็นและความลับที่ใช้ร่วมกัน ... สมเหตุสมผล สิ่งที่ฉันไม่เข้าใจคือการร้องขอไปยังการดำเนินการบริการส่วนที่เหลือกำลังดำเนินการผ่านทางจาวาสคริปต์ (XHR / Ajax) สิ่งที่จะป้องกันไม่ให้ใครบางคนสูดดมสิ่งที่เรียบง่ายเช่น FireBug (หรือ "ดูแหล่งที่มา" ในเบราว์เซอร์) และ คัดลอกคีย์ API แล้วแอบอ้างเป็นบุคคลนั้นโดยใช้คีย์และความลับ?

96 restful-authentication 

ฉันมีการดำเนินการรักษาความปลอดภัยบริการเว็บสงบ ฉันได้หาข้อมูลโดยใช้ Google แล้ว แต่ฉันติดขัด ตัวเลือก: TLS (HTTPS) + HTTP พื้นฐาน (pc1oad1etter) HTTP Digest OAuth สองทาง แนวทางที่อิงตามคุกกี้ ใบรับรองลูกค้า (Tom Ritter และที่นี่ ) คำขอที่ลงชื่อโดยใช้HMACและอายุการใช้งานที่ จำกัด มีตัวเลือกอื่น ๆ ที่เป็นไปได้ให้พิจารณาหรือไม่? ถ้า OAuth แล้วรุ่นอะไร มันสำคัญหรือไม่? จากสิ่งที่ผมได้อ่านเพื่อให้ห่างไกลOAuth 2.0พร้อมด้วยสัญญาณถือ (ที่ไม่มีลายเซ็น) ดูเหมือนว่าจะไม่ปลอดภัย ฉันได้พบบทความที่น่าสนใจอีกมากในการตรวจสอบส่วนที่เหลือตาม รักษาความปลอดภัย REST API ของคุณ ... วิธีที่ถูกต้อง

88 web-services  security  rest  oauth  restful-authentication