Difference between revisions of "JWT"
From MgmtWiki
(→Full Title) |
|||
| 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== | ||
Revision as of 19:27, 28 May 2019
Full Title
JSON Web Token (JWT) -- pronounced "JOOT" as though it were Welsh.
Context
In OAuth 2.0
Problems
- OAuth 2.0 still depends on shared secrets between services on Web Sites and other internet devices;[1] while most sites are protected by public keys and certificates, at least until quantum computing arrives.
- 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
- The RFC definition of the JSON Web Token (JWT)
- Justin Richer has some suggestions.[2]
References
- RFC 6749 The OAuth 2.0 Authorization Framework specification
- RFC 8252 OAuth 2.0 for Native Apps Specification
