*texto colaboração de Daniela Marques – Sensedia

A popularização de hardwares de prototipagem como Arduino e Raspberry Pi baratearam o custo de desenvolvimento de sistemas embarcados e dispositivos IoT, o que possibilitou qualquer pessoa desenvolver seu próprio sistema inteligente, como automação residencial, controle de sensores, robôs etc., com muita facilidade.

O boom do IoT é recente e diferentemente de sistemas convencionais, nesses dispositivos há a preocupação de consumo de energia e banda, limitação de memória etc. e ainda há pouca discussão sobre modelagens e arquiteturas que permitam evoluir de forma ágil, segura e escalável essas aplicações no mundo IoT, sendo comum casos de vulnerabilidades em sistemas críticos como equipamentos de vigilância, sensores e até mesmo monitor cardíaco de bebês. É essencial durante o desenvolvimento preocupar-se com essas questões e uma API REST pode ser uma solução ideal.

If you’re afraid to change something it is clearly poorly designed. – Martin Fowler

Ao utilizar REST, há uma flexibilidade maior de incrementar novas features, facilidade de expor o sistema para diferentes plataformas (os clientes podem ser apps, outros dispositivos IoT, navegadores etc), se utilizado corretamente reduzirá a complexidade do sistema, permite inserir um API Management para solucionar problemas de segurança, throttling, validar acessos etc. e imagine as inúmeras possibilidades de expôr uma API de um dispositivo IoT.

Há algumas diferenças importantes para implementação de APIs para sistemas comuns e para dispositivos IoT.

MQTT vs HTTP vs CoAP

É comum cenários em que o consumo de banda e energia do dispositivo é limitado, seja por limitações de hardware ou por possuir processos críticos que são mais prioritários. Para esses casos, existem protocolos que são mais eficientes que o HTTP como o MQTT e o CoAP, os quais também permitem utilizar JSON.

O MQTT é orientado a mensagens e funciona como um modelo cliente/servidor porém o servidor é denominado broker. Cada dispositivo, sistema ou sensor pode ser um cliente e se inscrever num tópico:

/sensors/{sensorId}/temperature 

Suponha que o A, B são clientes inscritos neste tópico e C publica um novo valor de temperatura nesse tópico. Os clientes A, B receberão a notificação do novo valor adicionado sem a necessidade de fazer nenhuma requisição e consequentemente poupando processamento e energia. Em MQTT as únicas ações disponíveis são publish, subscribe e unscribe diferentemente dos verbos HTTP.

O CoAP por sua vez possibilita o uso dos verbos já conhecidos como GET, PUT, PATCH e DELETE porém utiliza o protocolo UDP ao invés de TCP/IP. O modelo é exatamente cliente/servidor, onde o cliente realiza requisições para algum recurso e servidor retorna as responses. A grande vantagem em relação ao fluxo HTTP TCP/IP comum é o fato de seus pacotes serem menores, o que poupa os recursos do device.

O projeto Eclipse Ponte permite que seja possível a mesma aplicação e devolver e receber respostas em HTTP, MQTT ou CoAP.

OAuth 2.0

O OAuth 2.0 é uma solução para autenticação e autorização que promove acesso aos recursos somente para devices/clientes autorizados.

O fluxo funciona com Resource Owner, Resource Server, Authorization Server, OAuth Server e o Client. Para acessar um determinado recurso, os seguintes passos ocorrem resumidamente:
1) O Client deve contatar o Authorization Server com seu respectivo username e password
2) O Authorization Server verifica com o Authentication Server se os dados passados pelo Client estão corretos
3) Caso estejam corretos, o Authorization Server permite o Client acessar o determinado recurso em posse do access_token

Toda a comunicação envolvida no processo do OAuth 2.0 necessita de TLS (Segurança da Camada de Transporte) para ter certeza de que aquele client é mesmo quem diz ser e encriptar a comunicação. Porém com dispositivos IoT, temos limitações que não permitem o device estar todo o tempo online, preocupar-se com bateria, realizar operações complexas com pouco hardware etc.

Para utilizar OAuth 2.0 em IoT independente de TLS, é necessário usar o fluxo denominado Proof of Possession.
1) O processo inicia normalmente com o Client contatando o Authorization Server com seu respectivo username e password, o Authorization Server verifica com o Authentication Server se os dados passados pelo Client estão corretos. Caso esteja, um código de autorização é retornado para o Client.

Esse código de autorização retornado serve somente para provar que aquele Client é quem diz ser e não permite acessar nenhum recurso.

2) O próprio Client gera uma key forte o suficiente para não ser quebrada
3) O Client transmite a key gerada anteriormente para o Authorization Server juntamente com o authorization code e informando quais recursos deseja acessar. Neste passo, o Authorization Server sabe que aquele authorization code gerado está ligada a uma determinada key e retorna um access_token para o Client
4) O Client em posse do access_token acessa um determinado recurso. O dono do recurso verifica com o Authorization Server qual é a key daquele determinado access_token, o acesso é permitido somente se o access_token transmitido bate com a determinada key.

E no caso em que o dono do recurso está offline e não pode verificar com o Authorization Server aquele Client?

Neste caso, é possível realizar a validação através de um JWT. Os passos ocorrem normalmente mas ao invés do Authorization Server retornar um access_token, é retornado um JWT. Através do JWT o dono do recurso consegue validar aquele Client sem a necessidade de se comunicar com o Authorization Server.

Para ler um pouco mais sobre tokens em OAauth 2.0, leia Como verificar se um Token OAuth é valido

Cool things

MBED Device Connector

O mbed Device Connector é um serviço desenvolvido para conectar placas baseadas no ARM Cortex-M na nuvem através de APIs sem configurar nenhum ambiente de infraestrutura e gratuito, suporta CoAP/HTTP, utiliza JSON e é ideal para prototipação mas limita a quantidade de requisições por dia e pode não ser tão personalizável de acordo com as necessidades.

Pingo

O Pingo é uma API feita totalmente em Python que possibilita a portabilidade de código para placas que possuem diferentes hardwares evitando o retrabalho, na prática o Pingo permite que o mesmo código que é executado num Arduino Yún seja executado numa BeagleBone Black, pcDuino etc. Atualmente o Pingo suporta Raspberry Pi, Arduino Yún, Arduino Firmata, BeagleBone Black, Intel Galileo, pcDuino e SECO UDOO.

Amazon e Azure IoT Hubs

As principais plataformas que oferecem serviços na nuvem já disponibilizam serviços específicos para IoT, os quais em geral permitem a autenticação do device, disponibilizam um Gateway para gerenciar a latência, segurança e análise de usos e possuem SDKs disponíveis para conectar cada device a nuvem.

Referências

https://medium.com/@AlexandraBowen/iot-is-eating-the-world-apis-and-rest-9e0321bc6cbf
https://medium.com/@AlexandraBowen/iot-is-eating-the-world-future-of-iot-a001dc263f08
https://dzone.com/articles/json-http-and-the-future-of-iot-protocols
https://nordicapis.com/why-oauth-2-0-is-vital-to-iot-security/