Jump toUpdate content
Auth-by-device (MQTT, Websocket)
In this authentication model, the Hub client provides device credentials. All device features apply (message filters, metrics e.t.c.).
Auth-by-token (Sigfox, REST)
In this authentication model, the Hub client provides a secret token. Published messages skip the device features and go directly to the message broker.
Authentication is a model for building trust in the identity of IoT machines and devices. Authentication protects data and controls access when information travels via an unsecured network such as the Internet.
Auto-provisioning allows your Hub to automatically create missing devices when they supply valid TLS information.
A Broker is a remote server which forwards messages between clients. The job of the broker is to filter all incoming messages and distribute them correctly to subscribers.
A Client enables you to connect devices in your IoT network, from simple sensors to complex programmable devices, to the cloud. In MQTT, clients identify themselves using a unique ClientID. If left empty the Broker will generate a random one.
A device is a “client” of the Hub, it can be a connected object or any other application. It can be understood as a representation of a device or program that is connected to the cloud. Devices can be manually added, or created via auto-provisioning. Each device will be associated with a unique identifier to be used as “client ID” and a certificate/key pair for a maximum security level.
Through a Hub, Devices exchange messages with other Devices and cloud services using the MQTT protocol. MQTT over Websocket is also supported through a dedicated Network.
A Device certificate is a certificate presented by a device to be authenticated when it connects to the Hub using a secured connection.
When it comes to configuring your device certificates, there are three possibilities:
- A Scaleway-managed Hub CA and device certificate: a Scaleway-managed device certificate will be generated for the device when it is created.
- A Scaleway-managed Hub CA and user-managed device certificate: refer to this documentation page to replace the generated device certificate with your own.
- A user-managed Hub CA and device certificate: in this case you do not have to replace the device certificate. Simply connect to your Hub with a device certificate signed by the Hub CA. Refer to the How to provide your own device certificate page to learn how to use this method.
Encryption relies on asymmetric cryptography. Each peer has a public and a private key. The public key allows for encryption only, the private key allows for decryption only.
Events represent devices and route events or errors.
The Hub is the central link, the IoT platform, which is used to route messages published by other links to their recipient(s).
Hub Device Certificate Authority
The Hub devices certificate authority is used to authenticate devices’ identities when they connect to the Hub using a secured connection.
It is either provided and managed:
- by Scaleway: Automatically provided for you when you create a Hub.
- by the user: The page provide your own Hub’s certificate authority explains how to provide your Hub certificate authority.
Hub Server Certificate Authority
The Hub server certificate authority is the CA of the certificate presented by Scaleway’s MQTTS Hub endpoint.
It can be used by devices to verify the server identity when they open a secured connection. This CA can be found in your Scaleway console, under the Networks tab of your IoT Hub, in the Default MQTT Network item.
IFTTT stands for “If This, then That”. It is an easy to use yet powerful automation service where you can choose to perform an action upon an event. There are thousands of events and actions available and customisable.
Scaleway IoT Hub is a Platform as-a-Service (PaaS) fitting between connected devices and services, enabling secure
device-to-cloud communication. It uses a publish/subscribe architecture where the Hub ensures flexible data delivery to many destinations, including non MQTT targets such as databases, object storage, or any REST API.
Kickstarts applications are ready-to-use images allowing you to test and build your IoT applications as quickly as possible. Kickstarts will install and configure the tools and software required for you on a Scaleway virtual instance.
Messages are like telemetry sent from IoT devices to an IoT Messaging Hub. Messaging protocols are used to transmit these messages and can operate over TCP, or even a higher-level abstraction such as HTTPS.
Message filters restrict the messages your device can publish or subscribe to. Each filter can be configured to allow or reject given topics. See our reference documentation for more information.
mTLS is just an extension of TLS (Transport Layer Security). The main thing that makes mTLS different and more secure than TLS is that it requires both the server and client to verify each other.
Message Queuing Telemetry Transport (MQTT) is a publish/subscribe messaging protocol. The MQTT protocol, allows two remote devices to communicate via messages asynchronously with low bandwidth. It is increasingly used to communicate between connected objects. These connected objects collect different information from integrated sensors and this data is sent through MQTT.
Networks allow devices, ranging from embedded systems to server software, to exchange messages with IoT Hub.
The publish/subscribe pattern (also known as pub/sub) provides an alternative to traditional client-server architecture. In the client-sever model, a client communicates directly with an endpoint.The pub/sub model decouples the client that sends a message (the publisher) from the client or clients that receive the messages (the subscribers). The publishers and subscribers never contact each other directly. In fact, they are not even aware that the other exists.
Quality of Service levels (QoS)
Quality of Service levels determine how the relationship between the client and the Broker should unfold when they are communicating. It indicates the level of commitment to the delivery of a message between the communicating parties. Several levels are available:
- Qos 0: “At most once”: Also known as “fire and forget”. On this level, a message is sent (PUBLISH) and may be received at most once.
- Qos 1: “At least once”: This level guarantees that a message sent (PUBLISH), will be received at least once.
- Qos 2: “Exactly once”: This level of service guarantees that the message sent is being received exactly once.
IoT Routes allow messages to be transmitted to the bricks of the Scaleway ecosystem, to third-party applications or even to other CSPs (Cloud Service Providers).
A device can be configured to either Deny or Allow insecure connections. In other words, connection security is either required or optional. This translates differently according to the three available connection methods (Mutual-authentication TLS, Server-authentication TLS and Plain). See our [/iot/iot-hub/reference-content/devices) for more information.
TLS, and its now-deprecated predecessor, Secure Sockets Layer (SSL), are cryptographic protocols designed to provide communications security over a computer network. For example, a cryptographic protocol encrypts the data that is exchanged between a web server and a user.
A topic is a character string indicating the message’s contents (example:
home/2ndfloor/kitchen/temperature). With MQTT, all subscribers receive a copy of the messages published with matching topics by default.
Transmission Control Protocol (TCP)
TCP establishes and maintains connections between hosts until applications at each end have finished exchanging messages, facilitating the transport of HTTP requests and responses.