Byrd — Chat & Sockets — Authentication

That was quite a task, to get this going. I even had a serious problem with getting git commits separated from each other, so I ended up committing it all together.

Introduction

As I mentioned earlier, I was arguing with myself on using either WebSockets which I am familiar with, or FireBase, which I got little idea of, but that’d shorten my development time, and would give me alot of performance advantages. Right. It would.

But finally, I decided to go with WebSockets — on top of Socket.IO. Decision was pretty simple, I’ve used WS before, and as I’m pretty limited if goes about time I can spend on this project — that was the easiest solution.

Doubts…

I was fighting with the thought of going the simplest way — not adding any sort of authentication here, except the agents, as this chat module would be used by the visitors. But the truth is — that wouldn’t be a good idea, as literally anybody would have access to every single chat out there. That could lead to abuse.

Of course, agents do need to authenticate, as they pay the key role on the platform. I’m not building a simple chat, I’m building a helpdesk system. Since agents already are being authenticated with use of Tokens — there was no doubt I’m gonna have to use them as well for that purpose. And since I’m going have to use them for agent auth — clear is, they’d have to use used for guests as well.

Solution

So I came up with using tokens for all the users out there. But the guest has to get the token somehow, and since he’s not authenticated with login form, I decided to generate a guest token, on every, single chat initiation.

Returned token is afterwards passed within a query string. The beauty of JWT gives me possibility to store data inside of it — so I took advantage of it, and I pass Chat result along with it. This helps me to save some time, as well as database performance.

You could also notice type key/value, being passed within the token. That helps me to verify whether the user is an agent or a guest, so I can split the auh process. Again — this is safe practice, as token is signed, so nobody will be able to successfully fake the token, without access to my secret.