Alternate way to auth to streaming endpoint when sending headers is not available?

[desert ore]

👋 Just getting started with the api, transcribing pre-recorded works great! Looking at the wss streaming endpoint, noticed that authentication requires an http Authorization header to be sent with the web socket request. The web-standard WebSocket client (browsers and other standards-based server-side envs) do not have this ability. https://developer.mozilla.org/en-US/docs/Web/API/WebSocket

Can I pass my api token in another way? (e.g. query param or auth ws message)

Thanks!

[tulip garden]

I believe there is. Checking with the team 👍🏻

[desert ore]

thanks! It's a blocker for now (don't want to have to proxy through another process)

[tulip garden]

Ideally you'd proxy it to protect the key, if it's a client-side websocket. That's our official line about client auth. Unofficially, you can use your API key to create short lived keys for the purpose of connecting. Once a connection is open, you're fine until it drops. Don't tell anyone at Deepgram that I told you this.

I'll get back to you asap about alternative methods for sending credentials

[desert ore]

Unofficially, you can use your API key to create short lived keys for the purpose of connecting
This would be great - some other APIs I've seen have https endpoints to create and return wss endpoints with embedded short-lived tokens for exactly this reason, but I'll take whatever I can get! Some server-side WebSocket clients also follow the browser WebSocket client spec (like Deno, Cloudflare Workers), so it would be great to have a way to do it without sending any headers

[tulip garden]

Seems you can connect using

const socket = new WebSocket(URL, ['token', DG_API_TOKEN]);

🤔

Undocumented way to Auth to our websocket. Try it out

[desert ore]

That second param is an array, but , instead of : works! const socket = new WebSocket(URL, ['token', DG_API_TOKEN]);

Thank you!!

[tulip garden]

Phew, I wrote that on my phone 😅 thanks for trying it out!

[rigid orbit]

I ran into the same issue but I can't get the above solution to work. @desert ore what was the format that worked for you? Can you show me an example? Much appreciated.

[desert ore]

Luke's got it up there in the answer: the second arg to the standard WebSocket ctor is an array of length 2, with the string literal 'token' as the first item, and a deepgram api token as the second item.

[rigid orbit]

Hmmm, mine is failing, good to know that is the right format at least. I thought I might be missing something. Thank you.

[fleet python]

With respect to creating short lived api keys to provide to the client in order to open a websocket streaming connection, I found this document which lists various scopes but I was wondering which scope would be most appropriate for this use case? As there is not any description of what each scope allows (at least on this page):
https://developers.deepgram.com/docs/working-with-roles

[tulip garden]

usage:write is the only scope required for sending us data 🙂 so I would limit the scope for these short-lived keys to only this scope, and that should allow you to prevent that key from being used maliciously to do anything but pinch a few $ of credit - assuming they catch the key in the split second it's available

[ashen fog]

I too ran into the same problem. I made a simple webapp that uses deepgram. Users are meant to set their own deepgram token in the settings to pay for their own usage. I am forced to have a proxy now and it's costing me 1$ / day to run on AWS. If users could connect directly I would save on the cost. I will switch to the unofficial method now, hoping it won't be retired and get rid of the proxy.

[ashen fog]

wow latency is also much better without the proxy. I hope the unofficial way stays.