MQTT JWT Kimlik Doğrulama: Şifre Alanında Token Kullanımı

MQTT JWT kimlik doğrulama, bir istemcinin CONNECT paketinin şifre alanına imzalı bir JSON Web Token koyması ve broker'ın depolanmış bir şifreyi aramak yerine imzayı ve claim'leri doğrulaması anlamına gelir. Bu yazı, bunun hat üzerinde nasıl çalıştığını, gerçek cihazlarda token süre dolumu ve yenilemesiyle nasıl başa çıkılacağını ve ek hareketli parçaların statik cihaz başına kimlik bilgilerine kıyasla ne zaman buna değdiğini açıklıyor.

Bir JWT, MQTT CONNECT İçinde Nasıl Taşınır?

MQTT'nin temel kimlik doğrulamasında token için ayrılmış bir alan yoktur. Sahip olduğu şey, bir kullanıcı adı metni ve spesifikasyonun ikili veri olarak tanımladığı bir şifre alanıdır. JWT destekleyen broker'lar bu alanı yeniden kullanır:

CONNECT
  Client ID:  sensor-0042
  Username:   sensor-0042            (often ignored or matched to a claim)
  Password:   eyJhbGciOiJSUzI1NiIs...  (the encoded JWT)

Bir JWT, noktalarla ayrılmış base64url ile kodlanmış üç bölümden oluşur: algoritmayı belirten bir başlık, claim'lerden oluşan bir payload ve bir imza. Tipik bir cihaz token'ının claim'leri şöyle görünür:

{
  "iss": "https://auth.example.com",
  "sub": "sensor-0042",
  "aud": "mqtt.example.com",
  "iat": 1792130400,
  "exp": 1792134000,
  "topics": {
    "pub": ["plant1/line3/sensor-0042/#"],
    "sub": ["plant1/line3/sensor-0042/cmd/#"]
  }
}

Broker veya ona bağlı bir kimlik doğrulama eklentisi ardından şunları yapar:

1. Token'ı çözer ve imzayı paylaşılan bir sırla (HS256) veya bir açık anahtarla (RS256, ES256) kontrol eder.
2. exp, nbf, iss ve aud değerlerini kontrol eder.
3. İsteğe bağlı olarak sub değerini client ID veya kullanıcı adıyla karşılaştırır.
4. İsteğe bağlı olarak istemcinin hangi topic'leri kullanabileceğine karar vermek için özel claim'leri okur.

Token bir şifre olarak taşındığından, herhangi bir MQTT kullanıcı adı şifre doğrulama yönteminde olduğu gibi aynı kural geçerlidir: TLS üzerinden gönderilmelidir. Bir JWT, taşıyıcı (bearer) kimlik bilgisidir. Onu yakalayan herkes süresi dolana kadar kullanabilir.

MQTT 5 Gelişmiş Kimlik Doğrulama

MQTT 5.0, broker ile istemcinin challenge-response alışverişleri yürütebilmesi ve canlı bir oturum sırasında bağlantıyı kesmeden yeniden kimlik doğrulaması yapabilmesi için bir Authentication Method özelliği ve bir AUTH paketi ekler. Bazı broker'lar token yöntemlerini bu mekanizma üzerinden sunar; bu da açık bir bağlantıda token yenilemeye olanak tanır. Destek, broker'lar ve istemci kütüphaneleri arasında büyük farklılık gösterir; bu nedenle çoğu kurulum hâlâ daha basit olan şifre alanı yaklaşımını kullanır ve yenilemek için yeniden bağlanır. AUTH akışı OASIS MQTT 5.0 spesifikasyonunda açıklanmıştır.

Hangi Broker'lar JWT Destekler?

JWT, MQTT'nin kendisinin bir parçası değil, bir broker veya eklenti özelliğidir. Bazı broker'lar bir JWT doğrulayıcı içerir; Mosquitto ise üçüncü taraf kimlik doğrulama eklentileri aracılığıyla token doğrulayabilir. Hangi algoritmaları, anahtar kaynaklarını (statik anahtar veya bir JWKS uç noktası) ve claim eşlemelerini desteklediğini görmek için broker'ınızın dokümantasyonunu kontrol edin.

ConnectMQ, JWT kimlik doğrulamasını desteklemez. Bir ConnectMQ broker'ı, istemcilerin kimliğini portalda oluşturulan kullanıcı adı ve şifre ile doğrular ve her client ID'yi kendisine verilen kimlik bilgilerine bağlar. Tenant'lar birbirinden izole edilmiştir; dolayısıyla bu kimlik bilgileri yalnızca kendi broker'ınıza ulaşır. Aşağıdaki karşılaştırmalar, bu modelin mi yoksa bir token modelinin mi projenize uygun olduğuna karar vermenize yardımcı olacaktır.

