Customer authentication options


#21

To your first question:

I am suggesting that a master access token to control all product devices is likely not possible I don’t believe an access token generated via OAuth client credentials without a customer scope would allow you to call functions / check variables on devices (This endpoint is documented here, you’d just leave out the scope).

We do this as a security measure to avoid a compromised token giving access to an entire fleet of devices. Using customers allows you to generate customer-scoped access tokens which do have the rights to call functions and check variables on devices belonging to the customer (i.e. a small subset of the fleet).

The only way for a master access token to be possible is to claim all devices to the same account (user account or customer account). That way, any access token generated for that account would have access to do anything and everything on devices in the fleet. We have had product creators take this approach.

With this approach, what you gain in flexibility and control you lose in security. That single access token would have tremendous power, and, if compromised, could leave you in a bad situation. You would have to be sure that you would never use this access token in a client-side application like a mobile or web application, or expose it anywhere outside your server.

To your second question:

Shadow customers were built with the assumption of using an email as the username. However, as long as you are not using the customer password resetting functionality exposed by the console, I can’t think of a reason why using a UUID would be a problem.

Hope this all makes sense.


#22

Hey @G65434_2,

Just want to circle back on this. There are some newly documented API endpoints that you could use to avoid having to use customers, leaving your devices unclaimed. These are product-specific endpoints for calling functions/checking variables on devices in the fleet that you can authenticate using an access token from a product team member or generated by a product OAuth client/secret.

Check out https://docs.particle.io/reference/api/#get-a-variable-value and https://docs.particle.io/reference/api/#call-a-function. Specifically, there are examples of how to use the product-specific endpoints for functions/variables.

This should allow you to fully wrap the device interactions using your back-end, avoiding the need for customers.


#23

That’s great to know thanks @jeiden

At the moment I’ve just claimed all devices to my account (that owns the product) and I’m calling functions using the access token for my account.

Although I understand the security concerns as addressed in your previous post, I’ve personally found this far easier than managing customers through the Particle system, so it’s good to know that Particle is facilitating this use case.

I’m hoping to do a thorough write up of our system over the next few weeks to help out anyone else that is making the same decisions etc. so will follow up soon :slight_smile: