The Websockets protocol currently does not support authentication.
I assumed we could use HTTP headers in the initial request, and although the WebSockets spec allows it, browsers don't have it implemented. We can't use HTTP headers in the initial request.
Some companies use tokens in query parameters in the request URL. Others use a custom websocket message. Not sure what is preferable.
In any case, Atomic Data authentication assumes that there is no shared state / token between client and server. Clients have a private key, and can sign things. Typically they sign the URL of the requested resource + some timestamp.
That's why we need:
The Agent Subject
The Public Key of the agent
The requested subject
The timestamp of the signature
The signature
We could encode these 4 fields either in a custom WebSocket message, or in 4 query parameters.
I don't really like either approach, to be honest, especially since we're already using HTTP headers. This feels like another way to encode the same data.
Using a JSON-AD object
Let's say we define some JSON object, that looks like this:
And we use re-use this JSON object in various cases. We would include it as a Base64 object in HTTP requests. We could send it over WebSockets. We could post it to some /token endpoint and get a JWT.
The Websockets protocol currently does not support authentication.
I assumed we could use HTTP headers in the initial request, and although the WebSockets spec allows it, browsers don't have it implemented. We can't use HTTP headers in the initial request.
Some companies use tokens in query parameters in the request URL. Others use a custom websocket message. Not sure what is preferable.
In any case, Atomic Data authentication assumes that there is no shared state / token between client and server. Clients have a private key, and can sign things. Typically they sign the URL of the requested resource + some timestamp.
That's why we need:
We could encode these 4 fields either in a custom WebSocket message, or in 4 query parameters.
I don't really like either approach, to be honest, especially since we're already using HTTP headers. This feels like another way to encode the same data.
Using a JSON-AD object
Let's say we define some JSON object, that looks like this:
And we use re-use this JSON object in various cases. We would include it as a Base64 object in HTTP requests. We could send it over WebSockets. We could post it to some
/tokenendpoint and get a JWT.And the best is: it's still atomic data!
Relates to #49