Token Oluşturma ve Kullanma: Örnek

Aşağıdaki örnek, RS256 token'larını doğrulayan, mqtt.example.com adresindeki varsayımsal bir broker'a karşı bir JWT kurulumunun iki yarısını gösterir. Önce minimal bir yayıncı servisi bir cihaz için token imzalar:

# pip install pyjwt cryptography
import time
import jwt

PRIVATE_KEY = open("issuer_private.pem", "rb").read()

def issue_device_token(device_id: str, ttl_seconds: int = 3600) -> str:
    now = int(time.time())
    claims = {
        "iss": "https://auth.example.com",
        "sub": device_id,
        "aud": "mqtt.example.com",
        "iat": now,
        "nbf": now - 30,          # küçük saat kaymalarını tolere et
        "exp": now + ttl_seconds,
    }
    return jwt.encode(claims, PRIVATE_KEY, algorithm="RS256")

if __name__ == "__main__":
    print(issue_device_token("sensor-0042"))

Ardından cihaz, token'ı şifresi olarak kullanarak bağlanır ve süre dolmadan önce yeni bir token ile yeniden bağlanır:

# pip install paho-mqtt requests
import ssl
import time
import requests
import paho.mqtt.client as mqtt

DEVICE_ID = "sensor-0042"
TOKEN_URL = "https://auth.example.com/device-token"
REFRESH_EVERY = 50 * 60   # 60 dakikalık süre dolumundan 10 dakika önce yenile

def fetch_token() -> str:
    # Cihaz, yayıncıya kendi uzun vadeli sırrıyla kimliğini doğrular
    r = requests.post(TOKEN_URL, json={"device": DEVICE_ID}, timeout=10)
    r.raise_for_status()
    return r.json()["token"]

def on_connect(client, userdata, flags, reason_code, properties):
    print("CONNACK:", reason_code)

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=DEVICE_ID, protocol=mqtt.MQTTv5)
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect

def connect_with_fresh_token():
    client.username_pw_set(DEVICE_ID, fetch_token())
    client.connect("mqtt.example.com", 8883, keepalive=60)
    client.loop_start()

connect_with_fresh_token()
while True:
    time.sleep(REFRESH_EVERY)
    client.disconnect()      # temiz bağlantı kesme, yapılandırıldıysa oturum korunur
    client.loop_stop()
    connect_with_fresh_token()

fetch_token içindeki yoruma dikkat edin: cihazın yayıncıya kendini kanıtlamak için yine de uzun vadeli bir sırra veya sertifikaya ihtiyacı vardır. JWT, statik kimlik bilgisini broker bağlantısından yayıncı bağlantısına taşır; onu ortadan kaldırmaz.

Süre Dolumu ve Yenileme Kalıpları

Süre dolumu, token kullanmanın ana nedenidir ve aynı zamanda üretim ortamındaki olayların ana kaynağıdır. Broker'lar süresi dolan bir token'ı iki yoldan biriyle ele alır:

Cihazlarda işe yarayan kalıplar:

1. Erken yenileyin. Yeni token'ı süre dolumunda değil, ömrünün yaklaşık yüzde 80'inde isteyin.
2. Temiz şekilde yeniden bağlanın. Aboneliklerin ve kuyruktaki QoS 1 mesajlarının yeniden bağlanmadan sonra korunması için kalıcı bir oturum (Clean Start false ve bir session expiry ile) kullanın.
3. Saati doğru tutun. Saati yanlış olan bir cihaz token'ları hatalı üretir veya reddeder. Token istemeden önce saati NTP ile senkronize edin ve nbf ile küçük bir kaymaya izin verin.
4. Yayıncı kesintilerini ele alın. Yayıncı çalışmıyorsa cihaz mevcut bağlantısını korur ve geri çekilmeyle yeniden dener; çalışan bir oturumu düşürmemelidir.
5. CONNACK nedenlerini günlüğe kaydedin. Süresi dolmuş veya geçersiz bir token, MQTT 5'te genellikle 0x86 (Bad User Name or Password) veya 0x87 (Not authorized) üretir.

Token Güvenliğindeki Tuzaklar

Token'lar şifrelerin başarısız olmadığı şekillerde başarısız olur; bu yüzden üretime geçmeden önce bunları gözden geçirin:

