This is a feature request. I need a secure side channel with open ai to enable secure billing. I believe I want an API endpoint or callback from open AI for token-use (or better USD cost) per OpenAI ephemeral key.
I have a web application that uses the realtime api. I want to launch it in beta mode soon but I have billing security concerns.
I’m currently grabbing the token usage in from the response.done event and posting that to my billing endpoint.
Even with CSP, SRI and js obfuscation, it’ll be relatively trivial for a client to disable or tamper with my billing API calls.
Is there a server side way to get per user session costs? What are other people doing? Maybe my brain isn’t working.
Is the app in the client making direct API requests to OpenAI? Is that why you think he may tamper the data?
If so, that is a severe security breach.
You should have your own server do the api calls and act as a proxy so the client never sees your API responses, only streaming the audio and text with your own protocol.
The client negotiates an ephemeral api-token from my server, however the usage-tokens comes back on the webrtc data channel on the client side. I post this usage information back to my server for billing. I can’t see how I can prevent the client from tampering. I haven’t played with SRI (Sub Resource Integrity) but it only sounds like a partial solution. There is nothing stopping the client from amending state to /dev/null the billing endpoint.
I can see in the billing dashboard some reference to users so I’m wondering if I can create user instances within openai, kind of like projects and then do server side calls to the cost api instead for each user. I can’t find any doco on this though. I think it might be a feature request.
Perhaps there is a way to secure the transmission of usage info to the server in a way clients can’t meddle with. I’ve thrashed this out with my peers and AI advisors, and I can’t see it. I’m curious what others are doing?
WebRTC: basically flawed thinking the way it is done, suggesting direct consumption by an untrusted client.
How do you prevent reuse of a “have this token, and go nuts using my account until it expires”? Never mind that you are trying to bill that usage. That is a quickly surfaced and unanswered concern you will find in the forum.
Hmm this was my concern. Glad to know others share my thinking. The realtime api is still in beta for a reason. It ain’t ready I suppose. I might experiment with invite only mode, and just self insure against clever customers.