Hacker News new | past | comments | ask | show | jobs | submit login

> For almost every use I've seen in the real world, JWT is drastic overkill; often it's just an gussied-up means of expressing a trivial bearer token.

This is certainly true for schemes that require trips to a source-of-truth database to authorize a token (c->auth, c->resource, resource->auth). It's also true for schemes where the token is associated with capabilities that are loaded from a database. Using JWT to implement RBAC is flawed.

However, there is a strong use case for the token carrying its own capabilities -- that is, a token that is more than just "20 bytes of urandom".

If a resource service can derive the capabilities associated with a token generated by a trusted authentication service without contacting that service, that has real world implications for lower latency, higher throughput applications that are simpler to compose and operate.

As far the cryptographic credibility, the idea behind capability-based security is an old one, and I'm sure you're aware of the research. This particular spec may be problematic, folks may be misunderstanding and misusing the primitives, but the underlying idea is sound.

Previous HN discussion of CapSec Wikipedia article https://news.ycombinator.com/item?id=10684129

Google Fuscia https://en.wikipedia.org/wiki/Google_Fuchsia

I don't deny that capability tokens are useful; they certainly can be. JOSE is just a poor vector for getting them.

The issue isn't with capabilities, or delegated authentication, or public key tokens, or even standardizing any of those things. I think at this point I've been pretty clear about what I believe the issues actually are.

Thanks for clarifying; I'll reread your comments.

Do you have a standard that you would recommend for any of those things?

found in the article linked at the top of the page:

- crypto_auth, or HMAC-SHA256 by itself, for authentication

- crypto_secretbox for symmetric encryption

- crypto_box or TLS for public key encryption

I was asking about standards for Web-based capabilities, delegated authentication, and public key tokens; not the individual message authentication or (a)symmetric encryption components.

Echoing tptacek's comment above: the problems with using those individual pieces is in the joinery - combining them in ways that are broken.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact