อะไรคือความแตกต่างที่สำคัญระหว่างการตรวจสอบ JWT และ OAuth?

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

ฉันใช้ JWT เป็น XSRF-TOKEN ของฉันเพื่อป้องกัน XSRF แต่ฉันถูกขอให้แยกพวกเขาหรือไม่ ฉันควรแยกพวกเขาออกจากกันหรือไม่? ความช่วยเหลือใด ๆ ที่นี่จะได้รับการชื่นชมและอาจนำไปสู่ชุดแนวทางสำหรับชุมชน

TL; DR หากคุณมีสถานการณ์ที่ง่ายมากเช่นแอปพลิเคชันไคลเอนต์เดียว API เดียวก็อาจไม่ได้ผลในการใช้งาน OAuth 2.0 ในทางกลับกันไคลเอนต์จำนวนมากที่แตกต่างกัน ฯลฯ ) จากนั้นการผสานกับกฎ OAuth 2.0 อาจทำให้จัดการได้ง่ายกว่าการพยายามพลิกระบบของคุณเอง

ตามที่ระบุไว้ในคำตอบอื่น JWT ( Learn JSON Web Tokens ) เป็นเพียงรูปแบบโทเค็นมันกำหนดกลไกขนาดกะทัดรัดและมีอยู่ในตัวเองสำหรับการส่งข้อมูลระหว่างบุคคลในวิธีที่สามารถตรวจสอบและเชื่อถือได้เพราะมีการเซ็นชื่อแบบดิจิทัล นอกจากนี้กฎการเข้ารหัสของ JWT ยังทำให้โทเค็นเหล่านี้ใช้งานได้ง่ายในบริบทของ HTTP

การมีอยู่ในตัวเอง (โทเค็นจริงมีข้อมูลเกี่ยวกับเรื่องที่กำหนด) พวกเขายังเป็นตัวเลือกที่ดีสำหรับการใช้กลไกการพิสูจน์ตัวตนแบบไร้รัฐ (aka Look mum, no session! ) เมื่อไปตามเส้นทางนี้และสิ่งเดียวที่ปาร์ตี้ต้องแสดงเพื่อให้ได้รับอนุญาตให้เข้าถึงทรัพยากรที่มีการป้องกันคือโทเค็นเองโทเค็นที่สงสัยสามารถเรียกได้ว่าโทเค็นผู้ถือ

ในทางปฏิบัติสิ่งที่คุณทำอยู่แล้วสามารถจัดประเภทตามโทเค็นผู้ถือ อย่างไรก็ตามโปรดพิจารณาว่าคุณไม่ได้ใช้โทเค็นผู้ถือตามที่ระบุไว้ในข้อกำหนดที่เกี่ยวข้องของ OAuth 2.0 (ดูRFC 6750 ) นั่นหมายความว่าต้องอาศัยAuthorizationส่วนหัว HTTP และใช้Bearerรูปแบบการตรวจสอบสิทธิ์

เกี่ยวกับการใช้ JWT เพื่อป้องกัน CSRF โดยไม่ทราบรายละเอียดที่แน่นอนมันเป็นการยากที่จะยืนยันความถูกต้องของการปฏิบัตินั้น แต่ตามจริงแล้วดูเหมือนจะไม่ถูกต้องและ / หรือคุ้มค่า บทความต่อไปนี้ ( คุกกี้ vs โทเค็น: คู่มือสรุป ) อาจเป็นประโยชน์สำหรับการอ่านในเรื่องนี้โดยเฉพาะอย่างยิ่งส่วนการป้องกัน XSS และ XSRF

หนึ่งชิ้นสุดท้ายของคำแนะนำถึงแม้คุณจะไม่จำเป็นต้องไป OAuth เต็ม 2.0 ผมจะขอแนะนำในการส่งผ่านการเข้าถึงของคุณโทเค็นภายในAuthorizationหัวแทนจะมีส่วนหัวที่กำหนดเอง หากพวกเขาเป็นโทเค็นผู้ถือจริงๆทำตามกฎของ RFC 6750 ถ้าไม่คุณสามารถสร้างรูปแบบการรับรองความถูกต้องที่กำหนดเองและยังคงใช้ส่วนหัวนั้น

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

