devicehive-java-server
devicehive-java-server copied to clipboard
Device specific, revocable tokens
Refresh tokens seem to be linked to a specific user instead of device causing concerns regarding security of the platform.
A compromised refresh token would allow adding arbitrary devices and posting notifications under any device. Detecting such leak would require monitoring device list and all notifications for anomalous behavior. In addition, revoking access using the refresh token would require disabling the user account in question leading to following issues:
- Determining the affected user account does not seem immediately obvious.
- Keeping things sane would require maintaining separate user accounts for all devices.
- There does not seem to be a way to determine which device has to be reconfigured after a user account is disabled and recreated. Unless there is 1:1 user-device mapping using a consistent naming practice by the user.
It would seem sensible to tie device access to the device in question. This would entail allowing authentication with device id in JWT token payload.
Making the token device specific would greatly reduce risks posed by a compromised token and make it possible to temporarily shut down any notifications sent impersonating the device (by setting operation to blocked). As an added bonus a single token is used for only one device making it possible to implement some sort of revocable tokens. For example:
- Add an integer column to device table and set it to 0 by default
- Add the value of the new column to JWT payload
- Increment the value of the column to revoke the token
- Check that the current value of the column matches JWT payload