Any way to use a client ID & secret or other method to give 'generic' access to Javascript event stream

Cloud
1

I’m setting up a prototype for a customer where we’ll use a couple E Series in the field and I want to throw together a quick Google Maps tracker screen so the customer can watch where the devices are, and I can show some additional data from the event stream of these devices. I’m using the Javascript API, listening to the event stream and creating markers on the Google Map JS api. Everything is working great.

My challenge is to authenticate them to the event stream without embedding my Particle account into the javascript for the login, and as I understand, tokens will eventually expire so I can’t just hard code in a token.

Anyone know of a method to authenticate to a device or product event stream for the public, without having to embed a particle user login info or token (or set token expiration to infinity)? I was thinking something like the Client ID & secret but I don’t fully understand how that might play out, or if it’s even able to be used for such a scenario.

Thanks for any idea.
Jon

2

There are security risks for embedding an access token in things, but you need an access token in order to access the private SSE stream for an account.

However the expiration is not an issue because if you generate an access token, you can set expires_in to 0 so it will never expire.

https://docs.particle.io/reference/api/#generate-an-access-token

If you can keep the access token in your server code, using a non-expiring token is a good solution.

Unfortunately there’s no fine-grained access control, so you can’t make an access token only for the SSE stream. Once you have an access token it either has access to everything, or only has access to create claim codes. This makes it difficult to use from client-side code safely.

1 Like
3

Thanks Rick, we’ll have to think of a sneaky way to do this, but good to hear that we can generate the non-expiring token, I must have missed that in the reference.

It’s a very small demo, and we have access control on the server size on the Azure website, so I’m not overly concerned for this use case - but yeah, for any larger scale solution, it’d be more difficult to deal with… without building out a user mgmt system that is…

Thanks!