Difference between revisions of "JWT"

From MgmtWiki
Jump to: navigation, search
(→‎Solutions)
 
(22 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
==Full Title==
 
==Full Title==
−
JSON Web Token (JWT)
+
JSON Web Token (JWT) --  pronounced "JOOT" as though it were Welsh.
  
 
==Context==
 
==Context==
−
In [[OAuth 2.0]]  
+
*In [[OAuth 2.0]] and other specs from the Open ID Foundation, there was a need for a small packed of identity information that could be coded and include in an HTTP header.
 +
*Since that humble beginning the JWT format has been extended in scope and more typically is delivered in the body of a post message which gets around the size limit experienced in an HTTP header.
  
 
==Problems==
 
==Problems==
−
* OAuth 2.0 still depends on shared secrets between services on [[Web Site]]s and other internet devices;<ref>Justin Richer, ''What's Wrong With OAuth 2?'' https://twitter.com/justin__richer/status/1023738139200778240</ref> while most sites are protected by public keys and certificates, at least until quantum computing arrives.
+
* The existing specs at the time the [[JWT]] was created were XML and [[SAML 2.0|SAML]] which were very wordy and not amenable to coding in an HTTP header.
−
* It is still just a collection of parts that can be configured in a wide variety of combinations; most of which are not particularly secure.
+
* Even now some JWT are too large for inclusion in a HTTP header.
−
* Token type "bearer" is still the only one used in real-world implementations. See the page [[Bearer Tokens Considered Harmful]] on this wiki.
 
−
* The redirect URL is not well specified in the spec and is subject many exploits. The problem is poor implementations and reuse of each client id across many implementations.
 
−
* HTTP refer header is usually sent in the clear and contains way too much information in Front Channel implementations.
 
−
* Security UX is complicated and not described in the spec.
 
−
* State parameters are needed for security, but not required by the spec.
 
−
* A bunch of specs implemented other ways to enable secure, such as UMA, PCKE, etc.
 
−
* Implicit flow was added to enable javascript, but recent innovations in browser has weaken the existing very weak security.
 
−
* Resource Owner password turned into a really bad idea. It should be banned.
 
−
* Scopes were created, but not explicitly defined, so there is no way to determine what a scope actually means.
 
−
* Discovery is not well defined, but always leaks information.
 
  
 
==Solutions==
 
==Solutions==
−
*The RFC definition of the [https://tools.ietf.org/html/rfc7519 JSON Web Token (JWT)]
+
*The RFC 7519 definition of the [https://tools.ietf.org/html/rfc7519 JSON Web Token (JWT)]. The abstract from the spec <blockquote>  JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties.  The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature ([[JWS]]) structure or as the plaintext of a JSON Web Encryption ([[JWE]]) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</blockquote>
 +
[[File:JTW Jason Token.jpg|thumb|right|400px]]
 +
 
 
*Justin Richer has some suggestions.<ref>Justin Richer, ''Moving On from OAuth 2: A Proposal.'' https://medium.com/@justinsecurity/moving-on-from-oauth-2-629a00133ade</ref>
 
*Justin Richer has some suggestions.<ref>Justin Richer, ''Moving On from OAuth 2: A Proposal.'' https://medium.com/@justinsecurity/moving-on-from-oauth-2-629a00133ade</ref>
 +
 +
The Image on the right is of a JWT - Json Token. It may be expanded to original size by clicking on the box in the lower right of the image.
  
 
==References==
 
==References==
 +
<references />
 +
===Other reference material===
 +
# [https://blog.angular-university.io/angular-jwt/ JWT: The Complete Guide to JSON Web Tokens] from the folks that brought you angular.
 +
# [https://jwt.io/ JWT.IO]] allows you to decode, verify and generate JWT.
 +
# RFC 7515 JSON Web Signature (JWS) <blockquote>represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures.  Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web  Algorithms (JWA) specification and an IANA registry defined by that  specification.  Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</blockquote>
 +
# RFC 7516 Json Web Encryption ([[JWE]])<blockquote>represents encrypted content using JSON-based data structures.  Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification.  Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification</blockquote>
 +
# RFC 7517 JSON Web Key (JWK)<blockquote>a JavaScript Object Notation (JSON) data structure that represents a cryptographic key.  This specification also defines a JWK Set JSON data structure that represents a set of JWKs.  Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification</blockquote>
 +
# RFC 7518 JSON Web Algorithms (JWA)<blockquote>registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications.  It defines several IANA registries for these identifiers.</blockquote>
 
# RFC 6749 The OAuth 2.0 Authorization Framework specification
 
# RFC 6749 The OAuth 2.0 Authorization Framework specification
 
# RFC 8252 OAuth 2.0 for Native Apps Specification
 
# RFC 8252 OAuth 2.0 for Native Apps Specification
−
 
−
 
 
[[Category:Glossary]]
 
[[Category:Glossary]]
 
[[Category:Standard]]
 
[[Category:Standard]]

Latest revision as of 20:51, 24 July 2023

Full Title

JSON Web Token (JWT) -- pronounced "JOOT" as though it were Welsh.

Context

  • In OAuth 2.0 and other specs from the Open ID Foundation, there was a need for a small packed of identity information that could be coded and include in an HTTP header.
  • Since that humble beginning the JWT format has been extended in scope and more typically is delivered in the body of a post message which gets around the size limit experienced in an HTTP header.

Problems

  • The existing specs at the time the JWT was created were XML and SAML which were very wordy and not amenable to coding in an HTTP header.
  • Even now some JWT are too large for inclusion in a HTTP header.

Solutions

  • The RFC 7519 definition of the JSON Web Token (JWT). The abstract from the spec
    JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.
JTW Jason Token.jpg
  • Justin Richer has some suggestions.[1]

The Image on the right is of a JWT - Json Token. It may be expanded to original size by clicking on the box in the lower right of the image.

References

  1. ↑ Justin Richer, Moving On from OAuth 2: A Proposal. https://medium.com/@justinsecurity/moving-on-from-oauth-2-629a00133ade

Other reference material

  1. JWT: The Complete Guide to JSON Web Tokens from the folks that brought you angular.
  2. JWT.IO] allows you to decode, verify and generate JWT.
  3. RFC 7515 JSON Web Signature (JWS)
    represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.
  4. RFC 7516 Json Web Encryption (JWE)
    represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification
  5. RFC 7517 JSON Web Key (JWK)
    a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification
  6. RFC 7518 JSON Web Algorithms (JWA)
    registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers.
  7. RFC 6749 The OAuth 2.0 Authorization Framework specification
  8. RFC 8252 OAuth 2.0 for Native Apps Specification
Retrieved from "http://tcwiki.azurewebsites.net/index.php?title=JWT&oldid=18379"