What's the scenario exactly? Based on what you wrote I'm guessing: All users publish to the same stream, and anyone can become a user by installing the add-on (there's no pre-approval process, anyone can join)? So effectively the stream must be publicly writable.
There's a few options which come to mind to approach this:
1) Anonymous keys
Use a stream-specific ("anonymous") API key. Unlike user API keys, which you must guard closely as they grant the holder permission to act on your behalf, the anonymous keys don't grant the holder any other permissions than the ability to write to the stream (and read from it). These keys can be created and revoked on the stream page. Such a key could be bundled with the add-on, which doesn't really make things less secure as the stream is intended to be publicly writable.
2) Granting permissions per user
In this option, each end user would become a Streamr user so that the permission to write to the stream can be granted to them individually. Going through the usual Streamr registration (email validation, choosing passwords etc.) is too cumbersome, but the new Ethereum-based identity and authentication feature can solve this by enabling an automated signup process inteded for apps and machines (and why not people too).
So basically you generate an Ethereum private key (=essentially a random number), then go through a simple challenge-response protocol to instantaneously sign up/log in. The Ethereum authentication is a brand new feature which isn't really even announced yet, but a blog post about it is ready and will be published shortly, and support for it is already in the JS client library.
Now that the end user has a Streamr identity (which equals their Ethereum identity), you as the stream owner can grant that identity a permission to write to the stream.
In this solution there's no shared access key anywhere, so from some point of view it's more secure, and access can be managed per individual, but it will also require you to run some backend which will grant the individual user access upon them requesting it. Also note that the practical security level isn't really changed at all, since at the end of the day, anyone can get trivially get write access to your stream, which is what you want.
3) Stream per user
Instead of a shared stream to which everyone writes, you could have users sign up using the Ethereum process as above, create an individual stream for themselves, and then grant you read access to that stream.
In this model, you'd need to a process that combines the data from each of those individual streams to a firehose stream, if that's the end result you're after.
Hope this helps - I'd go with option 1 if possible as it's the simplest. We're happy to assist further as needed!