add device authentication about simpleiot

[kdsch]

@cbrake After some preliminary research on JWT and getting familiar with the codebase, I'd like some clarification of the requirements.

It seems to be to create a notion of device identity with which we could, for instance, perform authorization (but authorization is out of scope). The JWT carries this identity, and will accompany every HTTP request against the backend. The server will associate JWTs with devices (presumably via bolthold?), and so any incoming HTTP request lacking a valid JWT header will be rejected.

This rejection could happen regardless of the request, so at the rootmost levels of the HTTP handler tree. Or, if we want something more like authorization, it could be happening at lower levels, with more complex logic.

I would assume that authorization is eventually needed to prevent a known device from modifying parts of the DB it should not be touching.

Does this sound right?

[cbrake]

Things we want to prevent:

• random people/bots spamming the system and filling database with crud
• fake data coming in for an existing device

I think when a device is provisioned, we store something on the server and device that has to match or authenticate for subsequent transactions to succeed.

This all gets pretty complex, so we probably want to start as simple as possible to accomplish the above goal.

I'm not sure what levels it should happen yet ...

[kdsch]

It sounds like you are describing API keys, so I looked into that. I found this article somewhat informative, although it feels like it's trying to sell me something:

https://nordicapis.com/why-api-keys-are-not-enough/

The main points:

• API keys provide identification,
• but not proof of authenticity, and
• are difficult to use with fine-grained access control.

Given that we assume SSL, that at least prevents the keys from being sniffed in transit.

[cbrake]

above article about API keys is interesting. I think the main production use cases for device->cloud communication (at least with cellular) will be CoAP, so I would be inclined to do something like a simple API key for the HTTP REST device API to provide some protection, yet keep them for demo and simple use cases (pushing data from scripts, etc). After learning a bit more about JWT during the user auth exercise, I think an API key is probably sufficient to get to a MVP -- can always expand later as needed.

[cbrake]

interesting article about server side vs client side device authentication: https://www.verypossible.com/what-engineering-leaders-need-to-know-about-iot-security

[cbrake]

authToken is implemented for NATS (feature-nats). Still should probably add authtoken support for HTTP.

[cbrake]

authToken support implemented for HTTP -- closing for now, we can improve more later.