I am working on a vehicle renting system prototype. We are using Particle Electrons with asset tracker shield attached to all the vehicles in the fleet. We will have our own app server connecting to Particle cloud and a smartphone app that would talk to both our server and Particle cloud. This mobile app will be used by our customers to locate vehicles w.r.t. their location and rent it through the app. Once the renting starts, customer will be able to control certain aspects of the vehicle, e.g. locking/unlocking, trip location updates etc.
Ideally and as Particle recommends, communication between device and app should happen directly and not through our app server. The problem I am facing is with choosing a suitable auth. method. From documentation, I read about simple and two-legged auth. methods. Now both methods require that we attach a device with customers, whereas, the system we are developing is about renting vehicles and one customer can rent different vehicles from time to time. So to enable the app communicate directly with Particle cloud/device and be able to unclaim and claim another device is mandatory. Documentation does not talk about such a scenario. I am thinking about using two-legged auth. but do not want to permanently attach one device (in our case this means one vehicle) to one customer.
Now I read in forums that you can claim/unclaim devices through new APIs (not mentioned in docs though). I would like to know, if it is the right way to proceed, given the requirements of our project. I am thinking, when a customers rents a vehicle, we will claim corresponding device for that customer and once the renting ends, unclaim it from customer and claim it with a system user of ours. What you guys think?
First off, thank you for the thoughtful and complete description of the type of product you are working on. It always helps to have this level of detail when providing advice. As you picked up on, the current well-documented methods of authentication assume a more permanent 1:1 association of a device and an end-user (customer). This works well for many types of consumer products, but the architecture doesn’t make as much sense for use cases like yours (short term individual access to shared assets). From your description above, I see 2 potential paths forward:
Use customers, claim/unclaim devices frequently: You alluded to this method in your post. If you use our APIs to claim and unclaim a device to a customer in alignment with the rental sessions, this should provide access to your customers to a particular device when they need it (and revoke access once the vehicle returns to the shared pool). Each one of your end users would need a Particle customer account when registering for your service. Devices in your product would start as being unclaimed. When a rider starts a session, your back-end would trigger a device claim to that customer. For claiming a device, I would suggest using the POST /v1/devices API endpoint (docs), and using the customer’s access token to authenticate. Note that the device being claimed must be online and unclaimed for this claiming method to work as intended. This will claim the device to the customer, and allow their access tokens to control the device. When the rental session is over, you can unlcaim the device using DELETE /v1/devices/:deviceID. (docs). The electron would then return to the pool of unowned devices, ready for the next customer to start a session.
Leave devices unclaimed, manage auth on your end: In this approach, access and permissions would be controlled by your server, giving you more flexibility to implement the authentication approach that makes the most sense for you. Devices would be added to your product, but would remain in an unclaimed state. Your server would use an OAuth client and secret to generate access tokens that could control any device in your fleet. Your app would manage which end-users would have access to which devices at what time. For this to work, you’d have to use a modified version of two-legged authentication, in which your server would exchange client credentials for fleet-wide access tokens between your back-end and the Particle cloud.
It may be worth trying approach #1 before #2, as it would be less work on your end. Please let me know if this was helpful and if you try to implement either approach. It would be great to have you forge the path for products like this, so we can learn and document best practices. Next year, we are planning on expanding our access-control and authentication functionality. We will certainly consider this use case type as we think through how to make this easier for product creators like you in the future.
Thanks for a detailed response to my question. I understand the first method fully as I was thinking along the same lines, however, the second method that you described, I don’t fully understand some parts of it. I have few questions
1- Do I need to create shadow customers (for my end users) on particle cloud?
2- My server would have fleet-wide access_tokens to manage any device in the fleet, how would I constraint and delegate these access_tokens to my end users? My users would not have a corresponding particle cloud shadow customer and If I provide them these fleet-wide tokens, they would be able to access any device? For example, a hacker can get hold of this token (extract it from my app’s http responses) and get a list of devices in the product.
3- If all devices will remain in an unclaimed state, how my end users will be able to communicate with these devices directly using my web/mobile app? I am assuming here that you can call functions on the device or access exposed variable on the device only if the device is claimed.
In this case, there would be no customers you’d create. You’d exchange your product-level OAuth client and secret for tokens that could control any device in your fleet with the following API call: curl -u client_id:secret -d grant_type=client_credentials https://api.particle.io/oauth/token.
You would only generate access tokens and make API calls to the Particle cloud server-to-server, never in any client (web/mobile app). This would ensure that these access tokens would not be accessible to the outside world or used to control other devices.
Your web/mobile app would make calls to your server, which would then hit the Particle API. Your server would act as a proxy.
I will say that I just tested this approach out, and it looks like our API doesn’t seem to support it right now. I would recommend going with the short-term customer ownership model if possible.
Alright that makes it clear. I was thinking that you meant both methods would allow me to have my end user app communicate directly with particle cloud. This obviously is not possible.
If I understand properly, you mean APIs do not support commnicating with unclaimed devices using fleet-wide access tokens in server-to-server method that you described? correct me if I am wrong.
Using a proxy server did cross my mind. I was thinking to create a product and claim all devices under my own particle user account and then use my server as a proxy to communicate with all the devices. What do you think about this approach? I actually had raised a support ticket for this before I got your response to this thread post and @rickkas7 from Particle support team also suggested this method. Is there anything not supported in this method?
His reason not to use temporary claiming/unclaiming method was that claiming means transferring ownership and if customers own the device even for a session they will be able to gain complete control over the devices and can even flash the firmware on the devices.
Sorry, I was actually thinking about non-fleet claiming when I wrote about the ability to take control and re-flash the device. That doesn’t apply to devices that are part of a product; even if you have physical access to the device and re-flash it, it will go back to the product creator firmware when it reconnects to the cloud.
Alright so using the claim/unclaim method (temp. ownership) is a feasible option with the benefit of having the end user communicate directly to particle cloud bypassing my app server. Good stuff So I think we can still call it a slightly modified version of Two Legged Auth. where devices are claimed per session and remain unclaimed when not in a session. I have to now put it into practice, so far it is looking good on paper
Awesome, glad to hear it @noumanh. Please keep us informed on your progress. We will re-examining how we do authentication in Q1 of next year, and will keep your use case in mind.
So I think we can still call it a slightly modified version of Two Legged Auth. where devices are claimed per session and remain unclaimed when not in a session. I have to now put it into practice, so far it is looking good on paper