Overview
The authentication microservice (Auth Service) is the security foundation of the IoT platform, unifiedly responsible for device connection authentication, user login authorization, API access control, and permission management. The IoT platform faces dual authentication challenges: first, the identity verification of massive devices — each device needs to prove "who I am" when connecting, while preventing forgery, replay attacks, and man-in-the-middle attacks; second, access control for multi-role users — operational personnel, developers, and end users have different access permissions to platform resources, requiring fine-grained management. The authentication microservice abstracts these two types of requirements into a unified identity and permission model, providing a trusted identity foundation for the entire platform.
Unlike traditional web applications, IoT devices are often unattended and resource-constrained, unable to complete the OAuth authorization flow through a browser like human users. Device authentication needs to support pre-installed keys, certificates, or strong authentication based on hardware security modules (HSM), while also considering simplified authentication for low-cost devices. The authentication microservice must balance security and usability.
Device Authentication
One device, one secret (ProductKey + DeviceSecret)
Each device is assigned a unique ProductKey (product identifier) and DeviceSecret (device key) during registration. When connecting via MQTT/CoAP, the device uses ProductKey + DeviceName + signature (based on DeviceSecret) for authentication. Advantages: simple implementation, suitable for mass production; disadvantages: DeviceSecret must be revoked promptly if leaked. Suitable for smart home, metering, and other medium-to-low security scenarios.
X.509 certificate authentication
The device is pre-installed with a client certificate, enabling mutual TLS authentication during connection. The certificate's validity period can be set and automatic rotation is supported. Suitable for high-security scenarios such as connected vehicles, industrial control, and financial payments. Requires a supporting PKI system (certificate issuance, certificate revocation list CRL, OCSP query).
Pre-registration and dynamic issuance
Devices are pre-registered on the platform before leaving the factory to obtain temporary credentials; when first going online, permanent credentials are exchanged through a secure channel. Alternatively, batch import + first activation mode can be used to reduce production line programming costs. Supports binding IoT SIM cards' IMSI/ICCID with devices for a "SIM and device integrated" authentication.
User authentication
Account and password: Traditional method, requires password strength policies, account lockout on login failure, regular password changes, etc. Supports secure hash storage such as BCrypt and Argon2.
SMS/email verification code: Password-free login, suitable for mobile and temporary access. Requires anti-bot and anti-replay measures; verification code validity is usually 5–10 minutes.
OAuth2/OpenID Connect: Supports third-party login via WeChat, DingTalk, Enterprise WeChat, etc., enabling "scan to login". Suitable for SaaS IoT platforms, lowering the user registration barrier.
JWT (JSON Web Token): JWT is issued after successful login. Subsequent requests carry it in the header, allowing stateless verification by the server. Suitable for microservice architectures; attention is needed for token refresh and blacklist implementation (logout scenarios).
API Authentication and Tenant Isolation
When the open platform provides RESTful APIs externally, each request must verify: ① Token validity; ② The user/tenant associated with the Token has permission to access the target resource; ③ The API call quota is not exceeded. In a multi-tenant scenario, Tenant A cannot access devices and data of Tenant B, and tenant ID filtering must be applied at the data layer. The authentication microservice can provide a unified authentication interface for the API gateway to call, or embed tenant ID and role through JWT claims for each business service to validate independently.
Permission Model (RBAC and Extensions)
RBAC (Role-Based Access Control): User → Role → Permissions, for example, the "Operator" role has "View Device" and "Restart Device" permissions, while the "Developer" has "Call API" and "View Logs" permissions. Supports role inheritance and multiple roles overlay.
Resource-Level Permissions: Fine-grained control such as "a specific user has read/write permission for a certain batch of devices of a certain product." Suitable for large enterprises where different departments manage different groups of devices.
Data Permissions: Controls the data scope visible to the user, such as only being able to see devices in their own region or reports of their own tenant. Combined with multi-tenancy and data anonymization to meet compliance requirements.
Considerations for IoT scenarios
Device authentication must consider timeouts and retries in low-network and high-latency environments; support smooth migration of credentials after device firmware upgrades; and integrate with the device lifecycle (pre-registration → activation → operation → deactivation → de-registration). In the SimtoLink IoT SIM cards and device management scenario, the authentication service needs to integrate with carrier card management and device profiles to achieve a unified identity system of "Card + Device + User."