(ที่มา: RFC 6819, ส่วน 5.4.1 )

OAuth 2.0 กำหนดโปรโตคอลเช่นระบุวิธีโอนโทเค็น JWT กำหนดรูปแบบโทเค็น

OAuth 2.0 และ "การรับรองความถูกต้อง JWT" มีลักษณะที่คล้ายกันเมื่อมาถึงสเตจ (2nd) ที่ไคลเอ็นต์แสดงโทเค็นไปยังเซิร์ฟเวอร์ทรัพยากร: โทเค็นจะถูกส่งผ่านในส่วนหัว

แต่ "การรับรองความถูกต้อง JWT" ไม่ใช่มาตรฐานและไม่ได้ระบุวิธีที่ลูกค้าได้รับโทเค็นตั้งแต่แรก (ระยะที่ 1) นั่นคือที่มาของความซับซ้อนของ OAuth ที่รับรู้: มันยังกำหนดวิธีการต่าง ๆ ที่ลูกค้าสามารถรับโทเค็นการเข้าถึงจากสิ่งที่เรียกว่าเซิร์ฟเวอร์การอนุญาต

ดังนั้นความแตกต่างที่แท้จริงคือ JWT เป็นเพียงรูปแบบโทเค็น OAuth 2.0 เป็นโปรโตคอล (ซึ่งอาจใช้ JWT เป็นรูปแบบโทเค็น)

อันดับแรกเราต้องแยกความแตกต่าง JWT และ OAuth โดยทั่วไป JWT เป็นรูปแบบโทเค็น OAuth เป็นโปรโตคอลการอนุญาตที่สามารถใช้ JWT เป็นโทเค็นได้ OAuth ใช้ที่เก็บข้อมูลฝั่งเซิร์ฟเวอร์และฝั่งไคลเอ็นต์ หากคุณต้องการออกจากระบบจริงคุณต้องไปกับ OAuth2 การตรวจสอบด้วยโทเค็น JWT ไม่สามารถออกจากระบบได้จริง เพราะคุณไม่มีเซิร์ฟเวอร์การตรวจสอบความถูกต้องที่ติดตามโทเค็น หากคุณต้องการให้ API แก่ลูกค้าบุคคลที่สามคุณต้องใช้ OAuth2 ด้วย OAuth2 ยืดหยุ่นได้มาก การติดตั้ง JWT นั้นง่ายมากและใช้เวลาไม่นาน หากแอปพลิเคชันของคุณต้องการความยืดหยุ่นเช่นนี้คุณควรไปกับ OAuth2 แต่ถ้าคุณไม่ต้องการสถานการณ์แบบใช้กรณีนี้การใช้ OAuth2 นั้นเป็นการเสียเวลาเปล่า

โทเค็น XSRF จะถูกส่งไปยังไคลเอนต์ในทุก ๆ หัวข้อการตอบสนอง ไม่สำคัญว่าจะส่งโทเค็น CSRF ในโทเค็น JWT หรือไม่เพราะโทเค็น CSRF นั้นปลอดภัยด้วยตัวเอง ดังนั้นการส่งโทเค็น CSRF ใน JWT จึงไม่จำเป็น

JWT (JSON Web Tokens) - เป็นเพียงรูปแบบโทเค็น โทเค็น JWT เป็นโครงสร้างข้อมูลที่เข้ารหัสของ JSON ประกอบด้วยข้อมูลเกี่ยวกับผู้ออกหัวเรื่อง (การอ้างสิทธิ์) เวลาหมดอายุเป็นต้นซึ่งมีการเซ็นชื่อเพื่อพิสูจน์การปลอมแปลงและความถูกต้องและสามารถเข้ารหัสเพื่อปกป้องข้อมูลโทเค็นโดยใช้วิธีสมมาตรหรือไม่สมมาตร JWT นั้นง่ายกว่า SAML 1.1 / 2.0 และรองรับโดยอุปกรณ์ทั้งหมดและมันมีประสิทธิภาพมากกว่า SWT (Simple Web Token)

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

