IoT Identity Management: Securing Connected Devices with Keycloak

Last updated: February 2026 — Covers Keycloak 26.5 and current IoT security standards

---

Introduction

The Internet of Things has fundamentally changed how organizations approach identity management. According to IoT Analytics’ State of IoT report, the number of connected IoT devices is projected to reach 21.1 billion by the end of 2025—a 14% year-over-year increase—with projections exceeding 39 billion by 2030 and 50 billion by 2035.

Traditional authentication systems designed for human users cannot handle the scale, protocol requirements, and security constraints of IoT environments. This guide explores how to implement IoT identity management using Keycloak, covering authentication flows, Zero Trust security patterns, and architectural decisions that make device authentication work at scale.

Why IoT Requires Different Identity Management

Traditional IAM systems authenticate humans through browsers—username/password forms, social logins, multi-factor prompts. IoT devices break these assumptions in several ways:

Resource Constraints

Many IoT devices lack the memory, processing power, or input capabilities for complex authentication flows. A temperature sensor cannot display a login form or prompt for MFA.

Scale Requirements

A factory floor might have thousands of sensors authenticating simultaneously. Consumer IoT deployments can reach millions of devices. Per-user pricing models from providers like Auth0 or Okta become prohibitively expensive at IoT scale—one reason organizations choose flat-rate alternatives that support unlimited devices.

Communication Patterns

Devices often communicate machine-to-machine without human involvement. They need to authenticate to APIs, message brokers, and backend services autonomously.

Lifecycle Management

Devices are provisioned, deployed, updated, and eventually decommissioned. Each phase requires identity operations—certificate rotation, credential revocation, access policy updates.

Regulatory Pressure

Frameworks including NIST SP 800-207, ISO/SAE 21434, and the EU Cyber Resilience Act now require organizations to demonstrate real-time control over connected assets.

Zero Trust Architecture for IoT

The traditional perimeter-based security model fails for IoT. Devices operate outside corporate networks, connect from unpredictable locations, and may be physically accessible to attackers. Zero Trust Architecture addresses these challenges.

Core Zero Trust Principles for IoT

Never Trust, Always Verify

Every device authentication request is validated, regardless of network location or previous authentication state.

Least Privilege Access

Devices receive only the permissions necessary for their function. A temperature sensor doesn’t need access to user management APIs.

Continuous Verification

Device identity is validated throughout operational sessions, not just at initial connection. Keycloak’s session management capabilities support this pattern.

Cryptographic Identity

Every device must possess cryptographically verifiable credentials. Hardware Security Modules (HSM) or Trusted Platform Modules (TPM) provide tamper-resistant identity storage for high-security deployments.

CISA Zero Trust Maturity Model

The Cybersecurity and Infrastructure Security Agency’s Zero Trust Maturity Model organizes implementation across five pillars, progressing through Traditional, Initial, Advanced, and Optimal stages:

Pillar	IoT Focus
Identity	Continuous device identity validation
Devices	Physical and virtual asset inventory and analysis
Networks	Micro-segmentation, encrypted communications
Applications	Per-application access policies
Data	Classification and protection based on sensitivity

OAuth 2.0 Flows for IoT Authentication

OAuth 2.0 includes flows designed for IoT device constraints. Selecting the right flow for each device type is critical.

OAuth 2.0 Device Authorization Grant (RFC 8628)

The Device Authorization Grant is designed for devices with limited input capabilities—smart TVs, set-top boxes, industrial equipment, or any device where typing credentials is impractical.

How it works:

1. The device requests a device code and user code from the authorization server
2. The device displays the user code (or a QR code) and a verification URL
3. The user visits the URL on a separate device (phone, laptop) and enters the code
4. The user authenticates normally on the companion device
5. The original device polls for the access token until authentication completes

This flow is ideal for consumer IoT devices where a human user is present but the device lacks a keyboard.

Security Warning: The Storm-2372 phishing campaign demonstrated how attackers can abuse Device Flow by tricking users into entering codes tied to attacker-controlled sessions. Implement monitoring for unusual authentication patterns and educate users about phishing risks.

Keycloak Configuration:

{
  "clientId": "smart-thermostat",
  "enabled": true,
  "publicClient": true,
  "standardFlowEnabled": false,
  "oauth2DeviceAuthorizationGrantEnabled": true,
  "attributes": {
    "oauth2.device.authorization.grant.enabled": "true",
    "oauth2.device.polling.interval": "5"
  }
}

Client Credentials Flow

For machine-to-machine (M2M) authentication where no human is involved, the Client Credentials flow is appropriate. Backend services, automated processes, and devices with secure credential storage use this flow.

When to use Client Credentials:

• Server-to-server API calls
• Scheduled batch processes
• Devices with hardware security modules (HSM) or trusted platform modules (TPM)
• Industrial IoT with secure key storage

Keycloak Configuration:

{
  "clientId": "industrial-plc-001",
  "enabled": true,
  "serviceAccountsEnabled": true,
  "clientAuthenticatorType": "client-secret",
  "standardFlowEnabled": false,
  "directAccessGrantsEnabled": false
}

The service account created for this client can be assigned roles and permissions like any user, enabling fine-grained role-based access control for your devices.

JWT Authorization Grant (Keycloak 26.5+)

Keycloak 26.5 introduced the JWT Authorization Grant (RFC 7523), enabling devices to use externally signed JWT assertions to request access tokens. This is particularly useful for:

• Devices with existing PKI infrastructure
• Cross-platform token exchange
• Kubernetes service account integration

MQTT and Message Broker Integration

IoT deployments commonly use MQTT for device communication. Keycloak can secure MQTT brokers through OAuth 2.0 token validation.

Architecture Pattern:

┌─────────────┐     OAuth 2.0      ┌─────────────┐
│  IoT Device │ ──────────────────▶│  Keycloak   │
└─────────────┘   Client Creds     └─────────────┘
       │                                  │
       │ MQTT + JWT                       │ JWKS
       ▼                                  ▼
┌─────────────┐    Token Validation  ┌─────────────┐
│ MQTT Broker │ ◀────────────────────│ Auth Plugin │
└─────────────┘                      └─────────────┘

The device obtains an access token from Keycloak and includes it when connecting to the MQTT broker. The broker validates the token against Keycloak’s JWKS endpoint.

Device Identity Lifecycle Management

Managing device identities from provisioning through decommissioning requires systematic processes.

Provisioning

Option 1: Pre-provisioning

Generate client credentials during manufacturing and embed them in device firmware. Suitable for high-security environments with controlled supply chains.

Option 2: Dynamic Registration

Use OpenID Connect Dynamic Client Registration to create clients programmatically:

curl -X POST https://keycloak.example.com/realms/iot/clients-registrations/default 
  -H "Authorization: Bearer $INITIAL_ACCESS_TOKEN" 
  -H "Content-Type: application/json" 
  -d '{
    "client_id": "device-'$(uuidgen)'",
    "client_name": "Factory Sensor - Line 3",
    "service_accounts_enabled": true
  }'

Option 3: Bootstrap Flow

Devices authenticate with a temporary bootstrap credential to obtain permanent credentials. The bootstrap credential is invalidated after first use.

Credential Rotation

Credentials should rotate periodically. For X.509 certificate-based authentication, integrate with certificate management systems. For client secrets, implement automated rotation:

1. Device detects credential expiration approaching
2. Device requests new credentials using current valid credentials
3. Authorization server issues new credentials
4. Device switches to new credentials
5. Old credentials are revoked after grace period

Revocation

When devices are decommissioned, stolen, or compromised:

1. Disable the client in Keycloak Admin Console
2. Revoke all active tokens
3. Update access policies in downstream systems
4. Log the revocation event for audit purposes

Automate revocation through the Keycloak Admin REST API for fleet management at scale.

Security Best Practices for IoT Authentication

Use Short-Lived Tokens

Access tokens for IoT devices should have short lifetimes—minutes, not hours. If a device is compromised, the window of exposure is limited.

{
  "access.token.lifespan": 300,
  "client.session.idle.timeout": 600,
  "client.session.max.lifespan": 3600
}

Implement DPoP (Demonstrating Proof-of-Possession)

Keycloak 26.4+ fully supports OAuth 2.0 DPoP, which binds tokens to cryptographic keys held by the device. This prevents token theft and replay attacks—critical for IoT deployments where network security cannot be guaranteed.

Enable Mutual TLS

For high-security environments, require client certificate authentication (mTLS). Keycloak supports X.509 certificate authentication, binding device identity to cryptographic material.

Secure Communication Channels

All device-to-Keycloak communication must use TLS 1.2 or higher. For extremely constrained devices, consider DTLS for UDP-based protocols like CoAP.

Monitor for Anomalies

Track authentication patterns. A device authenticating from an unexpected location, at unusual times, or with abnormal frequency may be compromised. Keycloak’s event system captures authentication events for analysis. Forward these events to your SIEM using Skycloak’s HTTP webhook integration.

Example: Smart Building Access Control

Consider a smart building with door locks, environmental sensors, and badge readers—all requiring authentication to the building management system.

Device Classes:

Device Type	Auth Flow	Credential Type	Token Lifetime
Door locks	Client Credentials	X.509 certificate	5 minutes
Environmental sensors	Client Credentials	Client secret	10 minutes
Badge readers	Device Authorization	Bootstrap + X.509	5 minutes
Admin tablets	Authorization Code + PKCE	User credentials + MFA	30 minutes

Realm Configuration:

