* MessageVerifier defaults to SHA1. That hasn't been a good default for a few years now.

* It doesn't support expiry as a claim; you have to check it against the current time manually, and factor in leeway if you want that. Because no one ever screwed up a timestamp check.

* It doesn't support any other verifiable claims, for that matter, so if you want to add e.g. issuer and issued-at, you'll have to do so manually.

* If you're not writing a Rails app, you have to pull in ActiveSupport... or copy code, as you suggest, which seems bad for other reasons. Surely maintaining your own crypto fork is almost as bad as writing your own crypto in the first place?

* To the best of my knowledge, ruby-jwt has not suffered either of the two JWT vulnerabilities discussed in this thread.

Finally, why is this "simple":

    @verifier = ActiveSupport::MessageVerifier.new('s3Krit', digest: 'SHA256')

    cookies[:remember_me] = @verifier.generate([@user.id, 2.weeks.from_now])

But this is "bad":

    payload = { sub: @user.id, exp: Time.now.to_i + 1_209_600 }

    cookies[:remember_me] = JWT.encode(payload, 's3Krit', 'HS256')

They seem fairly equivalent to me?

1. https://github.com/rails/rails/blob/master/activesupport/lib... feel free to change the default, if you find enough reasons for rails team (beware: it's hard).

2. it doesn't, internal session class does and IMO most apps do not need expire claim.

3. Just put issuer/issued_at/whatever in your object

4. I suggest to look at messageverifier and do your own (and use sha256 hmac). Why? Lets consider 50 lines of code not "maintaining your crypto fork" but merely helpers.

5. JWT has more LOC inside, say header payload is just useless. I believe having OpenSSL::HMAC helpers is better and simple enough to not do it wrong

Thanks for your response.

> 2. it doesn't, internal session class does and IMO most apps do not need expire claim.

If you're generating a token to send to an SPA or native app, you can't rely on any other expiration mechanism. It needs to be embedded in the token or stored server-side in a database-backed session or what have you.

> 3. Just put issuer/issued_at/whatever in your object

You're missing the point that these features would require additional SLOC to verify the "claims."

> 4. I suggest to look at messageverifier and do your own (and use sha256 hmac). Why? Lets consider 50 lines of code not "maintaining your crypto fork" but merely helpers.

By this logic, ruby-jwt isn't crypto, just helpers. It seems to be frowned upon simply because it includes additional features some people may not need, and those features and alternative signing methods require more SLOC than your presumed "optimal" implementation. Do you see no value in a flexible, reusable library?

> 5. JWT has more LOC inside, say header payload is just useless. I believe having OpenSSL::HMAC helpers is better and simple enough to not do it wrong

How can critics justify the position that people should write their own OpenSSL::HMAC helpers because they can't correctly call the JWT helpers?

He didn't say use SESSIONS, he said use COOKIES for the data you would expect to go within a session. They scale just fine. You shouldn't be storing that much data in a JWT either.

> Session cookies suck

Well that's got me convinced, compelling argument old chap.

> and don't scale.

The vast majority of developers in the world are never going to actually need the type of scalability that requires stateless tokens for authentication.

Can you elaborate on your first sentence?

I've been using headerless JWTs for stateless API authentication and authorization (JWT without the first segment), but the work is preliminary and I wonder if I'm doing it wrong.

A JWT is a signed token - or at least, in most cases, is?

JWT is a subset of signed tokens, but using home baked signed token is still great.