You are right that lots of web security protocols just use a "God Rights" key that allows any REST call to do anything. The more appropriate way is to have any "caller" of the remote service be required to have an RSA PKE key such that every call is done with some 'identity', and to each of these identities the system knows which privileges are allowed (which buildings are controllable, what things are able to be deleted, etc).
Of course going along with this architecture you can have the requester be required to do a PKE based digital signature of the request (to send along with the request, like in an HTTP header) so that the server side can also be certain the request did indeed originate from who it's supposed to have.
Having HTTPS makes some of this redundant, so the real key thing I'm saying here is:
1) Don't use tokens with God Rights
2) Make each user/role have the minimal privileges that it's required to have so that there's no way it can go rogue even if hacked.
You are right that lots of web security protocols just use a "God Rights" key that allows any REST call to do anything. The more appropriate way is to have any "caller" of the remote service be required to have an RSA PKE key such that every call is done with some 'identity', and to each of these identities the system knows which privileges are allowed (which buildings are controllable, what things are able to be deleted, etc).
Of course going along with this architecture you can have the requester be required to do a PKE based digital signature of the request (to send along with the request, like in an HTTP header) so that the server side can also be certain the request did indeed originate from who it's supposed to have.
Having HTTPS makes some of this redundant, so the real key thing I'm saying here is:
1) Don't use tokens with God Rights
2) Make each user/role have the minimal privileges that it's required to have so that there's no way it can go rogue even if hacked.
Totally agree.