Return token in devices queries for `owner` and `admins`
oscgonfer opened this issue · 4 comments
Another improvement that would help in certain current projects and the front-end, similar to #287 and aligned with #246
It would be good to return the device token for authenticated requests (device owner can see their own token) or authorised (admin can see all tokens).
This, aligned with #287 , would help in the front-end, but also to do the forwarding schemas in external services, as we are planning them now. In this particular case, would help with the device token->device id mapping, so that we can forward mqtt messages to other platforms. Currently, we would need to know the device token before hand, as the API doesn't expose it (even if it allows for searching devices by token for admins)
Initially, we tried to prevent exposing the token to users as little as possible. However, let's prioritise convenience.
Overall, let's find a way to improve the security in the mid-term by adding a secondary, more extended token. That could be manually entered by the user or exchanged periodically between the platform and the device, a temporary or ephemeral key. Anyway, that's for another security and cryptography issue that might require a benchmark of existing solutions.
OK. So as far as I see, an authenticated and authorized request would be in any case safe (in the absence of bugs, obviously).
For users: Currently we do not have a way to expose the token via the API, so it makes the users always go to the device (not a bad thing for security) or to us, in case they lose it (bad for us). Maybe having it in the API is already a way to facilitate things, and we see if we trust the front-end to handle it properly.
For us: I am thinking of ways that make better use of the MQTT Bridging capabilities to avoid going through the API or PUSH for having the data sent elsewhere (which now is required in 3 out 3 big projects we are on). By using a bridge via the broker, we reduce the load on the API, and we can forward data near real-time as a standard for people interested, under very controlled conditions with flows. Now, to avoid exposing the token there, we need then to map token->device and forward it that way. People would need to map sensor_id still, but that's a minor load.
This whole thing started because of this last issue, but I can't see any risk to do it. Understanding that the token (for now) is a private key to send MQTT data, and that (for now) we work via 1883, I would say that steps moving forward for a more secure mechanism would be:
- Move to 8883 on the devices (already supported on the broker)
- Rethink token if needed as per your comment
But that:
- Expose token in API to
ownersandadminsfor convenience (if you all agree)
Would be good to have.
Now that you mention MQTT and Auth. Don't forget in the future could move this to the broker.
i.e. rails could populate a PG table EMQTT will check to allow devices to publish or consume data
https://www.emqx.io/docs/en/latest/access-control/authz/postgresql.html