OpenID Connect - OpenID Connect จะสร้างจากด้านบนของ OAuth2 และเพิ่มการรับรองความถูกต้อง OpenID Connect เพิ่มข้อ จำกัด บางอย่างให้กับ OAuth2 เช่น UserInfo Endpoint, ID Token, การค้นพบและการลงทะเบียนแบบไดนามิกของผู้ให้บริการ OpenID Connect และการจัดการเซสชัน JWT เป็นรูปแบบบังคับสำหรับโทเค็น

การป้องกัน CSRF - คุณไม่จำเป็นต้องใช้การป้องกัน CSRF หากคุณไม่ได้เก็บโทเค็นในคุกกี้ของเบราว์เซอร์

คุณสามารถอ่านรายละเอียดเพิ่มเติมได้ที่นี่http://proficientblog.com/microservices-security/

ดูเหมือนว่าทุกคนที่ตอบที่นี่พลาดจุดที่สงสัยของ OAUTH

จากวิกิพีเดีย

OAuth เป็นมาตรฐานแบบเปิดสำหรับการมอบสิทธิ์การเข้าถึงซึ่งโดยทั่วไปใช้เป็นวิธีสำหรับผู้ใช้อินเทอร์เน็ตในการอนุญาตให้เว็บไซต์หรือแอปพลิเคชันเข้าถึงข้อมูลของพวกเขาบนเว็บไซต์อื่น ๆ แต่ไม่ได้ให้รหัสผ่านแก่พวกเขา [1] กลไกนี้ใช้โดย บริษัท เช่น Google, Facebook, Microsoft และ Twitter เพื่ออนุญาตให้ผู้ใช้แบ่งปันข้อมูลเกี่ยวกับบัญชีของตนกับแอปพลิเคชันหรือเว็บไซต์ของบุคคลที่สาม

จุดสำคัญที่นี่คือ access delegationจุดสำคัญที่นี่คือทำไมทุกคนจะสร้าง OAUTH เมื่อมีการพิสูจน์ตัวตนโดยใช้ ID / pwd สนับสนุนโดยรับรองความถูกต้องหลาย ๆ อย่างเช่น OTPs และสามารถรักษาความปลอดภัยโดย JWTs ซึ่งใช้เพื่อรักษาความปลอดภัยการเข้าถึงเส้นทาง (เช่นขอบเขตใน OAUTH) และตั้งค่าการหมดอายุ เข้าไป

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

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

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

ค้นหาความแตกต่างที่สำคัญระหว่าง JWT และ OAuth

1. OAuth 2.0 กำหนดโปรโตคอล & JWT กำหนดรูปแบบโทเค็น

2. OAuth สามารถใช้ JWT เป็นรูปแบบโทเค็นหรือโทเค็นการเข้าถึงซึ่งเป็นโทเค็นผู้ถือ

3. การเชื่อมต่อ OpenID ส่วนใหญ่ใช้ JWT เป็นรูปแบบโทเค็น

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

โดยที่ OAuth2 เป็นเฟรมเวิร์กการอนุญาตซึ่งมีโพรซีเดอร์และการตั้งค่าทั่วไปที่กำหนดโดยเฟรมเวิร์ก JWT สามารถใช้เป็นกลไกภายใน OAuth2

คุณสามารถอ่านเพิ่มเติมได้ที่นี่

OAuth หรือ JWT ใช้ตัวไหนและทำไม?

