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

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

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

ตอนนี้เรามาเปลี่ยนมาใช้การรับรองความถูกต้องตามการอ้างสิทธิ์ องค์ประกอบหลักคือการเรียกร้องและการรวบรวมการเรียกร้องสามารถใช้เป็นที่เก็บ

• คุกกี้ (ตามที่กล่าวไว้ข้างต้น)
• โทเค็น (JWT เป็นตัวอย่าง)

จากอีกด้านหนึ่งเมื่อเราพูดถึงโทเค็นมันอาจมีข้อมูลใด ๆ ... รหัสเซสชันเช่น ...

แล้วฉันจะพลาดอะไรไป? ทำไมคนไม่กำหนดสิ่งที่ชอบCookie-Session-basedหรือToken-Claims-basedรับรองความถูกต้องเมื่อพูดคุยเกี่ยวกับประเภทการรับรองความถูกต้อง?

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

ลูกค้าส่งข้อมูลอะไรเมื่อตรวจสอบสิทธิ์

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

ไคลเอ็นต์ส่งข้อมูลการตรวจสอบสิทธิ์อย่างไร

• คุ้กกี้ เบราว์เซอร์จะส่งคุกกี้โดยอัตโนมัติเมื่อมีคำขอแต่ละครั้งหลังจากที่ตั้งค่าคุกกี้แล้ว คุกกี้มีความเสี่ยงต่อ XSRF
• ส่วนหัวอื่น ๆ โดยทั่วไปส่วนหัวการอนุญาตใช้สำหรับสิ่งนี้ ส่วนหัวเหล่านี้จะไม่ส่งโดยเบราว์เซอร์โดยอัตโนมัติ แต่จะต้องมีการตั้งค่าโดยลูกค้า สิ่งนี้มีความเสี่ยงต่อ XSS
• คำขอ Url ข้อมูลการรับรองความถูกต้องรวมอยู่ใน URL สิ่งนี้ไม่ได้ใช้กันทั่วไป

รูปแบบของข้อมูลการรับรองความถูกต้องคืออะไร?

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

โบนัส: ลูกค้าจะเก็บข้อมูลในพื้นที่ได้อย่างไร

• คุ้กกี้ เป็นกรณีนี้เมื่อใช้คุกกี้เพื่อส่งข้อมูล แต่คุกกี้ยังสามารถใช้เป็นเพียงกลไกการจัดเก็บข้อมูลฝั่งไคลเอ็นต์ สิ่งนี้ต้องการให้คุกกี้อ่านได้จากสคริปต์เพื่อให้มีประโยชน์ ตัวอย่างเช่นลูกค้าสามารถอ่านคุกกี้ด้วย JavaScript และส่งข้อมูลด้วย Authorization-Header
• เก็บข้อมูลท้องถิ่น นี่เป็นวิธีการเดียวที่เป็นไปได้หากคุกกี้ไม่พร้อมใช้งาน ต้องการการจัดการด้วย JavaScript

ผู้คนหมายถึงอะไรเมื่อพวกเขาพูดว่า ...

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

เพียงแค่ใส่

1. การรับรองความถูกต้องตามคุกกี้

   • เว็บไคลเอ็นต์ (เช่นเว็บเบราว์เซอร์) เก็บคุกกี้ที่ส่งจากเว็บเซิร์ฟเวอร์หลังจากตรวจสอบสิทธิ์สำเร็จ
   • คุกกี้มีข้อมูลเกี่ยวกับผู้ใช้ไคลเอนต์การประทับเวลา AuthN และข้อมูลที่เป็นประโยชน์อื่น ๆ ที่มี id ที่ไม่ซ้ำกันเพื่อกำหนดคุกกี้
   • โดยทั่วไปคุกกี้จะถูกเข้ารหัสโดยเว็บเซิร์ฟเวอร์พร้อมชุดแอตทริบิวต์ของโดเมน (เช่น:) google.comและส่งไปยังเว็บไคลเอ็นต์
   • เมื่อใดก็ตามที่เว็บไคลเอนต์ต้องการเข้าถึงทรัพยากรโดเมน (เช่น:) mail.google.comมันจะส่งคุกกี้ทั้งหมดตามโดเมน (เช่น:) google.comไปยังเว็บเซิร์ฟเวอร์ซึ่งตรวจสอบ / ตรวจสอบและให้สิทธิ์ / ปฏิเสธการเข้าถึงตามรัฐและเวลาของ คุกกี้

2. การตรวจสอบตามเซสชัน

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

3. การรับรองความถูกต้องโดยใช้โทเค็น

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

4. การรับรองความถูกต้องตามการอ้างสิทธิ์

   • นี่เหมือนกับการรับรองความถูกต้องโดยใช้โทเค็นเท่านั้นที่จะเพิ่มข้อมูลเพิ่มเติมบางอย่างลงในโทเค็นเกี่ยวกับลูกค้าและ / หรือผู้ใช้ที่เกี่ยวข้องกับลูกค้า
   • ข้อมูลเหล่านี้เกี่ยวข้องกับการอนุญาตซึ่งพูดถึงสิ่งที่ลูกค้าต้องทำภายในทรัพยากร (เช่น: mail.read, mail.delete, calendar.read)