I'm building a JSON API. For authentication I plan to use a random-token based approach, with the random token having 256 bits of entropy and generated using a CSRNG. A hash of the token will be stored in server-side in the database. For most clients, I will send the authentication token to them in an
Authorization header. All communction will be over HTTPS.
The general pattern that I plan to implement is described in the first part of this SO answer.
The solution seems to be to send the authentication token to the client in a HttpOnly cookie, AND also implement a Synchronizer Token Pattern where we generate an additional token that is sent to the client in a header when they first authenticate. The client can store this additional token in local storage, and pass it back to the API in a header with subsequent requests.
Reasonable enough. But what I would like to understand is whether there is any risk in not generating a new additional token to implement the Synchronizer Token Pattern, and instead just splitting the original 256-bit authentication token so that the client receives half of it in a HttpOnly cookie, and half of it in an header that they can keep in local storage? The API server then reconstructs the full authentication token when receiving the request.
Granted, if one of the halves was exposed, there would only be 128-bits of entropy remaining for an attacker to guess (but I think that is probably still sufficiently difficult).
Otherwise, does this achieve essentially the same thing from a security point of view? Are there any subtleties that I'm missing here?