ฉันกำลังดำเนินการติดตั้ง OAuth 2.0 JWT access_token ในเซิร์ฟเวอร์การตรวจสอบสิทธิ์ของฉัน แต่ฉันไม่ชัดเจนว่าความแตกต่างระหว่างการaudอ้างสิทธิ์JWT และclient_idค่าส่วนหัว HTTP คืออะไร พวกเดียวกันหรือเปล่า? ถ้าไม่คุณสามารถอธิบายความแตกต่างระหว่างทั้งสองได้หรือไม่?
ความสงสัยของฉันคือaudควรอ้างถึงเซิร์ฟเวอร์ทรัพยากรและclient_idควรอ้างถึงแอปพลิเคชันไคลเอนต์ตัวใดตัวหนึ่งที่เซิร์ฟเวอร์รับรองความถูกต้อง (เช่นเว็บแอปหรือแอป iOS)
ในกรณีปัจจุบันเซิร์ฟเวอร์ทรัพยากรของฉันยังเป็นไคลเอนต์เว็บแอปของฉัน
คำตอบ:
ปรากฎว่าความสงสัยของฉันถูกต้อง การaudอ้างสิทธิ์ของผู้ชมใน JWT หมายถึงการอ้างถึงเซิร์ฟเวอร์ทรัพยากรที่ควรยอมรับโทเค็น
ตามที่โพสต์นี้ใส่ไว้:
ผู้ชมของโทเค็นคือผู้รับที่ต้องการของโทเค็น
ค่าผู้ชมเป็นสตริง -
https://contoso.comโดยทั่วไปที่อยู่ฐานของทรัพยากรที่มีการเข้าถึงเช่น
client_idใน OAuth หมายถึงโปรแกรมไคลเอนต์ที่จะร้องขอทรัพยากรจากทรัพยากรของเซิร์ฟเวอร์
แอปไคลเอ็นต์ (เช่นแอป iOS ของคุณ) จะขอ JWT จากเซิร์ฟเวอร์การตรวจสอบสิทธิ์ของคุณ ในการดำเนินการนี้จะส่งผ่านclient_idและclient_secretไปพร้อมกับข้อมูลรับรองผู้ใช้ที่อาจจำเป็น การอนุญาตเซิร์ฟเวอร์ตรวจสอบลูกค้าใช้client_idและclient_secretและผลตอบแทน JWT
JWT จะมีการaudอ้างสิทธิ์ที่ระบุว่าเซิร์ฟเวอร์ทรัพยากรใดที่ JWT ใช้ได้ หากaudมีwww.myfunwebapp.comแต่แอปไคลเอ็นต์พยายามใช้ JWT เปิดwww.supersecretwebapp.comการเข้าถึงจะถูกปฏิเสธเนื่องจากเซิร์ฟเวอร์ทรัพยากรนั้นจะเห็นว่า JWT ไม่ได้มีไว้สำหรับใช้งาน
audอ้างสิทธิ์JWT (ผู้ชม)ตามRFC 7519 :
การอ้างสิทธิ์ "aud" (ผู้ชม) ระบุผู้รับที่ JWT มีไว้สำหรับ หลักแต่ละคนมีวัตถุประสงค์เพื่อประมวลผล JWT ต้องระบุตัวเองด้วยคุณค่าในการอ้างสิทธิ์ของผู้ชม หากการประมวลผลหลักของการอ้างสิทธิ์ไม่ได้ระบุตัวตนด้วยค่าในการอ้างสิทธิ์ "aud" เมื่อมีการอ้างสิทธิ์นี้ JWT จะต้องถูกปฏิเสธ ในกรณีทั่วไปค่า "aud" คืออาร์เรย์ของสตริงที่คำนึงถึงขนาดตัวพิมพ์แต่ละตัวมีค่า StringOrURI ในกรณีพิเศษเมื่อ JWT มีหนึ่งผู้ชมค่า "aud" อาจเป็นสตริงที่คำนึงถึงตัวพิมพ์เล็กและใหญ่ที่มีค่า StringOrURI โดยทั่วไปแล้วการตีความค่าของผู้ชมจะเป็นไปตามความเฉพาะเจาะจง การใช้การอ้างสิทธิ์นี้เป็นทางเลือก
การaudอ้างสิทธิ์Audience ( ) ตามที่กำหนดโดยข้อมูลจำเพาะเป็นแบบทั่วไปและเป็นแอปพลิเคชันเฉพาะ วัตถุประสงค์การใช้งานคือการระบุผู้รับที่ต้องการของโทเค็น ความหมายของผู้รับหมายถึงแอปพลิเคชันเฉพาะ ค่าผู้ชมอาจเป็นรายการสตริงหรืออาจเป็นสตริงเดียวก็ได้หากมีการaudอ้างสิทธิ์เพียงรายการเดียว ผู้สร้างโทเค็นไม่บังคับให้audมีการตรวจสอบความถูกต้องอย่างถูกต้องความรับผิดชอบคือผู้รับในการพิจารณาว่าควรใช้โทเค็นหรือไม่
ไม่ว่าค่าจะเป็นเท่าใดเมื่อผู้รับตรวจสอบความถูกต้องของ JWT และต้องการตรวจสอบความถูกต้องว่าโทเค็นถูกนำไปใช้เพื่อวัตถุประสงค์ของมันต้องกำหนดว่าค่าใดในการaudระบุตัวเองและโทเค็นควรตรวจสอบความถูกต้องก็ต่อเมื่อ ID ที่ประกาศของผู้รับคือ มีอยู่ในaudข้อเรียกร้อง ไม่สำคัญว่านี่คือ URL หรือสตริงเฉพาะแอปพลิเคชันอื่น ๆ ตัวอย่างเช่นหากระบบของฉันตัดสินใจระบุตัวเองaudด้วยสตริงapi3.app.comควรยอมรับ JWT ก็ต่อเมื่อการaudอ้างสิทธิ์มีapi3.app.comอยู่ในรายการค่าผู้ชมเท่านั้น
แน่นอนว่าผู้รับอาจเลือกที่จะไม่สนใจaudดังนั้นสิ่งนี้จะมีประโยชน์ก็ต่อเมื่อผู้รับต้องการการตรวจสอบเชิงบวกว่าโทเค็นถูกสร้างขึ้นโดยเฉพาะ
การตีความของฉันตามข้อกำหนดคือการaudอ้างสิทธิ์มีประโยชน์ในการสร้าง JWT ที่สร้างขึ้นตามวัตถุประสงค์ซึ่งใช้ได้เฉพาะกับวัตถุประสงค์บางประการเท่านั้น สำหรับระบบหนึ่งอาจหมายความว่าคุณต้องการให้โทเค็นใช้ได้กับคุณสมบัติบางอย่าง แต่ใช้ไม่ได้กับระบบอื่น คุณสามารถออกโทเค็นที่ จำกัด เฉพาะ "ผู้ชม" บางกลุ่มในขณะที่ยังคงใช้คีย์และอัลกอริทึมการตรวจสอบความถูกต้องเดียวกัน
เนื่องจากในกรณีทั่วไป JWT ถูกสร้างขึ้นโดยบริการที่เชื่อถือได้และถูกใช้โดยระบบอื่น ๆ ที่เชื่อถือได้ (ระบบที่ไม่ต้องการใช้โทเค็นที่ไม่ถูกต้อง) ระบบเหล่านี้จำเป็นต้องประสานค่าที่จะใช้
แน่นอน, audเป็นทางเลือกที่สมบูรณ์และสามารถละเว้นได้หากกรณีการใช้งานของคุณไม่รับประกัน หากคุณไม่ต้องการ จำกัด โทเค็นให้ใช้กับผู้ชมบางกลุ่มหรือไม่มีระบบของคุณที่จะตรวจสอบaudโทเค็นจริงก็ไม่มีประโยชน์
ตัวอย่างหนึ่งที่สร้างขึ้น (แต่เรียบง่าย) ที่ฉันคิดได้คือบางทีเราต้องการใช้ JWT เพื่อเข้าถึงและรีเฟรชโทเค็นโดยไม่ต้องใช้คีย์การเข้ารหัสและอัลกอริทึมแยกต่างหาก แต่ต้องการให้แน่ใจว่าโทเค็นการเข้าถึงจะไม่ตรวจสอบความถูกต้องเป็นโทเค็นรีเฟรชหรือรอง - ตรงกันข้าม
ด้วยการใช้audเราสามารถระบุการอ้างสิทธิ์refreshสำหรับโทเค็นการรีเฟรชและการอ้างสิทธิ์accessสำหรับโทเค็นการเข้าถึงเมื่อสร้างโทเค็นเหล่านี้ เมื่อมีการร้องขอเพื่อรับโทเค็นการเข้าถึงใหม่จากโทเค็นการรีเฟรชเราจำเป็นต้องตรวจสอบว่าโทเค็นการรีเฟรชเป็นโทเค็นการรีเฟรชของแท้ การaudตรวจสอบความถูกต้องตามที่อธิบายไว้ข้างต้นจะบอกเราว่าโทเค็นนั้นเป็นโทเค็นการรีเฟรชที่ถูกต้องหรือไม่โดยมองหาการอ้างสิทธิ์refreshในaudใน
audอ้างสิทธิ์JWTรหัสไคลเอ็นต์ OAuth ไม่เกี่ยวข้องกันโดยสิ้นเชิงและไม่มีความสัมพันธ์โดยตรงกับ JWT audอ้างสิทธิ์จากมุมมองของ OAuth โทเค็นเป็นวัตถุทึบแสง
แอปพลิเคชันที่รับโทเค็นเหล่านี้มีหน้าที่ในการแยกวิเคราะห์และตรวจสอบความหมายของโทเค็นเหล่านี้ ฉันไม่เห็นคุณค่ามากนักในการระบุรหัสไคลเอ็นต์ OAuth ภายในการaudอ้างสิทธิ์JWT
ฉันรับรู้ว่าสิ่งนี้ถูกแท็กสำหรับ oauth 2.0 และไม่ใช่ OIDC อย่างไรก็ตามมักมีความขัดแย้งระหว่าง 2 มาตรฐานเนื่องจากทั้งสองมาตรฐานสามารถใช้ JWT และการaudอ้างสิทธิ์ได้ และหนึ่ง (OIDC) นั้นเป็นส่วนขยายของอีกอันหนึ่ง (OAUTH 2.0) (ฉันเจอคำถามนี้โดยมองหา OIDC ด้วยตัวเอง)
สำหรับ OAuth 2.0 โทเค็นการเข้าถึงคำตอบที่มีอยู่ครอบคลุมได้ดี นอกจากนี้นี่คือส่วนที่เกี่ยวข้องอีกหนึ่งส่วนจากOAuth 2.0 Framework (RFC 6749)
สำหรับไคลเอ็นต์สาธารณะที่ใช้โฟลว์โดยนัยข้อกำหนดนี้ไม่ได้จัดเตรียมวิธีการใด ๆ สำหรับไคลเอ็นต์ในการพิจารณาว่าไคลเอ็นต์ใดที่มีการออกโทเค็นการเข้าถึง
... การ
พิสูจน์ตัวตนเจ้าของทรัพยากรกับไคลเอ็นต์อยู่นอกขอบเขตสำหรับข้อกำหนดนี้ ข้อกำหนดใด ๆ ที่ใช้กระบวนการอนุญาตเป็นรูปแบบของการรับรองความถูกต้องของผู้ใช้ปลายทางที่มอบหมายให้กับไคลเอ็นต์ (เช่นบริการลงชื่อเข้าใช้ของบุคคลที่สาม) ต้องไม่ใช้ขั้นตอนโดยนัยโดยไม่มีกลไกการรักษาความปลอดภัยเพิ่มเติมที่จะทำให้ไคลเอ็นต์ตรวจสอบว่าการเข้าถึง โทเค็นถูกออกเพื่อใช้งาน (เช่นผู้ชม - จำกัด โทเค็นการเข้าถึง)
OIDC มีID Tokenนอกเหนือจากโทเค็นการเข้าถึง ข้อกำหนด OIDC มีความชัดเจนเกี่ยวกับการใช้การaudอ้างสิทธิ์ใน ID Tokens ( openid-connect-core-1.0 )
AUD
จำเป็น ผู้ชมที่ ID Token นี้มีไว้สำหรับ ต้องมี OAuth 2.0 client_id ของ Relying Party เป็นค่าผู้ชมนอกจากนี้ยังอาจมีตัวระบุสำหรับผู้ชมอื่น ๆ ในกรณีทั่วไปค่า aud คืออาร์เรย์ของสตริงที่คำนึงถึงตัวพิมพ์เล็กและใหญ่ ในกรณีพิเศษทั่วไปเมื่อมีผู้ชมหนึ่งคนค่า aud อาจเป็นสตริงที่คำนึงถึงตัวพิมพ์เล็กและใหญ่เพียงตัวเดียว
นอกจากนี้ OIDC ยังระบุการazpอ้างสิทธิ์ที่ใช้ร่วมกับaudเมื่อaudมีค่ามากกว่าหนึ่งค่า
ตัว
เลือกazp ฝ่ายที่ได้รับอนุญาต - ฝ่ายที่ออก ID Token หากมีอยู่จะต้องมีรหัสไคลเอ็นต์ OAuth 2.0 ของฝ่ายนี้ การอ้างสิทธิ์นี้จำเป็นเฉพาะเมื่อ ID Token มีค่าผู้ชมเดียวและผู้ชมนั้นแตกต่างจากฝ่ายที่ได้รับอนุญาต อาจรวมได้แม้ว่าฝ่ายที่ได้รับอนุญาตจะเป็นคนเดียวกับผู้ชมเพียงคนเดียว ค่า azp เป็นสตริงที่คำนึงถึงตัวพิมพ์เล็กและใหญ่ที่มีค่า StringOrURI
แม้ว่าเรื่องนี้จะเก่า แต่ฉันคิดว่าคำถามนี้ใช้ได้แม้กระทั่งในปัจจุบัน
ความสงสัยของฉันคือ aud ควรอ้างถึงเซิร์ฟเวอร์ทรัพยากรและ client_id ควรอ้างถึงหนึ่งในแอปพลิเคชันไคลเอนต์ที่เซิร์ฟเวอร์รับรองความถูกต้อง
ใช่Audควรหมายถึงบุคคลที่ใช้โทเค็น และclient_idหมายถึงบุคคลที่ได้รับโทเค็น
ในกรณีปัจจุบันเซิร์ฟเวอร์ทรัพยากรของฉันยังเป็นไคลเอนต์เว็บแอปของฉัน
ในสถานการณ์ของ OP เว็บแอปและเซิร์ฟเวอร์ทรัพยากรเป็นของฝ่ายเดียวกัน ดังนั้นจึงหมายความว่าลูกค้าและผู้ชมจะเหมือนกัน แต่อาจมีสถานการณ์ที่ไม่เป็นเช่นนั้น
ลองนึกถึงสปาที่ใช้ทรัพยากรที่มีการป้องกัน OAuth ในสถานการณ์นี้ SPA คือไคลเอนต์ ทรัพยากรที่มีการป้องกันคือผู้ชมของโทเค็นการเข้าถึง
สถานการณ์ที่สองนี้น่าสนใจ มีแบบร่างที่ใช้งานได้ชื่อ " ตัวบ่งชี้ทรัพยากรสำหรับ OAuth 2.0 " ซึ่งอธิบายว่าคุณสามารถกำหนดผู้ชมเป้าหมายในคำขออนุญาตของคุณได้ที่ใด ดังนั้นโทเค็นที่ได้จะ จำกัด เฉพาะผู้ชมที่ระบุ นอกจากนี้ Azure OIDC ยังใช้วิธีการที่คล้ายกันซึ่งอนุญาตให้ลงทะเบียนทรัพยากรและอนุญาตให้คำขอรับรองความถูกต้องมีพารามิเตอร์ทรัพยากรเพื่อกำหนดผู้ชมเป้าหมายโทเค็นการเข้าถึง กลไกดังกล่าวช่วยให้การโฆษณา OAuth มีการแยกระหว่างลูกค้าและฝ่ายที่ใช้โทเค็น (ผู้ชม)
aud REQUIRED for session_token. Contains the client_id of the client receiving the assertion.