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

ฉันต้องการใช้บริการการพิสูจน์ตัวตนที่มีประสิทธิภาพมากขึ้นและjwtเป็นส่วนใหญ่ของสิ่งที่ฉันต้องการทำและฉันเข้าใจวิธีการเขียนรหัส แต่ฉันมีปัญหาเล็กน้อยในการทำความเข้าใจความแตกต่างระหว่างการสงวนissและการaudเรียกร้อง ฉันเข้าใจว่าเซิร์ฟเวอร์หนึ่งกำหนดเซิร์ฟเวอร์ที่ใช้งานโทเค็นและเซิร์ฟเวอร์หนึ่งอ้างถึงแอปพลิเคชันที่มีไว้สำหรับการใช้งาน แต่วิธีที่ฉันเข้าใจว่าผู้ชมและผู้ออกของฉันเป็นสิ่งเดียวกันmyserver.comคือการออกโทเค็นเพื่อให้ผู้ที่มาmyserver.comสามารถได้รับอนุญาตและรับรองความถูกต้อง ฉันเดาว่าฉันไม่เห็นความแตกต่างระหว่างการอ้างสิทธิ์ทั้งสองแม้ว่าฉันจะรู้ว่ามีอยู่ก็ตาม มีบทความที่ดีเขียนอยู่ที่msdn ในการอ้างสิทธิ์ที่สงวนไว้ทั้งหมดและนั่นคือสิ่งที่ฉันสับสนมากที่สุดเพราะพวกเขามี บริษัท ผู้ออกหลักทรัพย์และผู้ชมต่างกันโดยสิ้นเชิง

13 security  authentication  authorization  jwt 

ฉันต้องการแนวคิดในการปกป้องคีย์ API ส่วนตัวในแอปพลิเคชันโดยเฉพาะในแอปพลิเคชัน ac # .NET ประการแรกฉันเข้าใจว่าในทางทฤษฎีมันเป็นไปไม่ได้ที่จะซ่อนอะไรในซอร์สโค้ดดังนั้นฉันจึงคิดความคิดอื่น แต่ฉันไม่แน่ใจว่ามันเป็นไปได้จริง อย่างไรก็ตามมีความเป็นไปได้ไหมที่จะสื่อสารกับเว็บเซิร์ฟเวอร์เพื่อตรวจสอบรหัสส่วนตัวจากนั้นพูดคุยกลับไปที่แอปพลิเคชันเพื่อยืนยันว่าเป็นการจับมือที่ถูกกฎหมายหรือไม่ ฉันมีสองปุ่มที่จะทำงานกับ: กุญแจสาธารณะ (ตามชื่อที่แนะนำมันไม่จำเป็นต้องได้รับการดูแลเช่นเดียวกับความเป็นส่วนตัว) และกุญแจส่วนตัวที่ต้องได้รับการรักษาความปลอดภัยจากผู้อื่น ความคิดเห็นใด ๆ เกี่ยวกับวิธีที่ฉันสามารถทำได้จะได้รับการชื่นชมอย่างมาก

12 c#  api  authentication 

มันเกินความเป็นวิศวกรรมหรือไม่ถ้าฉันเพิ่มการป้องกันการกระทำผิดโดยเจตนาของผู้ใช้ (เพื่อกล่าวอย่างอ่อนโยน) หากความเสียหายที่ผู้ใช้สามารถได้รับนั้นไม่เกี่ยวข้องกับรหัสของฉันหรือไม่? เพื่อชี้แจงฉันกำลังเปิดเผยบริการ JSON RESTful แบบนี้: GET /items - to retrieve list of user's items PUT /items/id - to modify an item POST /items - to add a new item บริการนี้ไม่ได้มีไว้สำหรับใช้กับเบราว์เซอร์ แต่มาจากแอปพลิเคชันบุคคลที่สามซึ่งควบคุมโดยผู้ใช้ (เช่นแอพโทรศัพท์แอพเดสก์ท็อป ฯลฯ ) นอกจากนี้บริการควรไม่มีสถานะ (เช่นเซสชันน้อย) การรับรองความถูกต้องจะทำกับการตรวจสอบขั้นพื้นฐานผ่าน SSL ฉันกำลังพูดถึงพฤติกรรม "อันตราย" ที่เป็นไปได้เช่นนี้: ผู้ใช้ป้อน URL ของ GET ในเบราว์เซอร์ (ไม่มีเหตุผลยกเว้น ... …