• Algoritma karışıklığı. Broker'ı yalnızca sizin verdiğiniz algoritmayı, örneğin RS256'yı kabul edecek şekilde yapılandırın. Asla none kabul etmeyin ve token başlığının simetrik ile asimetrik doğrulama arasında seçim yapmasına asla izin vermeyin.
• Cihazlarda paylaşılan HMAC sırları. Cihazlar kendi HS256 token'larını imzalayabiliyorsa her cihaz ana sırrı tutuyor demektir. Token'ları yalnızca sunucu tarafında imzalayın.
• Aşırı uzun ömürler. Bir yıl geçerli bir token, fazladan adımları olan bir şifreden başka bir şey değildir. Ömürleri, sızan bir token'ın süresi hızla dolacak kadar kısa, zayıf ağlardaki cihazların sürekli yenileme yapmayacağı kadar uzun tutun.
• Eksik audience kontrolleri. aud olmadan, başka bir servis için verilmiş bir token broker'ınıza karşı tekrar kullanılabilir.
• Token'ları günlüğe yazmak. Token'lar tıpkı şifreler gibi hata ayıklama günlüklerine ve çökme raporlarına düşer. sub ve exp değerlerini günlüğe yazın, token'ı asla.

JWT ile Statik Cihaz Başına Kimlik Bilgilerinin Karşılaştırması

JWT; zaten bir kimlik sağlayıcı işlettiğinizde, kullanıcılar (yalnızca cihazlar değil) tarayıcılardan veya mobil uygulamalardan kısa oturumlarla bağlandığında ya da yetkilendirmenin kimlik bilgisinin içine gömülmesini istediğinizde öne çıkar.

Statik cihaz başına kimlik bilgileri ise sadeliğin önemli olduğu cihaz filolarında öne çıkar: sınırlı kaynaklara sahip mikrodenetleyiciler, yayıncıya erişimi güvenilir olmayan sahalar ve bir kimlik doğrulama servisi işletmek istemeyen ekipler. Zayıf yanları olan uzun ömürlü sırlar, korumalı depolama ve planlı yenileme ile ele alınır. Yetkilendirme tarafı için MQTT kimlik bilgilerinin nasıl yenileneceğine ve MQTT ACL kavramları yazısındaki tasarım notlarına bakın.

Yönetilen Bir Broker ile Orta Yol

JWT'den beklediğiniz şey çoğunlukla "paylaşılan sır olmaması ve tek bir cihazı hızla devre dışı bırakmanın bir yolu" ise, bunun büyük kısmını token kullanmadan elde edebilirsiniz: her cihaza kendi kimlik bilgisi setini verin, bir client ID'ye bağlayın, korumalı depolamada tutun ve bir takvime göre yenileyin. ConnectMQ gibi bir tam yönetilen MQTT servisi, 8883 ve 8084 portlarında TLS, tekrarlanan başarısız girişlerden sonra IP engelleme ve tenant izolasyonuyla bu modeli kutudan çıktığı gibi sunar. Tarayıcı uygulamaları için broker kimlik bilgilerini backend'inizde tutun ve kullanıcıların backend'inize zaten kullandığınız token sistemiyle kimlik doğrulamasına izin verin.

ConnectMQ ile Başlayın

Bir token yayıncısı işletmeden güçlü cihaz başına kimlik doğrulaması mı istiyorsunuz? app.connectmq.com adresinde kredi kartı gerekmeden ücretsiz bir Serverless bulut MQTT broker oluşturun ve ilk cihazınızı oluşturulmuş kimlik bilgileriyle TLS üzerinden dakikalar içinde bağlayın.

Sık Sorulan Sorular

ConnectMQ, MQTT JWT kimlik doğrulamasını destekliyor mu?

Hayır. ConnectMQ, istemcilerin kimliğini oluşturulmuş kullanıcı adları ve şifrelerle doğrular; her client ID kendisine verilen kimlik bilgilerine bağlıdır. Tenant'lar birbirinden izole edilmiştir.

JWT, bir MQTT bağlantısında nereye konur?

Çoğu broker onu CONNECT'in şifre alanında bekler; bazen kullanıcı adı cihaz ID'si veya sabit bir değer olarak ayarlanır. Bazı MQTT 5 broker'ları token'ları gelişmiş kimlik doğrulama yoluyla da kabul eder.

Oturum sırasında token'ın süresi dolarsa ne olur?

Broker'a bağlıdır. Bazıları yalnızca bağlantı anında doğrular, diğerleri süre dolumunda istemcinin bağlantısını keser; bu nedenle cihazlar token'ın süresi dolmadan önce yenileyip yeniden bağlanmalıdır.

JWT bir şifreden daha mı güvenli?

Kısa ömürlü bir token, çalınan bir kimlik bilgisinin ne kadar süre işe yarayacağını sınırlar, ancak cihazların token almak için yine de uzun vadeli bir sırra ihtiyacı vardır. Genel güvenlik, her iki sırrın nasıl saklandığına ve taşındığına bağlıdır.