JWT in URL: option to send it within the socket connection
Opened this issue · 7 comments
My security department has a problem with sensitive data as part of URLs - here: the JWT.
Can you imagine requesting a channel by POSTing a JWT - or like postgrest : putting the JWT in a header instead (i. e. Authorization: Bearer)?
The security background probably is, the webserver logs (of my reverse proxy) contains URLs, thus currently contains sensitive data (the JWTs).
@fjf2002 unfortunately the websocket clients on browsers are very limited and AFAIK do not have any header capability. Check this discussion for more info.
It seems that the simplest solution in this case would be to apply some filter on the logs to remove the those URLs before persisting them.
I also advise short TTLs (a few minutes) for the tokens and some error handling that tries to get new tokens a few times.
We could have some option to send the token as the first message and move the auth to the websocket connection.
Ok, thanks for the clarification.
Just another idea: What about sending the token in-channel, i. e. as the first websocket message after connection, from the browser to the postgres-websockets?
@fjf2002 yes, that would work. It adds a bit of complexity to the code, and it could be easier for a malicious user to consume resources (since we would have to open the socket before authenticating). But this could be enabled by a configuration flag to avoid using this workflow in cases where it's not needed. I'll leave this issue open as an enhancement and see if anybody else will thumbs up this.
ok, thanks!
it could be easier for a malicious user to consume resources (since we would have to open the socket before authenticating).
You seem to mean the additional HTTP->Websocket "switching protocol" server reponse? The TCP socket must be open in each case.
Also the server thread that keeps the websocket session alive sos we can wait for the auth token.