12 rest  authentication 

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

12 web-applications  security  browser  authentication 

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

12 authentication  authorization  session  cookies  jwt 

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

11 web-services  rest  authentication  ssl  https 

ฉันทำงานกับ API สำหรับบริการ REST ที่ฉันจะผลิตและบริโภค ฉันใช้เวลาไม่กี่วันที่ผ่านมาพยายามหาวิธีจัดการกับการรับรองความถูกต้องอย่างดีและคิดว่าในที่สุดฉันก็คิดอะไรบางอย่าง ฉันกำลังทำสิ่งนี้ตามข้อเท็จจริงต่อไปนี้เกี่ยวกับสแต็กแอปพลิเคชัน: ไคลเอ็นต์ & เซิร์ฟเวอร์อยู่ใน. NET4 (ส่วนลูกค้าในโปรไฟล์ลูกค้า) เซิร์ฟเวอร์แสดงโดยใช้ WCF REST ฉันไม่ต้องการเก็บชื่อผู้ใช้และรหัสผ่านไว้ในหน่วยความจำในแอพ จาก 3 ฉันต้องการใช้รูปแบบการตรวจสอบความถูกต้องของโทเค็นเพื่อให้หลังจากที่ข้อมูลรับรองถูกตรวจสอบโดยเซิร์ฟเวอร์ลูกค้าจะได้รับโทเค็นกลับมาใช้ตลอดช่วงเวลาที่เหลือของแอป (สิ่งนี้จะทำให้ฉันทำสิ่งอื่น ๆ เช่น หมดเวลาผู้ใช้สามารถย้ายผู้ใช้อย่างต่อเนื่องระหว่างเว็บและเดสก์ท็อปเวอร์ชัน ฯลฯ ) หลังจากหาวิธีการโทรซ้ำและป้องกันการรบกวนฉันได้รับสิ่งต่อไปนี้: ก่อนที่ลูกค้าจะพยายามพิสูจน์ตัวตนมันจะสร้างคู่คีย์ Diffie-Hellman โดยใช้ECDiffieHellmanCngคลาส มันจะส่งส่วนสาธารณะของคู่กุญแจผ่านสายพร้อมกับชื่อผู้ใช้และรหัสผ่าน (ผ่าน HTTPS แน่นอน) เซิร์ฟเวอร์รับรองความถูกต้องของชื่อผู้ใช้ / รหัสผ่านหากทำสำเร็จจะทำสิ่งต่อไปนี้: สร้างโทเค็นเซสชันที่ไม่ซ้ำกัน สร้างคู่คีย์ DH ของตนเองและคำนวณความลับที่ใช้ร่วมกันจากพับลิกคีย์ที่ลูกค้าให้ไว้ บันทึกโทเค็นเซสชันความลับที่ใช้ร่วมกันผู้ใช้และเวลา "การกระทำล่าสุด" (ใช้สำหรับหน้าต่างหมดอายุการหมุน) ในฐานข้อมูล ส่งคืนโทเค็นเซสชันคีย์สาธารณะ DH และข้อความยืนยันความสำเร็จในการตรวจสอบความถูกต้อง ไคลเอ็นต์ใช้คีย์ DH จากการตอบสนองคำนวณความลับที่ใช้ร่วมกันและเก็บทั้งโทเค็นและความลับในหน่วยความจำ …

11 algorithms  rest  authentication 

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

10 rest  authentication  headers 

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

9 security  authentication  jwt 

