Is there a difference between that token and a password? Yes, the token is bigger and created by somebody else, yet for all practical means it walks like a password and quacks like a password...
Bearer tokens are just awful
11–20 of 148 posts
Re: Bearer tokens are just awful
#12Earlier quoted context omitted.
> Or you can put device/or ip related info baked into the token. That way when the user device or ip changes, you can invalidate the token. yeah, I always wondered why there isn't a standard field in the JWT containing a fingerprint/hash of the client's machine/browser/etc.
Advertisers would love such a thing
> Advertisers would love such a thing
Why? It doesn't give them any more info than they already have (the logged-in user!)
Re: Bearer tokens are just awful
#13> In theory you could just hand someone a randomly generated blob, but then you'd need to keep track of which blobs you've issued and when they should be expired and who they correspond to Is this so difficult?
It isn't until it is. And wherever you store it is a juicy target.
When will "until it is" kick in? It has never kicked in for me...
Re: Bearer tokens are just awful
#14> In theory you could just hand someone a randomly generated blob, but then you'd need to keep track of which blobs you've issued and when they should be expired and who they correspond to Is this so difficult?
These are just sessions (e.g. session cookies). The arguments against using database-stored sessions are generally brought up in the context of microservices or decentralized systems where that service/machine that keeps track of sessions becomes a bottleneck/single point of failure for a much larger system.
Re: Bearer tokens are just awful
#15So don't set the token to expire after the "heat death of the universe", make the user reauthenticate after an appropriate time for the service being used.
The problem is that you don't have control over what third parties are doing here. You may have control over the policies associated with tokens issued by your identity provider, but how do you audit the policies that third party services are applying to their tokens?
Re: Bearer tokens are just awful
#16Or you can put device/or ip related info baked into the token. That way when the user device or ip changes, you can invalidate the token.
> Or you can put device/or ip related info baked into the token. That way when the user device or ip changes, you can invalidate the token. yeah, I always wondered why there isn't a standard field in the JWT containing a fingerprint/hash of the client's machine/browser/etc.
How would that be verified? Any information the client sends to the server can be spoofed by another fake client. The stuff which can't be spoofed (say introduced by the network - IP address etc) can changed for legitimate clients (roaming between wifi and 4g for example)
Unless you use something like a "trusted" hardware module the client has no access too (which is mentioned in the article), but the article is still concerned with compromised machines.
Re: Bearer tokens are just awful
#17Is there a difference between that token and a password? Yes, the token is bigger and created by somebody else, yet for all practical means it walks like a password and quacks like a password...
Isn't the fundamental difference that a password needs checking against a stored per-user value such as password hash and therefore needs a database lookup, while a token can be validated through just the cryptographic signature and therefore avoids hitting the central database?
Re: Bearer tokens are just awful
#18Earlier quoted context omitted.
Advertisers would love such a thing
> Advertisers would love such a thing Why? It doesn't give them any more info than they already have (the logged-in user!)
It could be used to tie that logged in user to other web sessions that are currently anonymous.
Re: Bearer tokens are just awful
#19> In theory you could just hand someone a randomly generated blob, but then you'd need to keep track of which blobs you've issued and when they should be expired and who they correspond to Is this so difficult?
It isn't until it is. And wherever you store it is a juicy target.
Wouldn't you just store it in the same place you're storing the main authentication data (eg. password hashes)?
[edit] I guess that database would get hammered pretty hard on every request, unless you use caching... which might be what you're getting at.
Re: Bearer tokens are just awful
#20Or you can put device/or ip related info baked into the token. That way when the user device or ip changes, you can invalidate the token.
Device info is spoofable, and tying it to IP means the phone experience is just awful.
For sure, but then the user assume they know what they are doing. It is to prevent cookie hijacking.