I have to respectfully ask, why is there no authentication what so ever on the http api beyond use of the device’s auth token which, in this case, is basically just an ID for the device?
[EDIT] the above seems to be a in direct contradiction to: “* Granular permissions allow you to manage who and how can see your devices and their data” here: Security - Blynk Documentation
There’s actually no control over that using any permissions if someone simple knows the devices ID (The token) if you’re not actually validating who’s access the device…
Someone could get fired from a company, retain an ID and the only way the company could prevent them from accessing the device would be to re-provision it or otherwise generate a new token.
Hello. In general, you’re right. Device OAuth token is like a password to your account, but for the device.
Device HTTPS API uses it and that’s not the most secured way to provide the access to the device. However, this way is super simple and straightforward. And for Blynk simplicity is one of the main features. So we’ll keep this API for sure.
In fact, we do already have some parts OAuth 2. And we gonna implement the new API soon for device/org/users management with OAuth 2 flow.
@Dmitriy do you have a timeline for the new/additional API with OAuth 2?
I am looking at working with IFTTT for an easy option for customers and from my (extremely limited!) understanding it looks like OAuth 2 is probably required.
Thanks!
EDIT: Actually, maybe I should ask if there is any plan to add a webhook function to the automations? If so I probably wouldn’t have to worry about this at all!
@Dmitriy Is there a more secure set of options for api access, authentication and/or authorization with a business server? An ip whitelist would be better than nothing.
For the WL clients, we can do everything, for example, we can turn off the HTTPS API access, so you would be able to access the device only when logged
For PRO users we probably should add an option to allow/disable device access via token
I just thought I’d come back and check in on this original thread. Any update on the possibility of adding webhooks to automations? That would really be a great addition/solution for us.