Entwicklung eines Autorisierungsdiensts auf Rust: Tokens, Verschlüsselung, Redis

Sichere Rust-Authentifizierungsservice entwickeln: Tokens, Verschlüsselung und Redis

Die Erstellung eines robusten Authentifizierungsdiensts in Rust erfordert ein solides Verständnis von Kryptografie, Token-Management und cleveren Abstraktionen. Dieser Artikel taucht in praktische Erfahrungen ein und deckt die Generierung, Validierung von JWT- und opaken Tokens sowie deren Speicherung in Redis ab.

Token-Architektur und -Generierung

Der Service verwendet zwei Token-Typen: Access-Tokens (JWT) für kurzlebige Sitzungen und Refresh-Tokens (opak) für nahtlose Verlängerungen ohne erneute Authentifizierung.

JWT-Tokens nutzen asymmetrische Verschlüsselung mit dem RS256-Algorithmus, der einen privaten Schlüssel zum Signieren und einen öffentlichen Schlüssel zur Verifikation benötigt. Opake Tokens sind zufällige Base64-Strings ohne lesbare Informationen für den Client, was die Sicherheit erhöht.

Komponenten für Schlüsselerstellung

• JwtTokenProvider: Trait für JWT-Generierung mit Claims und privatem Schlüssel.
• OpaqueTokenProvider: Trait für opake Tokens über Zufallsbytes.
• Claims-Struktur: Enthält Standardfelder wie sub (Benutzer-ID), jti (Token-ID), iat (ausgestellt am) und exp (Ablauf).

Beispielimplementierung für JwtTokenProvider:

pub trait IJwtTokenProvider {
    type Claims: Send + Sync;
    type Error;
    fn generate(&self, claims: &Self::Claims, pem: &str) -> Result<String, Self::Error>;
}

Token-Verifikation und -Validierung

Die JWT-Verifikation verwendet den öffentlichen Schlüssel, um kompromittierte private Schlüssel zu blockieren. Der IJwtTokenValidator-Trait übernimmt Signaturprüfungen und Token-Integrität.

Validierungs-Highlights

• PEM-Format: Schlüssel werden in PEM-Dateien gespeichert, die Zertifikate und Vertrauensketten unterstützen.
• Verschlüsselungsalgorithmen: Unterstützt symmetrische (z. B. HS256) und asymmetrische (z. B. RS256), wobei letztere für bessere Sicherheit bevorzugt werden.
• Claims-Konvertierung: Domänen-Claim-Modelle werden für Bibliotheks-Kompatibilität angepasst, z. B. DateTime zu usize.

Beispielcode für Verifikation:

pub trait IJwtTokenValidator {
    type Claims: Send + Sync;
    type Error;
    fn verify(&self, token: &str, pem: &str) -> Result<Self::Claims, Self::Error>;
}

Token-Speicherung und -Orchestrierung

TokenManager und KeyManager kümmern sich um Tokens und Schlüssel. TokenManager generiert, verifiziert und speichert Tokens in Redis mit flexiblen Abstraktionen.

RedisIO-Implementierung

RedisIO vereinfacht Speicheroperationen mit setex, get und delete-Methoden, reduziert Boilerplate und verbessert die Lesbarkeit.

Beispiel:

impl<Storage> RedisIO<Storage>
where Storage: redis::AsyncCommands + Send + Sync
{
    pub async fn setex(&mut self, key: &str, data: &str, exp: u64) -> Result<(), redis::RedisError> {
        self.redis_storage.set_ex::<&str, String, (>(&key, data.to_string(), exp).await?;
        Ok(())
    }
}

TokenManager-Features

Verwendet Generics für Provider und Validatoren, um einfache Austausche zu ermöglichen. Wichtige Methoden:

• generate_pair: Erstellt Access-/Refresh-Paar, speichert in Redis mit TTL.
• verify_access: Prüft Existenz und Integrität des Access-Tokens.

Nutzungsbeispiel:

pub async fn generate_pair(&mut self, claims: &Claims, pem: &str) -> Result<(String, String), TokenManagerError> {
    let access_token = self.access_provider.generate(&claims, &pem)?;
    let refresh_token = self.refresh_provider.generate();
    // Redis-Speicherlogik
    Ok((access_token, refresh_token))
}

Wichtige Erkenntnisse

• RS256-Asymmetrische Verschlüsselung für JWTs ist sicherer als symmetrische Methoden.
• Opake Tokens als zufällige Base64-Strings widerstehen Fälschungen.
• Traits erleichtern Tests und Austausche.
• Redis-TTL-Speicherung managt Sitzungen effizient und entlastet die Datenbank.
• Strenge Trennung von privaten/öffentlichen Schlüsseln verhindert Sicherheitslücken.

Häufige Fallstricke und Lösungen

In der Entwicklung zeigten sich Probleme:

• Base64-Aufblähung: 32 Bytes werden zu 43, was Speicherfehler verursachen kann.
• Schlüsselmissbrauch: Private Schlüssel für Verifikation zu verwenden ist tabu.
• Typkonflikte: DateTime zu usize erfordert Validierung.

Lösungen:

• Testen von Randfällen mit variierenden Datengrößen.
• Strenge Prüfungen für Schlüsseltypen/Formate durchsetzen.
• Bewährte JWT-/Krypto-Bibliotheken nutzen.

— Editorial Team