คำถามนี้เป็นคำถามทั่วไป แต่ก็ไม่สมเหตุสมผลนัก JWT เป็น Token ประเภทหนึ่งและ OAuth เป็น Framework ที่อธิบายวิธีแจกจ่ายโทเค็น

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

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

JWT เป็นโทเค็นบางประเภทและ JWT สามารถใช้เป็นโทเค็น OAuth Bearer ได้อย่างแน่นอน ในความเป็นจริงนี่คือการปฏิบัติที่พบบ่อยที่สุด ด้วยเหตุนี้ "JWT vs OAuth" จึงเป็นการเปรียบเทียบแอปเปิ้ลกับแอปเปิ้ลเกวียน

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

ในทางตรงกันข้าม JWT ไม่ทึบแสง JWT ไม่ใช่ "ตัวชี้" หรืออ้างอิงถึงข้อมูล มันมีข้อมูลเฉพาะจำนวนมากที่สามารถแยกและตีความโดยฝ่ายใดก็ตามที่มีโทเค็น เนื่องจาก JWT มีข้อมูลจริง JWT จึงมีขนาดใหญ่ 300 ไบต์, 500 ไบต์หรือมากกว่านั้นขึ้นอยู่กับการอ้างสิทธิ์ที่อยู่ในนั้นและอัลกอริทึมที่ใช้ในการเซ็นชื่อ เมื่อผู้คนพูดว่า "JWT ตรวจสอบตัวเอง" สิ่งที่พวกเขาหมายถึงคือเจ้าของ JWT คนใดก็ได้ที่สามารถเปิดตรวจสอบความถูกต้องแล้วทำการตัดสินใจอนุญาตตามการอ้างสิทธิ์ที่ปรากฏในนั้น การตรวจสอบ JWT หมายถึง: การตรวจสอบโครงสร้างถอดรหัสการเข้ารหัส base64 การตรวจสอบคีย์นั้นถูกต้องตรวจสอบลายเซ็นจากนั้นตรวจสอบการอ้างสิทธิ์ที่จำเป็นอยู่ในโทเค็นตรวจสอบการหมดอายุ มันไม่ใช่เรื่องง่าย ค่อนข้างเป็นกระบวนการที่มีหลายขั้นตอน แต่แน่นอนว่ามีไลบรารีจำนวนมากในภาษาการเขียนโปรแกรมต่าง ๆ ที่สอดคล้องกับสิ่งนี้และแน่นอนว่ามีนโยบาย VerifyJWT ที่ช่วยคุณทำสิ่งนี้ภายในพร็อกซี Apigee Edge API ประเด็นก็คือผู้ถือหรือผู้รับสามารถตรวจสอบโทเค็นได้ ด้วยเหตุนี้เราจึงบอกว่า JWT รองรับ "Federation" - ทุกคนสามารถสร้างโทเค็นได้และทุกคนสามารถอ่านและตรวจสอบโทเค็นได้

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

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

OAuth2 ในทางกลับกันไม่ใช่โปรโตคอล แต่เป็นกรอบการให้สิทธิ์ที่ได้รับมอบหมาย คิดแนวทางที่มีรายละเอียดมาก ๆ เพื่อให้ผู้ใช้และแอปพลิเคชั่นอนุญาตการอนุญาตเฉพาะแอปพลิเคชันอื่น ๆ ในการตั้งค่าส่วนตัวและสาธารณะ OpenID Connect ที่อยู่ด้านบนของ OAUTH2 ให้การรับรองความถูกต้องและการอนุญาตมีรายละเอียดว่าบทบาทที่แตกต่างกันหลายอย่างผู้ใช้ในระบบของคุณแอพฝั่งเซิร์ฟเวอร์เช่น API และไคลเอนต์เช่นเว็บไซต์หรือแอพมือถือทั่วไป

หมายเหตุ oauth2 สามารถทำงานกับ jwt, การปรับใช้ที่ยืดหยุ่น, ขยายได้ไปยังแอ็พพลิเคชันที่ต่างกัน