Hardcoded secrets, unverified tokens, and other common JWT mistakes

Paseto appears to be something that attempts to be "JWT but with sensible choices already made".

When it comes down to it, you need some crypto knowledge to make these choices. We constrain them to PS256 and ES256 in our system (but then you also need to make sure that the curve used for your keys for the ES256 signature is an acceptable one)

The SPIFFE JWT-SVID standard attempts this, although for a specific context: https://github.com/spiffe/spiffe/blob/master/standards/JWT-S...

Here's your recommendations: https://security.stackexchange.com/a/233863/111020

And yes I just spent 2 hours writing that.

There can't be a great authentication/crypto that can improve over time. In theory, it must block old things to be state of the art. In practice, it's used in client-server communications, that would break all communications if nothing could talk unless they're always on the exact same version.

Regarding logout, I think that's a fundamental issue with a stateless solution like JWTs. I mean, the whole point is that it is a self encapsulated token, so you don't have to go back to a central server to check if someone's login session is still valid. So how on earth do you invalidate it?

My boss wrote up this article on different ways to revoke JWTs: https://fusionauth.io/learn/expert-advice/tokens/revoking-jw... which examines a few interesting methods.

>rarely talking about the hard things like logout

Why hard?

You can always black list them

Of course you can improve the tooling but it's not the only conclusion.

If you don't read the docs, don't have the right mentoring, etc etc, your first go at anything is likely to be of low quality. Calibrate your confidence better, especially for anything security-related. Don't put it into production if you've only skimmed the docs (the mistakes we're talking about are novice mistakes).

Another conclusion you could draw is "use a built in security library not raw JWTs". There's just as much reason not to use a security library as there is not to use a SQL ORM.

What would you suggest instead?

Irrelevant. If the application doesn't call the function to verify the user token, the application is insecure, it doesn't matter what protocol or token format is used.

That's similar to saying that CRUD apps are bad because you can have SQL injection (as others have mentioned). Or that username/password is a "not very good authentication protocol" because some folks store passwords in a database in plaintext. Sure, the "none" algorithm is a footgun, but just make sure you don't allow it.

Maybe I'm talking my book (because I work for a company that sells software which generates JWTs) but I think it isn't that hard to securely validate them. It's just matching on JSON keys, mostly, and can be wrapped up in a library (like https://github.com/jwt/ruby-jwt).

I also wrote an article on how to build secure JWTs: https://fusionauth.io/learn/expert-advice/tokens/building-a-...

I guess the question is, where's the balance between the responsibility of the application developer vs the RFC authors? That's an interesting discussion to have, because I bet there is at least one valid use case for every one of the JWT RFC sections. (I've even heard of valid cases for the "none" algo, like if you are very concerned about performance and have other ways of validating your clients, such as mutual TLS certs.)

I've never written an RFC/standard, but I bet it isn't an easy task.

That's the thing, JWT is not an authentication protocol, that's just one (the most frequent) use-case of "transfering claims". The footguns, e.g. the choice of encrypted or not, or symmetric or asymmetric crypto, are a result of the flexbility required to cover the other use-cases. Maybe what's needed is a subset of JWT that's just for AuthN.

The only insecure-by-design authentication scheme is passing the user identifier through HTTP headers (it's unfortunately quite common). Headers are set by the web client, so any client can assume to be anyone.

Agreed. But writing your own authentication frameworks are a virtually identical situation.

>sanitize their inputs ever did.

was even escaping input viable strategy?

if you escape thing, then your data in db is broken

parametrization seems like the only strategy out of those 2

See TFA for a subset of the problems. Security should be designed so that it's easy to do it right and hard to do it wrong, but JWT offers many opportunities to do it wrong. Maybe you can figure it out with enough reading of TFA and other articles online, but there's no reason to take a risk on such a shoddy security standard in the first place.

> first off: the whole idea of using oauth in your systems is to externalize authentication. its main usecase is if you have several services which share the same users... usually microservices, but everything else which supports oauth works as well, obviously

We don't want to externalize it. For clarity _(because i think i implied internal API->API)_, our primary concern right now is a client API interfacing with our API. We want to choose some implementation that clients would expect, and easily reason about.

There may be a future where those clients have to authenticate to multiple APIs / microservices of ours, but currently it is one API setup for this explicit purpose.

> but to come back to my initial point: if you do not want to externalize your authentication, then do not use oauth! almost all frameworks already have tools available you can use to authenticate with api tokens.

Yea, not using Oauth was my thought was well. My concern however, was trying to pick something clients would expect. I don't want it to feel custom, arbitrary, hodgepodge.

Our very early impression / plan is to use a token renewal, and a shortlived token, similar to oauth. However this loose, and custom, and i don't want clients feeling like we're making things up. Hell, i don't want to make things up.

My current thought is that I need to research JWT more, as it may fit what we need, and be more standardized.

edit: And PASETO

PASETO looks interesting, thank you!

Since my primary concern is external client APIs communicating with ours securely, but also in a way that's not too-foreign. I imagine JWT would fit the bill of being widely known, but PASETO sounds really interesting too - having less things to get wrong sounds amazing. My concern with PASETO is that client APIs are huge slow customers, so i'm hesitant to choose anything that's not super mainstream.

I'll research PASETO more, but i feel like my decision would come down to fitting to what the customer can use - less change is more, in that case. Ie, JWT.

From my understanding, the use case for JWTs is where:

1) One system produces a JWT which makes a bunch of "claims" about the bearer; e.g. 'their email address is alice@example.org'.

2) Another system which trusts the first system can consume these tokens and use the "claims" to authenticate the bearer, e.g. 'the email address alice@example.org is associated with user ID 12345, so the bearer must be user 12345'.

3) Now that the user is authenticated, the second system can initiate a session for them (e.g. storing a cookie in their browser, or whatever).

