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.
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.
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.