ClearBlade IoT Enterprise supports public key (asymmetric) and mTLS device authentication types.various types of authentication.
Active key authentication
The MQTT protocol allows for the connect action to provide a username and password. We will modify the use of those fields to accommodate our OAuth-styled token model.
Key | Value | Example |
|---|---|---|
URL | URL_OF_BROKER | |
PORT | PORT | 1883 |
Username | USER_TOKEN | abcdefabcdef01234567890 |
Password | SYSTEM_KEY | f0cbf0cbf0cbf0cbf0cbf0cbf0cb |
ClientID | UNIQUE_CLIENT_ID | sjdbfkasdbf |
Public key (asymmetric) authentication
A device must create a private/public key pair. The private key is only left local on the device, while the public key is uploaded to the ClearBlade IoT Enterprise system’s device record.
See Creating key pairs to create the key pair.
To authenticate, the device will construct a JSON Web Token (JWT) based on the private key and present that on the MQTT authentication or REST endpoint’s connect packet. The JWT is used in place of the standard ClearBlade auth token.
...
Find the device in the system’s device table:
Right-click the device’s gear icon and choose Public Keys, then click the Add button:
Pick the appropriate key format:
ClearBlade IoT Core supports the RSA and elliptic curve algorithms. For details on key formats, see Public key format.
Claims
ClearBlade IoT Enterprise requires these reserved claim fields. They may appear in any order in the claim set.
...
Each time the client sends an MQTT message (including PINGREQ), the ClearBlade MQTT Broker checks the exp. If the current time is later than exp + 10m then the client will disconnected. The 10 minutes is to allow for time skew between client and server.
The
| View file | ||
|---|---|---|
|
mTLS
Devices may connect using an mTLS approach to gain their access token. ClearBlade handles mTLS auth and TLS termination.
...
Currently, no user interface administration is available to manage the loaded certificates. All certificates must be loaded to the server via API calls.
Requirements
The device name must be the cn (common name) in the cert presented. The platform verifies that the certificate passed in is for the device.
APIs
/admin/settings/mtls
GET, PUT (upsert), and DELETE support. Admin only.
...
No query support. Deletes mTLS settings.
/admin/revoked_certs
GET, POST, and DELETE support. Admin only.
...
Query supported. An empty query deletes all revoked certificates and returns nil on success.
Authentication
A device can authenticate (i.e., receive a token) using mTLS by sending an HTTP POST request to port 444 of the relevant URL.
The following curl can be used as an example:curl -X POST "https://yourURL.com:444/api/v/4/devices/mtls/auth" -H 'Content-Type: application/json' -H 'Accept: application/json' -d '{"system_key": "yourSystemKey", "name": "yourDeviceName"}' --cert "path/to/yourDeviceCert.pem" --key "path/to/yourDeviceKey.pem"
The returned response will contain a device token.
Similarly, this Python code can be used as an example:
| Code Block |
|---|
import requests
url = "https://yourURL.com:444/api/v/4/devices/mtls/auth"
headers = {"Content-Type": "application/json", "Accept": "application/json"}
data = '{"system_key": "yourSystemkey", "name": "yourDeviceName"}'
resp = requests.post(url, headers=headers, data=data, verify=True, cert=("path/to/yourDeviceCert.pem", "path/to/yourDeviceKey.pem"))
deviceToken = str(resp["deviceToken"]) |
ALPN (Application Layer Protocol Negotiation)
ClearBlade supports mTLS authentication for devices connecting via MQTT using ALPN on port 444. The ALPN protocol name is clearblade_mqtt_mtls. Device Just-in-Time (JIT) provisioning is also supported. A Root CA certificate must be added via the mTLS admin endpoints before connecting devices via mTLS.
...