4) From now on that JWT should be rejected; we can approximate this by making it short-lived, but we can do better by the second system update some state. For example, updating the "last seen" time of a user, and rejecting any tokens issued before the this time.

The idea of 'using stateless JWTs for authentication' is presumably the common practice of avoiding steps 3 and 4: rather than having the second system initiate a session for the user, the JWT is treated as if it were a session token; rather than invalidating the JWT after its first use, it is accepted over and over again as part of the user's subsequent requests. This also requires the JWTs to have a longer expiry time than necessary, since they have to survive until the user's last interaction, rather than their first (in fact 'refresh tokens' can be used as well, but the principle is the same).

As for why it's a bad idea, I recently came across PASETO (a simplified alternative to JWT) which specifically calls this out as an insecure practice due to the possibility of replay attacks ( e.g. https://github.com/paragonie/paseto/tree/master/docs#was-sta... )

Using something stateless when you want state always leads to problems. It is very convenient, for example, when you give the end-user a token that cryptographically proves that they're a certain user. They provide that to the server, and it doesn't have to access any state to allow access, saving precious milliseconds of latency. The problem comes when someone else steals the token or the user's authorization is revoked. Since you aren't checking any state, you have no way to say "oh we fired them, kill their access" or "their token got leaked, shut it off". This leads to problems where malicious access can persist and you can do nothing about it.

I feel like the problem is generally ignored to some extent. I was writing my own (stateful, one database lookup per request) SSO system and ran into other problems. For example, how do you terminate all TCP connections that the user has open when revoking the token? No proxy I could find had that level of granularity exposed through its control plane API. They are all living in an HTTP/1.1 world where requests were short-lived, and it was acceptable to handle revocation at the next request. I kind of doubt it's ever caused any problems (employees on their last day don't seem to open long-lived gRPC connections to internal infrastructure for whatever reason), but it's one of those things that's going to burn someone someday.

(I seriously considered modifying envoy to keep track of (user, downstream TCP connection) so that they could be forcibly closed via an API when necessary, but decided a global rolling restart of the frontend proxy was acceptable in the extremely rare instance when some sort incident required terminating all of a user's TCP connections. Engineering time vs. security tradeoff. But then there are companies with 100s of developers that will ship you custom software to manage authentication, and they don't have this feature. That seems shady to me. Or maybe not so much shady, just exceedingly lazy, like they haven't really thought much about their product.)

> unless you’ve implemented some sort of state store that all of your API services and server share.

Yes, it's called session storage, and it used to be incredibly common. These issues are not "orthogonal", because a primary promise of JWTs were the ability to get rid of that shared session storage and just put that identifying info into the signed token.