https://livekit.io logo
Join Slack
Powered by
This message was deleted.
# helpdesk
s
This message was deleted.
m
livekit-server exposes a websocket endpoint. This is what you pass to LK client SDKs, which establish a signaling connection to your server. You can interact with the server in some fashion from three different places: 1) a client SDK 2) cli 3) server SDK. Each allows for a different set of capabilities.
Tokens are not generated by calling a livekit-server http endpoint. Instead, you should integrate a server SDK into your own backend. You should expose an http endpoint which authenticates your user however you see fit and then uses our SDK to generate a room token.
🙌 1
g
The reason why you would have an own http endpoint which integrates the server SKD is: so that not ANYone can just join rooms and subscribe to tracks? If I don't mind THIS is it ok to not use the server sdk but let the user from clients directly authenticate and join rooms?
m
This is correct, it’s this way primarily for security. If you don’t mind this, you could sign tokens yourself from the client using the APP ID and secret, but you’d have to port in the signing code from our server SDK. Is there a particular reason that setting up a server endpoint is difficult for you?
g
It is just another layer, which I thought is not needed and the "security reason" is for me not 100% clear yet.. since when you have an open website (online chat) where everyone can join and subscribe - it should be ok (when it is labeld as such: hey everyone who knows the room name can see your stream)
"you’d have to port in the signing code from our server SDK." and now with this info, it looks like to omit the server sdk is even more work
m
In your case, the problem is someone could take your API key + secret and use it to generate tokens to be used in any other application. All of that usage would consume your resources and either potentially DDoS your server (self-hosted) or have you paying the bill (cloud).
👀 1
The authentication mechanism we enforce here with server-side token generation is a pretty common security model to protect against situations like the above.
🙌 1
g
jwt, yes yes
m
Does it make sense why authentication is needed even for your particular application?
g
yes I think so. that it is possible to make join requests even from other software was the "aha" moment. but maybe just this could have been integrated into the core server; "allow requests only from defined domains"
no cross origin requests to the core server
m
How do you enforce no cross-origin requests from non-browser clients?
g
is cross-origin just a browser thing? hmm I mean the backend (core server) could check the request header and it will see if it was done from a browser and from a specific domain right? I need to understand this hehe sorry hmm
a backend is browser/client agnostic.. so the backend can refuse requests from the client (in this case a browser with a website with specific domain)
so the backend knows: IsItFromMyWebsit:boolean
m
Yes, cross-origin requests can be spoofed. The browser enforces this through its security model, but there’s no foolproof way to determine the origin of a request without key signing.
That’s what we effectively do via JWT tokens. Determine the origin of a connection request, in a way that works across all client types.
🙌 1
g
so if this can be spoofed.. why should my custom server (that one which I need to have between the client and the livekit core server) not be spoofed as well?
m
Because you are using a key/secret that we agree upon.
g
aha because I need to have additional logic.. authentications and so on hmm
👌 1
ok ok sloooowly I am getting there 😄 hehe
m
This is why you don’t want to share/leak your key and secret
g
thanks a lot for your time!
👍 1
🙌 1
I saw you are the cofounder - what a nice software you guys created! wow! ❤️
🙏 1
❤️ 1
Open in Slack
PreviousNext
Powered by