ประเภทส่วนหัวการอนุญาต HTTP ที่ดีที่สุดสำหรับ JWT

ฉันสงสัยว่าAuthorizationประเภทหัว HTTP ที่เหมาะสมที่สุดสำหรับโทเค็น JWTคืออะไร

Basicหนึ่งในชนิดที่นิยมอาจจะมากที่สุดคือ ตัวอย่างเช่น

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

มันจัดการสองพารามิเตอร์เช่นเข้าสู่ระบบและรหัสผ่าน ดังนั้นจึงไม่เกี่ยวข้องกับโทเค็น JWT

นอกจากนี้ฉันได้ยินเกี่ยวกับประเภทผู้ถือเช่น:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

อย่างไรก็ตามฉันไม่รู้ความหมายของมัน มันเกี่ยวข้องกับหมีหรือไม่?

มีวิธีการใช้โทเค็น JWT ในAuthorizationส่วนหัวHTTP หรือไม่ เราควรใช้Bearerหรือควรลดความซับซ้อนและเพียงแค่ใช้:

Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

ขอบคุณ

แก้ไข:

หรืออาจเป็นเพียงJWTส่วนหัว HTTP:

JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

ส่วนหัว HTTP ที่ดีที่สุดสำหรับลูกค้าของคุณในการส่งโทเค็นการเข้าถึง (JWT หรือโทเค็นอื่น ๆ ) เป็นAuthorizationส่วนหัวที่มีBearerรูปแบบการตรวจสอบความถูกต้อง

โครงการนี้มีการอธิบายโดยRFC6750

ตัวอย่าง:

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIXVCJ9TJV...r7E20RMHrHDcEfxjoYZgeFONFh7HgQ

หากคุณต้องการการรักษาความปลอดภัยที่แข็งแกร่งนอกจากนี้คุณยังอาจพิจารณาร่าง IETF ต่อไปนี้: https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture ร่างนี้น่าจะเป็นทางเลือกที่ดี (ที่ถูกทิ้งร้าง?) https://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac

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

ซึ่งแตกต่างจากที่กำหนดเองJWTรูปแบบที่คุณกล่าวถึงในคำถามของคุณหนึ่งมีการลงทะเบียนที่ IANABearer

เกี่ยวกับรูปแบบBasicและการDigestรับรองความถูกต้องพวกเขาจะทุ่มเทให้กับการตรวจสอบโดยใช้ชื่อผู้ใช้และความลับ (ดูRFC7616และRFC7617 ) ดังนั้นจึงไม่สามารถใช้ได้ในบริบทนั้น

คำตอบสั้น ๆ

Bearerโครงการตรวจสอบคือสิ่งที่คุณกำลังมองหา

คำตอบที่ยาว

มันเกี่ยวข้องกับหมีหรือไม่?

ผิดพลาด ... ไม่ :)

ตามพจนานุกรม Oxfordนี่คือคำจำกัดความของผู้ถือ :

ผู้ถือ _{^{/ ˈbɛːrə /}}
คำนาม

1. บุคคลหรือสิ่งที่บรรทุกหรือถือสิ่งของ

2. บุคคลที่แสดงเช็คหรือคำสั่งอื่น ๆ เพื่อชำระเงิน

ความหมายแรกรวมถึงคำพ้องความหมายต่อไปนี้: messenger , ตัวแทน , ลำเลียง , นักการทูต , ผู้ให้บริการ , ผู้ให้บริการ

และนี่คือคำจำกัดความของโทเค็นผู้ถือตามRFC 6750 :

1.2 คำศัพท์

ผู้ถือโทเค็น

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

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

ยึดตามมาตรฐานมากที่สุดเท่าที่จะทำได้และไม่สร้างแผนการรับรองความถูกต้องของคุณเอง

ต้องส่งโทเค็นการเข้าถึงในAuthorizationส่วนหัวคำขอโดยใช้Bearerรูปแบบการตรวจสอบความถูกต้อง:

2.1 ฟิลด์ส่วนหัวคำขออนุมัติ

เมื่อส่งโทเค็นการเข้าถึงในAuthorizationฟิลด์ส่วนหัวคำขอที่กำหนดโดย HTTP / 1.1 ไคลเอ็นต์จะใช้Bearerรูปแบบการตรวจสอบความถูกต้องเพื่อส่งโทเค็นการเข้าถึง

ตัวอย่างเช่น:

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM

[ ... ]

ลูกค้าควรทำการร้องขอที่รับรองความถูกต้องด้วยโทเค็นผู้ถือโดยใช้Authorizationฟิลด์ส่วนหัวคำขอที่Bearerมีรูปแบบการให้สิทธิ์ HTTP [ ... ]

ในกรณีที่โทเค็นไม่ถูกต้องหรือหายไปBearerรูปแบบควรรวมอยู่ในWWW-Authenticateส่วนหัวการตอบสนอง:

3. ฟิลด์ส่วนหัวการตอบกลับรับรองความถูกต้อง WWW

หากการร้องขอทรัพยากรที่มีการป้องกันไม่รวมถึงการรับรองความถูกต้องหรือไม่มีโทเค็นการเข้าถึงที่เปิดใช้งานการเข้าถึงทรัพยากรที่มีการป้องกันเซิร์ฟเวอร์ทรัพยากรต้องมีWWW-Authenticateฟิลด์ส่วนหัวการตอบสนองHTTP [... ]

Bearerความท้าทายทั้งหมดที่กำหนดโดยข้อกำหนดนี้จะต้องใช้ค่ารับรองความถูกต้องโครงการ แบบแผนนี้จะต้องตามด้วยค่า auth-param อย่างน้อยหนึ่งค่า [ ... ]

ตัวอย่างเช่นในการตอบสนองต่อการร้องขอทรัพยากรที่มีการป้องกันโดยไม่มีการตรวจสอบ:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"

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

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example",
                         error="invalid_token",
                         error_description="The access token expired"