sensedia_iot

sensedia_iot

APIs para dispositivos IoT 
===================


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 um 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.
[ ![](https://media1.giphy.com/media/5aLrlDiJPMPFS/giphy.gif)]()

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. 

[![](http://www.hivemq.com/wp-content/uploads/Screen-Shot-2014-10-22-at-12.21.07.png)]()

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? 
[ ![](https://media3.giphy.com/media/12NUbkX6p4xOO4/giphy.gif)]()

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](http://sensedia.com/blog/apis/como-verificar-se-um-token-oauth-e-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
http://nordicapis.com/why-oauth-2-0-is-vital-to-iot-security/