realm: smart-building
clients:
  - clientId: door-lock-floor-1-room-101
    protocol: openid-connect
    serviceAccountsEnabled: true
    clientAuthenticatorType: client-x509
    attributes:
      x509.subjectdn: CN=door-lock-floor-1-room-101,O=BuildingCo
    defaultClientScopes:
      - door-access
      - device-telemetry

  - clientId: badge-reader-entrance
    protocol: openid-connect
    oauth2DeviceAuthorizationGrantEnabled: true
    publicClient: false

The tablets used by building administrators authenticate using PKCE (see our React + Keycloak PKCE guide) and require multi-factor authentication.

Keycloak vs. Alternatives for IoT

AWS Cognito

Amazon Cognito integrates well with AWS IoT Core but locks you into the AWS ecosystem. Custom authentication flows are limited compared to Keycloak’s extensibility.

Auth0

Auth0’s Machine-to-Machine tokens work for M2M scenarios, but pricing scales with the number of tokens issued—problematic for large IoT deployments with frequent authentication. See our detailed comparison.

Azure AD B2C

Microsoft’s solution is powerful for consumer scenarios but can be complex for industrial IoT with specific protocol requirements.

Why Keycloak

Keycloak’s advantages for IoT include:

• Protocol Support: Native OAuth 2.0 Device Flow, Client Credentials, JWT Authorization Grant, and custom authentication SPIs
• Extensibility: Custom authenticators for device-specific requirements
• Cost Model: Open source with no per-device or per-token fees
• Deployment Flexibility: Self-hosted, cloud, or fully managed
• Modern Security: FAPI 2.0 compliance, DPoP support, passkeys (Keycloak 26.4+)

For organizations wanting Keycloak’s power without operational overhead, managed Keycloak services eliminate infrastructure management while providing enterprise-grade security and compliance.

Implementation Checklist

Before deploying IoT identity management with Keycloak:

Planning

• [ ] Inventory device types and their authentication capabilities
• [ ] Select appropriate OAuth 2.0 flow for each device class
• [ ] Define credential provisioning and rotation procedures
• [ ] Establish revocation workflows
• [ ] Map to Zero Trust maturity model stages

Configuration

• [ ] Create dedicated realm for IoT devices
• [ ] Configure clients with appropriate flows and scopes
• [ ] Set token lifetimes appropriate for each device class
• [ ] Enable event logging for security monitoring

Security

• [ ] Enforce TLS 1.2+ for all connections
• [ ] Implement DPoP for token binding
• [ ] Configure brute force protection
• [ ] Set up SIEM integration for anomaly detection

Operations

• [ ] Automate device provisioning via Dynamic Client Registration
• [ ] Implement credential rotation pipelines
• [ ] Test revocation procedures
• [ ] Document incident response for compromised devices

Frequently Asked Questions

What is IoT identity management?

IoT identity management is the practice of assigning, verifying, and managing unique digital identities for connected devices. Unlike human users, IoT devices require automated authentication mechanisms that account for resource constraints, scale requirements, and machine-to-machine communication patterns.

How do IoT devices authenticate without user interaction?

IoT devices typically use the OAuth 2.0 Client Credentials flow, where the device presents pre-provisioned credentials (client ID and secret, or X.509 certificate) directly to the authorization server. For devices where a human is present but input is limited, the Device Authorization Grant allows authentication via a companion device like a smartphone.

What is the difference between Device Flow and Client Credentials?

The Device Authorization Grant (Device Flow) is for input-constrained devices where a human user authorizes the device via a separate browser. Client Credentials is for fully automated machine-to-machine authentication with no human involvement. Choose Device Flow for consumer devices (smart TVs, streaming boxes); choose Client Credentials for industrial sensors, backend services, and automated systems.

Why is Zero Trust important for IoT security?

Traditional perimeter security assumes devices inside the network are trusted. IoT devices often operate outside corporate networks, connect from unpredictable locations, and may be physically accessible to attackers. Zero Trust requires continuous verification of device identity regardless of network location, limiting the blast radius of compromised devices.

How does Keycloak handle IoT device authentication at scale?

Keycloak supports horizontal scaling across multiple instances with shared database and cache layers. For IoT deployments, use short-lived tokens to reduce session storage requirements, implement Client Credentials for stateless M2M authentication, and leverage Keycloak’s Admin REST API for automated device provisioning and revocation.

Conclusion

IoT identity management requires purpose-built approaches that account for device constraints, scale requirements, and security considerations that traditional IAM systems don’t address. The OAuth 2.0 Device Authorization Grant and Client Credentials flows provide the protocol foundation, while Zero Trust architecture ensures security in untrusted environments.

Organizations building IoT solutions should evaluate their device types, select appropriate authentication flows, implement systematic lifecycle management, and align with Zero Trust frameworks like NIST SP 800-207. Whether self-hosting Keycloak or using a managed solution, the architectural patterns remain the same—what changes is who handles the operational complexity.