zelloptt / zello-channel-api

WebSocket-based API and SDKs to connect to Zello channels (BETA)
MIT License
85 stars 34 forks source link

Authentication Best Practices #11

Closed tompierce closed 5 years ago

tompierce commented 6 years ago

Hi Guys, Thanks for the quick turn-around on the JS SDK - It's looking good!

I had a query RE: Authenticating:

When you create the ZCC.Session object, you provide it with the address for the Zello server, your authentication token, the name of the channel you are connecting to, and optionally a username and password.

In what cases is the username & password optional? In my testing I have to supply it. Am I missing a method of generating an auth token which includes the username and password? I'm hoping that is the case, because we'd rather not store zello credentials if we can help it.

If that is the case, could you provide some guidance on what that looks like?

Thanks in advance, Tom

megamk commented 6 years ago

Hello @tompierce thank you for your feedback!

authToken is used for authentication, and you need to provide it always, no matter if you're providing username and password to connect to a channel or not. Here is the doc on how to generate tokens.

If no username parameter is set in the parameters object session will try to connect to a channel in anonymous mode. Anonymous users won't be able to start outgoing messages. Anonymous access support is there for ZelloWork channels and will be added to public zello channels soon with an option for channel owners to enable or disable anonymous access to their channels.

tompierce commented 6 years ago

Thanks for the prompt response @megamk.

Does the JS SDK support any sort of session refresh? We are trying to avoid having to store Zello credentials, as this poses an increased security risk. Are there plans to add OAuth, or similar, support? Then we could authenticate once, and use a revokable token for future authentications.

tompierce commented 6 years ago

We're starting work on a basic integration using the JS SDK. Could you confirm that this is the expected login flow:

Could we store the username and password in the JWT payload of the auth_token? That would allow us to just store the token, which has the benefits of being expirable and encrypted.