Paseto is better https://paseto.io/ , but unfortunately OAuth forces the usage of JWT.
It seems to be a NIH-ed serialization format with hard-coded ciphersuits. It doesn't seem to support use-cases like delegation and claims.
31–40 of 159 posts
Paseto is better https://paseto.io/ , but unfortunately OAuth forces the usage of JWT.
It seems to be a NIH-ed serialization format with hard-coded ciphersuits. It doesn't seem to support use-cases like delegation and claims.
Love JWTs but I wish there was a better standard for conveying detailed and compact authorization information, for systems requiring enforcement of complex authorization rules. We experimented once with trying to put permissions on a JWT (more complex than your popular scopes) but that makes them grow quickly. And we experimented with putting role information on JWTs but that results in re-centralization of logic. Ma…
Attempting to generalize it ends up in pain, suffering, and AWS IAM.
Paseto is better https://paseto.io/ , but unfortunately OAuth forces the usage of JWT.
I fail to see how it's better, except for hand-waving about potential crypto attacks? It seems to be a NIH-ed serialization format with hard-coded ciphersuits. It doesn't seem to support use-cases like delegation and claims.
Paseto is better https://paseto.io/ , but unfortunately OAuth forces the usage of JWT.
Every time I want to use a JWT, it seems like it's the suboptimal choice, so I've never found a genuine use case for them. Most recently, I wanted to implement 2FA w/ TOTP. I figure I'll use 1 cookie for the session, and another cookie as a TOTP bypass. If the user doesn't have a 2FA bypass cookie, then they have to complete the 2FA challenge. Great, so user submits username & password like normal, if they pass but d…
The use-case I always remember people presenting for JWTs was mostly part of the "serverless" fad/hype.
The theory was presented like this: If you use a JWT your application logic can be stateless when it comes to authentication; So you don't need to load user info from a session database/kv store, it's right there in the request...
The only way that makes any sense to me, is if your application has zero storage of its own: it's all remote APIs/services, including your authentication source. I'm sure there are some applications like that, but I find it hard to believe that's how/why it's used most of the time.
Never underestimate this industry's ability to get obsessed with the new shiny.
I had an eye opening experience many years ago with a junior dev (I was significantly more experienced than he was then, but wouldn't have called myself "senior" at the time).
He had written an internal tool for the agency we both worked for/through. I don't recall the exact specifics, but I remember the accountant was involved somewhat, and it was a fairly basic CRUD-y PHP/MySQL app. Nothing to write home about, but it worked fine.
At some point he had an issue getting his php/mysql environment configured (I guess on a new laptop?) - this was before the time of Docker; Vagrant was likely already a thing but he wasn't using it.
From what he explained afterwards I believe it was just the extremely common issue that connecting to "localhost" causes the mysql client to attempt a socket connection, and the default socket location provided in php isn't always correct.
As I said, I heard about this after he'd decided that connection issue (with an app that had already been working well enough to show off to powers-that-be and get approval to spend more paid time on it) was enough to warrant re-writing the entire thing to use MongoDB.
As I said: never underestimate this industry's ability to get obsessed with the new shiny.
Earlier quoted context omitted.
I use JWTs with RSA key pairs primarily. I tell the other service to make the pair and send me the public. I never see the private. Then I can verify all their tokens with the public key. This way I don’t have to worry about sharing the secret. It never leaves the other service.
I think you meant verify with public key.
Earlier quoted context omitted.
> Did you mean cert exchange, because keys are just a very long password My experience differs: My private key is only 256 bits (32 bytes, which base64 encodes up to 44 characters, if you use padding). My typical passwords are 40-64 characters (unless stupid requirements force me to go shorter).
What algorithm are you using? RSA keys are normally at least 2048 bits in length.
[1]: https://en.wikipedia.org/wiki/EdDSA#Ed25519
[2]: https://www.iana.org/assignments/jose/jose.xhtml#web-signatu...
Love JWTs but I wish there was a better standard for conveying detailed and compact authorization information, for systems requiring enforcement of complex authorization rules. We experimented once with trying to put permissions on a JWT (more complex than your popular scopes) but that makes them grow quickly. And we experimented with putting role information on JWTs but that results in re-centralization of logic. Ma…
> Biscuit is an authorization token with decentralized verification, offline attenuation and strong security policy enforcement based on a logic language
Is there an RSS feed for this blog?