Should I Use jwts For Authentication Tokens?

• openpubkey

  5 608 8.3 Go

  Reference implementation of OpenPubkey

  

  > By just using a “normal” opaque session token and storing it in the database, the same way Google does with the refresh token, and dropping all jwt authentication token nonsense.

  Not only is this true, but most actual deployments of JWTs just have you swap a JWT (ID Token) for a opaque session token.

  That said, I really like having a JWT signed by an IDP which states the user's identity because if designed correctly you only need to trust one party IDP. For instance Google (the IDP) is the ideal party to identify a gmail email address since you already have to trust them for this. I created OpenPubkey to leverage JWTs, while minimizing and in some cases removing trust.

  OpenPubkey[0, 1] let's you turn JWTs bearer tokens into certificates. This lets you use digital signatures with ephemeral secrets.

  [0]: https://github.com/openpubkey/openpubkey

• InfluxDB

  www.influxdata.com featured

  Purpose built for real-time analytics at any scale. InfluxDB Platform is powered by columnar analytics, optimized for cost-efficient storage, and built with open data standards.

  

• php-jwt

  18 9,363 5.2 PHP

  PHP package for JWT

  

  The vulnerability is usually in verifiers rather than signers.

  See, for example:

  https://github.com/firebase/php-jwt/issues/351

• quickfeed

  1 20 9.7 Go

  QuickFeed server and web frontend for instant feedback on programming assignments

  

  A former student of mine (Vera Yaseneva) redesigned our old auth architecture using jwts and I’m pretty happy with how it turned out. Maybe it is overkill for our simple autograder server, but it was fun getting it to work and I’m sure it is more secure than the old architecture which had many many flaws… it was a maintenance nightmare for years. After the redesign it has been a breeze. Here is the project https://github.com/quickfeed/quickfeed

  The security arch is mainly in web/auth and web/interceptor packages if anyone is interested in learning from the code. It uses connectrpc, which has a nice interceptor arch.

  Happy to share Vera’s thesis report if anyone is interested…

• Devise

  98 23,898 5.2 Ruby

  Flexible authentication solution for Rails with Warden.

  

  IMHO the stateful opaque token approach is simple enough that it can (and often does) get baked into whatever language/framework you’re using to write your app. In addition, the very nature of session tokens is such that the logic for what the token actually means/represents lives in your app, on the server.

  So, that may be why we don’t see more “opaque session token” standards/libraries out there as an alternative to JWTs.

  But if you want an existing example, Devise for Rails [1] has been around a while.

  [1] https://github.com/heartcombo/devise

• aws-cognito

  1 6 6.7 JavaScript

  

  I typically use a service like AWS cognito (using their built-in hosted UI) to handle authentication for my apps. That gives me MFA, Google/Facebook login, email verification, etc for free and has a generous free tier.

  I have a template that's backed by terraform and the authentication client is in lambda so the whole thing is serverless, self-contained and practically free. So I just run "terraform apply" and I have scalable auth for my new service.

  https://github.com/alshdavid/template-cognito

  If any service I create is lucky enough to break out of the free-tier, then I can just move to another OAuth2/OIDC provider. The auth mechanism Cognito uses is just a specification meaning I am not coupled to any one service provider (though the user accounts themselves are). Cognito, Auth0, IdentifyServer, or whatever - I can migrate if cost becomes a problem.

  The big issue with JWTs are that, if lost, they give permissions to attackers without revocability.

  For this reason, I keep auth-tokens short lived and refresh them often. Refresh-tokens are revocable and live for a few days. This means that a lost auth-token is only harmful for a few minutes while a lost refresh token is only harmful until revoked or expired.

  Tokens are stored as path-specific http-only headers so the only vector for attack is if a user physically opens devtools and gives an attacker the token - or if the attacker has access to the computer directly (physically or via a malicious terminal script).

  High risk operations (e.g. delete account, delete content, anything high risk) requires "step-up" authentication - so a user is asked to re-authenticate in those cases.

• auth-jwt

  4 244 0.0 TypeScript

  A demo to learn JWT by reverse engineering

  Start with usual session based authentication. Keep it until you see the absolute need to move to JWT. And make sure you understand JWT and "invalidating JWT" before using it - https://github.com/gitcommitshow/auth-jwt?tab=readme-ov-file...

Suggest a related project