Authentication

Most real-time messaging platforms force you to maintain a separate user database just for messaging. CloudSignal takes a different approach: it integrates directly with the identity provider you already use, so your users authenticate once and get MQTT access automatically.

The problem with separate auth

When a messaging layer requires its own credentials, you end up managing two sources of truth for identity. Users exist in your app database and in the messaging system. Passwords drift out of sync. Deprovisioning means remembering to revoke access in two places. Every new integration doubles the auth surface area.

This is where CloudSignal's auth provider model changes the equation.

Auth provider integration

CloudSignal connects to the identity providers your application already relies on. Your backend validates the user's identity token and exchanges it for MQTT credentials - no separate user registration, no password sync, no duplicate accounts.

Supported providers

The flow is identical across all providers:

1. User signs in through your app using your existing provider
2. Your backend receives the provider's identity token
3. Your backend calls CloudSignal's token exchange endpoint
4. CloudSignal returns temporary MQTT credentials (username + password)
5. Your client connects to the MQTT broker with those credentials

Your users never see or handle MQTT passwords. Your backend never stores them. The credentials are scoped to the session and expire automatically.

Token-based authentication

For applications that do not use a third-party identity provider - or for machine-to-machine scenarios - CloudSignal's Token Service generates temporary MQTT credentials with a 60-minute TTL.

Why temporary credentials matter

• No embedded secrets - Browser and mobile clients never hold permanent passwords. If a token leaks, it expires in under an hour.
• Automatic cleanup - Expired users are removed from the system. No accumulation of stale accounts.
• Per-session scoping - Each token exchange produces fresh credentials. Revoking access is as simple as not issuing a new token.
• Zero password management - No password resets, no rotation schedules, no credential sync between systems.

When to use tokens vs. auth providers

Individual MQTT users

For backend services, IoT devices, and any client that can securely store credentials, CloudSignal supports permanent MQTT users. Each user authenticates with:

username@org_short_id

For example: sensor_01@org_k7xm4pqr2n5t

Individual users are created through the dashboard or API and persist until explicitly deleted. They are best suited for long-running services that maintain persistent connections.

How this compares

Many messaging platforms take one of two approaches to auth, both with significant trade-offs:

API-key-only platforms give every client the same key. There is no per-user identity, which means no per-user access control. You cannot restrict what one client sees without building a proxy layer.

Custom-auth-only platforms require you to implement authentication webhooks, validate tokens on every connection, and maintain a mapping between your users and messaging identities. This works, but it is undifferentiated infrastructure that every customer rebuilds.

CloudSignal's approach gives you per-user identity (for access control) with provider integration (so you do not rebuild auth). The broker authenticates every connection against your organization's credentials - whether those came from Supabase, Firebase, Auth0, Clerk, or the Token Service - and enforces access control rules per user.

TLS encryption

All authentication happens over encrypted connections. CloudSignal exposes two endpoints, both encrypted with TLS 1.2+:

Next steps

• Auth provider guides - Step-by-step setup for Supabase, Firebase, Auth0, and Clerk
• Access lists - Control what authenticated users can publish and subscribe to