Apart from the fact that TLS doesn’t have “connection context” variables, is there any reason why this couldn’t be technically built into the standard for something like JWT?
Why it is needed
When a browser sends multiple requests to the same API server, it resends the JWT in the header multiple times. This means additional data overhead, and each time, the server needs to verify the JWT.
I would like to see the TLS standard include “connection bound context variables” so that JWTs can be sent once and used across multiple HTTP REQUESTS over that TLS connection.
How it could work
1) The client connects to the server, and a TLS encrypted session is established.
2) The client send the JWT to the server-side – there are two options for this:
A) The client can send connection variables directly on the TLS layer. The client sets the variable on the client side, and TLS sends the data to the server side. The variable name from the client is always prefixed with “CLIENT-“.
B) The client sends a HTTP request over the TLS session to a specific endpoint dedicated for use to set a TLS variable /api/setJWT. The client sends the JWT as a POST. The server reads the JWT, verifies it, and then sets it to the TLS connection context.
[B] would work best, because client software would be harder to change (browsers).
On the serverside, the encapsulating TLS object’s ITLSConnectionContext interface is made available from HTTP REQUEST handlers. The ITLSConnectionContext has three functions, string ListVariables(), string GetVariable(name), SetVariable(name, string).
Assuming 2B is used, when GetVariable(“JWT”) is successful, it can be assumed that it’s valid.
How it could work without changing TLS standard
If a particular TLS connection between the server and the client has a secure identity, then the application-layer can link that to a simple dictionary lookup. Perhaps this could be a GUID (as well as the client-side IPAddress-Port tuple). This GUID approach would mean each language framework can natively implement the lookup, and that makes other benefits possible, where native memory objects can also be linked, not just platform-independent strings.
Furthermore, the server might variables on the context for other purposes:
1) A database PK for the Person behind the JWT, PersonID. It might be a stream interface 2) A particular stream (TCP connection) to another resource 3) A file lock to a user-related logging file
The web would be better.
But am I wrong? Am I missing something that would make this unworkable and insecure?