|
|
| Line 6: |
Line 6: |
| | | | |
| | ==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 which were very wording 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.
| |
| − | * 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== |
Revision as of 19:35, 28 May 2019
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 a HTTP header.
Problems
- The existing specs at the time the JWT was created were XML and SAML which were very wording and not amenable to coding in an HTTP header.
Solutions
- The RFC 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.
- Justin Richer has some suggestions.[1]
References
- RFC 6749 The OAuth 2.0 Authorization Framework specification
- RFC 8252 OAuth 2.0 for Native Apps Specification
↑ Justin Richer, Moving On from OAuth 2: A Proposal. https://medium.com/@justinsecurity/moving-on-from-oauth-2-629a00133ade
