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.
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.
Another thing, it's mentioned that we don't control how tokens are created by some third-party, but still, we can use something like Keycloak with external identity provider and client in this case would use token from our Keycloak. In that case we can ensure that for our purposes token will expire quickly.
Overall, hardware-backed identity is probably viable in enterprise scenarios where you don't have the same expectation that company-owned hardware will respect your privacy, and we don't have a great solution for doing it at consumer level, and that probably impairs our ability to offer any sort of browser-level API for it.
I'm obviously not understanding how bearer tokens work (another user downthread also contends that fingerprint will work, so I'm pretty certain at this point that I have the wrong mental model).
My understanding is as follows:
1. Client logs into gmail/google/facebook/wherever, and gets a signed token-generating-token.
2. Client goes to legit SiteA. SiteA has no access to the token-generating-token granted in #1 above.
3. SiteA pops up "continue with google/fb/etc" and user clicks "continue", at which point google/fb/etc gets a request for a new token using the TGT to authenticate the user.
4. The final-token is returned to the client, and can be sent to SiteA by the client as proof of identity.
5. SiteA can verify final-token with google/fb/etc.
My question is, why can't the token-generating-token (TGT) embed the hashed fingerprint[1], which is generated by the issuing server, and will never be seen by SiteA?
The final-token can use that hash as added entropy into the salt used for the key that signs final-token, because the issuing server will have the fingerprint-hash that allows it to check the signature of any final-token relayed to it.
[1] Browser-fingerprinting may not be totally unique, but it should be good enough (so, you don't include the IP, but the issuing server can figure out what country it is and use that instead.)
The threat is someone with momentary access to the client machine (either in person or via another exploit) can clone the data.
The server has many things to use for a browser hash, including some stuff that doesn't change very often (you would have to exclude things like screen resolution if you didn't want to reauthenticate your laptop everytime you unplug from a dock for example), but they are all based on information sent by the browser, and thus can be cloned by a process running on the client's machine (even including any Elastic Curve magic ciphers which would be pullable from memory)
The only things that couldn't be cloned would be things not sent by the machine, but instead generated by the network -- IP address etc (network spoofing being a completely different attack, although quite easy to do from a coffee shop)
However using that data would be awful as a workflow as many people will change IP address on a frequent basis
The problem is that with many services, the compromise of a client machine can get a token that never expires. The solution is for the service to require reauthentication periodically.
the client never sees the final token, unless the SiteA returns the token to the client, or the exchange of the code happens on the client side. in both cases these are the definitions of incorrect implementation, as the exchange should take place in the backend.
in most implementation you can/should send additional parameters like `nonce` or `state`, which can/should be used to protect against reply/forgery attacks.
Good that you brought it up. That's why I still bake my own verification session system.
Why? It doesn't give them any more info than they already have (the logged-in user!)
If those other sessions are anonymous, why do they have the token?
See, I'm not very experienced in web-dev, and I'm very much aware that I may not know what I am talking about.
I'm just trying to understand how the tracking data in the bearer token will "leak". Can you give me a scenario, like "Client goes to SiteA, is then redirected to login on SiteB which grants the token, and then goes to SiteC which reads the token".
For all you need to identify but you don not want them to be linkable to each other or your government-issued ID.
This is part of why relying on phone number validation for gatekeeping is an issue. (Try registering at Discord or Twitter via tor. I'll wait)