Authorization. Token verification. about reverb

[joedixon]

Hey @Doclassif, can you elaborate on why you think that might be unreliable?

[Doclassif]

Hi @joedixon, it seems to me that anything can be hacked and stolen, including keys, application IDs, and so on. Authenticating the client on the rewerb side would make it more secure to identify the user ID of a token "generated on the other side" (e.g. in the same keycloak).

[joedixon]

@Doclassif, still not 100% sure I'm following how keys can be stolen. Could you give me an example just so we're on the same page?

[Doclassif]

@joedixon, it's very simple: take the developer hostage =). Human factor, somewhere they didn't keep track and a vulnerability appeared in the cluster, somewhere they just didn't protect it properly and so on. I realize that the solution may be redundant and I am exaggerating everything very much, but still just want to know the point of view of professionals and parents of the project.

[joedixon]

Reverb is implemented with the Pusher protocol. It's possible to join public channels without auth, but private and presence channels have to be authorized first before being allowed to join. We also have support for encrypted channels if you need end to end encryption.

[Doclassif]

@joedixon, I've heard all I need to hear, thank you.