ข้อมูลจำเพาะ JWT อธิบายถึงน้ำหนักบรรทุกและวิธีการส่ง แต่ปล่อยให้โปรโตคอลการตรวจสอบความถูกต้องเปิดซึ่งช่วยให้มีความยืดหยุ่น แต่น่าเสียดายที่ความยืดหยุ่นสามารถนำไปสู่การออกแบบและออกแบบที่ผิด ฉันกำลังมองหาแนวคิดที่ดีและผ่านการทดสอบการใช้งานองค์กรสำหรับการรับรองความถูกต้อง JWT ซึ่งฉันสามารถใช้หรือปรับเปลี่ยนได้ แต่ฉันล้มเหลวในการค้นหาสิ่งที่สมบูรณ์ สิ่งที่ฉันคิดคือ เมื่อไม่พบส่วนหัวการให้สิทธิ์หรือโทเค็น JWT ไม่ถูกต้องหรือหมดอายุให้ส่ง HTTP 401 เพื่อตรวจสอบสิทธิ์ใช้ / ล็อกอินช่อง REST ส่งชื่อผู้ใช้และรหัสผ่านเป็นวัตถุ JSON เพื่อให้โทเค็นยังมีชีวิตอยู่ใช้ / keepalive REST ช่องเรียกมันทุก ๆ N (5) นาทีรับโทเค็น JWT ใหม่และแทนที่หนึ่งที่มีอยู่หลังจากแต่ละสาย (โทเค็นหมดอายุหลังจาก M (15) นาที) อย่างไรก็ตามสิ่งที่รบกวนฉันคือความจำเป็นของช่องทางนั้น / keepalive ในทางกลับกันมันบังคับให้ฉันเพื่อป้องกันไม่ให้การรับรองความถูกต้องหมดอายุแม้ว่าผู้ใช้จะไม่อยู่ (การตัดสินใจถ้าเรายังต้องการ keepalive ยังไม่พบ) และแน่นอนการโทรเหล่านั้นเป็นพิเศษและมีความซับซ้อนเป็นพิเศษในโปรโตคอล สิ่งที่น่าสนใจก็คือเซิร์ฟเวอร์นั้นจะขยายโทเค็นโดยอัตโนมัติ ในสภาพแวดล้อมแบบเซสชันนั้นเกิดขึ้นโดยการรีเซ็ตเวลาประทับที่นี่อย่างไรก็ตามเซิร์ฟเวอร์จะต้องส่งโทเค็นใหม่อาจไม่ได้แต่ละครั้ง แต่เมื่อโทเค็นจะหมดอายุใน R (พูด 10 …

9 rest  authentication  architectural-patterns 

ฉันกำลังทำงานกับเว็บแอปที่ต้องจัดการกับแรงกระตุ้นที่มีขนาดใหญ่มากของผู้ใช้งานพร้อมกันซึ่งต้องได้รับอนุญาตเพื่อขอเนื้อหาที่เหมือนกัน ในสถานะปัจจุบันมันหมดอำนาจโดยสิ้นเชิงแม้แต่กับ 32-core AWS instance (โปรดทราบว่าเราใช้ Nginx เป็น reverse proxy) การตอบสนองไม่สามารถแคชได้อย่างง่ายดายเนื่องจากในกรณีที่เลวร้ายที่สุดเราต้องตรวจสอบว่าผู้ใช้รับรองความถูกต้องโดยการถอดรหัส JWT หรือไม่ สิ่งนี้ทำให้เราต้องยิง Laravel 4 ซึ่งส่วนใหญ่เห็นด้วยช้าแม้เปิดใช้งาน PHP-FPM และ OpCache นี่คือสาเหตุส่วนใหญ่เนื่องมาจากขั้นตอนการบูตที่แข็งแกร่ง บางคนอาจถามคำถาม "ทำไมคุณถึงใช้ PHP และ Laravel ตั้งแต่แรกถ้าคุณรู้ว่านี่จะเป็นปัญหา?" - แต่มันสายเกินไปแล้วที่จะกลับไปตัดสินใจเรื่องนั้น! ทางออกที่เป็นไปได้ ทางออกหนึ่งที่ถูกนำมาใช้คือการแยกโมดูล Auth จาก Laravel ไปยังโมดูลภายนอกที่มีน้ำหนักเบา (เขียนในสิ่งที่เร็วกว่า C) ซึ่งมีหน้าที่รับผิดชอบในการถอดรหัส JWT และตัดสินใจว่าผู้ใช้รับรองความถูกต้องหรือไม่ การไหลของการร้องขอจะเป็น: ตรวจสอบว่าแคชโดนหรือไม่ (ถ้าไม่ผ่านไปยัง PHP ตามปกติ) ถอดรหัสโทเค็น ตรวจสอบว่ามันถูกต้อง หากถูกต้องให้บริการจากแคช หากไม่ถูกต้องให้บอก Nginx …

9 authentication  caching  nginx