Token binding is a mechanism where the client sends an signed token to the server. Because this token is based on a private key it is harder to steal than session cookies. What I don't understand is how the token binding token works together with session cookies.

The token binding intent to implement says:

With token binding, the cookie acts much like a certificate issued to the client (as opposed to a session credential), while the token-binding private key becomes the actual session credential.

Is it possible to use the signed token provided by token binding as the session token? Would you still need a cookie in that case? What does it mean that the cookie acts like a certificate?

Edit: the intent to implement no longer says this.


As far as I understand it, token binding can be used to identify user using a certificate without need of PKI. How it works:

Client generates a key-pair, certificate locally, without need of signing server. Then once it connect to the HTTPS server it signs the tls_unique value (sent by server during tls handshake) using the generated private key then it "builds" the token consisting of the signed tls_unique and the public key. This information is added to HTTP request as Token-Binding header. Additionally, for the first time, the HTTP request includes some kind of another authentication info such as username/password. This bunch of data is sent to the server. Server validates the credentials passed and if it is correct it stores the token binding (mainly the certificate) locally for further authentication. Additionally, it generates the token which can store whatever info but it also stores the public key which's private key was used to sign the binding request. This token is bound to the given certificate and uniquely identifies given user. And this token is delivered back to client using a cookie.

During other requests, no credentials are need as server already has the user certificate bound to the token generated. Client sends the token together with another signed tls_unique value, server checks the token in cookie together with the Binding-Token info and if it knows the user (token is valid) and the certificate presented is the same as previous the authentication is done.

In this case, I would say the token is sent by cookie just because it is well known mechanism which can be done completely automatically and the cookie is quiet well protected. But please note, the token can be delivered to both sides in any other way, i.e. in GET request (http://service.domain/?token=...). This is used especially for federation services because passing cookies cross domain would not work.

What about sessions?. Although this token can also be used to identify the session I would not mix it up. The token is primarily used for authentication while session is used to keep some information about the stateless session during some amount of time. I would use separate session ID for every new session the user would open. This is just my personal feeling and I can't exactly explain why. Definitely, it is not necessary to store authentication info in session anymore as it will be passed with every new request separately in headers (Token-Binding/Cookie) pair ;)

Just to finish it. I would not say the cookie, but rather the token (it can be sent by cookie or by GET/POST request / or data) really servers as client certificate used to authenticate you, moreover without need of PKI. Because you pass your certificate in token together with a data encrypted (signed) using your private-key server. Then server uses it to authenticate you.

  • 1
    Looks like token binding is a method to eliminate the man-in-the-middle attack scenario that JWT doesn't handle natively. May 29 '17 at 19:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.