Client-side tokens?

[iamnafets]

Is there a way to generate signed requests/sessions to Deepgram? I'm using the streaming transcription endpoint via a bounce to our servers which adds N ms of latency and requires me to maintain sessions that I'd prefer not to.

Can I:

1. Create temporary API keys and have them expire in an hour?
2. Create a signed endpoint which bills to my account?
3. Something else?

[jcdyer]

Yes. API keys can be set to expire. If you create one in the console.deepgram.com UI, you'll see an option to set an expiration. In this screenshot, it's set to 15 minutes:

Similarly, if you're creating an api key using the API, you can either set an expiration_date or a time_to_live_in_seconds, as described here: https://developers.deepgram.com/reference/create-key

[coreyward]

+1 on being able to connect directly from the browser. I am working on a project for a client and having to set up a CloudFlare Worker just to act as a proxy to allow streaming audio to Deepgram since Deepgram doesn't allow this and Vercel doesn't support websockets.

[iamnafets]

Was able to get this working by passing in the token as a protocol. Unfortunately, I had to completely fork the DeepGram client as it imports a bunch of libraries which won't run on the client.

So should work with a bit of effort.

[Mijawel]

@iamnafets any chance u can share a link to the fork? trying to replicate the same thing

[iamnafets]

https://gist.github.com/iamnafets/c4ea02ae06463ae288f1e62490b69008

This code is in prod but I don't remember touching any of it so I can't speak to it's validity. I may have selectively pruned functionality that I don't use.

[lukeocodes]

We're working on a rebuild of our Node SDK (to become the JavaScript SDK) to be isomorphic. I can't speak for the existing SDKs dependencies, but I'm sure it has nothing that it doesn't need 👀😇

[lukeocodes]

Currently, officially, we do not have a solution for client-side tokens.

Our recommendation is to use a proxy service of your own, to mask the API key in requests you make to our API. This should essentially act as a middleman to add the token to the request, and forward on the replies to the client. You can then define your own Auth between the proxy and your client, to prevent unauthenticated users from making API calls - or not, that is up to you.

While we have the option (as Chris points out) of short-lived tokens, our recommendation will always be to never expose an API key in the client.

[coreyward]

For what it's worth, proxying is a non-viable option for many users since streaming requests require websockets and popular deployment infrastructure like AWS Lambda does not support websockets.

[augustnmonteiro]

Cloudflare workers now support websockets.

[coreyward]

Cloudflare workers don't run Node, though, and last I checked the Deepgram SDK required Node. This means you would need to write your own implementation for the websocket connection to Deepgram.

[acidbubbles]

So, that's what we ended up doing but as @coreyward said, it requires a completely different infrastructure from what's needed for other use cases, we have to deal with both the incoming and outgoing connections having potential networking issues, and we have to "reverse-engineer" the protocol to replace our own app API keys with the deepgram API key in our proxy. This adds costs, latency, and complexity.

As was suggested before, what I would greatly prefer is if we were able to sign short-lived tokens that could be used by the end-user to connect directly to Deepgram. Something like:

1. The user connects to our service using their authenticated user, and after validating their authentication, we connect to deepgram with our deepgram secret and request a token.
2. We return the token to the user, who can then connect directly to deepgram with it (they use it instead of the deepgram secret)
3. Since that token is short-lived, we need to renew it once in a while, that would go through the same path
4. Finally we need to be able to track usage, e.g. by querying the Deepgram API with some "user ID" we would specify when creating the token

Another option is to provide a NuGet (for C# at least) that you maintain that provides the mechanism to do the forwarding and authentication of connections, to avoid having all customers re-implement the logic.

I understand the complexity for Deepgram, however I was surprised since I'd expect any service offering STT using Deepgram to require the exact same thing.

Any feedback on this would be greatly welcome!