Skip to content

Instantly share code, notes, and snippets.

@jfromaniello
Last active September 19, 2023 23:38
Show Gist options
  • Save jfromaniello/8418116 to your computer and use it in GitHub Desktop.
Save jfromaniello/8418116 to your computer and use it in GitHub Desktop.
Example of authenticating websockets with JWTs.
var WebSocketServer = require('ws').Server;
var wss = new WebSocketServer({port: 8080});
var jwt = require('jsonwebtoken');
/**
The way I like to work with 'ws' is to convert everything to an event if possible.
**/
function toEvent (message) {
try {
var event = JSON.parse(message);
this.emit(event.type, event.payload);
} catch(err) {
console.log('not an event' , err);
}
}
wss.on('connection', function(ws) {
ws.on('message', toEvent)
.on('authenticate', function (data) {
jwt.verify(data.token, options, function (err, decoded) {
//now is authenticated
});
});
ws.send('something');
});
@msafronov
Copy link

that code snippet has a lot of vulnerabilities:

  • you must check time of life of the token
  • you must check currently received user agent data with the same data, that you placed in token previously
  • you must store additional refresh token for auth token refreshing
  • you must minimize jwt.verify() operations (store token in special registry, in redis for example)
  • etc

@DmitryMyadzelets
Copy link

DmitryMyadzelets commented Mar 9, 2018

The toEvent approach is indeed cool. Some notes. The error message "not an event" is wrong. It should be "not an object" there. I'd suggest the following version, which allows us to process any data including strings. Assuming the payload is neither 0 or undefined it allows to handle the objects with wrong structure too:

function toEvent (message) {
  try {
    let {type, payload} = JSON.parse(message)
    this.emit(type, payload || message)
  } catch (ignore) {
    this.emit(undefined, message)
  }
}

This way any data other then event objects can be processed too:

ws.on('undefined', message => console.log(message))

Finally, you may need to check the type for reserved words, e.g. the message, and avoid using them.

@kanalasumant
Copy link

kanalasumant commented Jun 26, 2018

@kotoo great points. I've understood all of them, except for you must check currently received user agent data with the same data, that you placed in token previously. Could you explain a bit more and the thought process behind what this means. I thought we should be storing only the token. Do we need to store the user agent, req headers, etc.. too. Also you mentioned reducing jwt.verify() calls which I understand even though is asynchronous has to at some point perform it and is a definite bottleneck. But is it too costly. Doesn't jwt store al of it's token in memory. If not, then storing it in redis makes sense. Thank you!

@dissoc
Copy link

dissoc commented Jul 8, 2019

@kanalasumant I think the idea behind the user agent check is to help ensure that the websocket connection originates from the same source as the initial login. A single user can have multiple tokens (say token A for web, and token B for mobile). Let's say the user logs in the web app and is given token A. The request for token A also provided user agent info A. Now the web app uses token A to make the websocket connection. That websocket request will have the same user-agent info A in the headers and will help ensure that both requests originate from the same source application. This information can easily be spoofed but it would require an attacker to have access to the user agent info or try a bunch of user agents until a match occurs. You could possibly take action when a mismatch occurs (revoke or maybe after N mismatches lockout the user, or block login attempts from mismatch's IP+user combo) . These are my initial thoughts and I haven't implemented this but it will be on my todo list.

@ShejaEddy
Copy link

ShejaEddy commented Apr 24, 2020

that code snippet has a lot of vulnerabilities:

  • you must check time of life of the token
  • you must check currently received user agent data with the same data, that you placed in token previously
  • you must store additional refresh token for auth token refreshing
  • you must minimize jwt.verify() operations (store token in special registry, in redis for example)
  • etc

@msafronov, My question can be somehow silly but I was asking myself why do we have to store tokens from the client, why not authenticate his tokens each time he reconnects to the sockets, then we could reset ws.userId at each authentication. Save authenticated users in a static object like a client room or something after each authentication. So I don't get the point of why saving the token.

@OBorce
Copy link

OBorce commented Jul 15, 2020

@ShejaEddy probably something like the token can expire and the client can keep the connection open forever?

@ShejaEddy
Copy link

@OBorce u get my point, that's why what I do is only save the userId as key to users object then save the token as it's value. so that every time the user's token changes u'll know which token to update due to the saved userId.

@arashmad
Copy link

arashmad commented Dec 4, 2020

Is there any option to connect to a WebSocket through username and password authentication?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment