Développement d'un service d'autorisation sur Rust : tokens, chiffrement, Redis

Développer un service d'authentification sécurisé en Rust : tokens, chiffrement et Redis

Créer un service d'authentification robuste en Rust exige une solide maîtrise de la cryptographie, de la gestion des tokens et d'abstractions intelligentes. Cet article partage une expérience pratique, couvrant la génération, la validation de tokens JWT et opaques, ainsi que leur stockage en Redis.

Architecture et génération des tokens

Le service utilise deux types de tokens : d'accès (JWT) pour des sessions courtes et de rafraîchissement (opaques) pour des renouvellements fluides sans réauthentification.

Les tokens JWT reposent sur un chiffrement asymétrique avec l'algorithme RS256, nécessitant une clé privée pour la signature et une clé publique pour la vérification. Les tokens opaques sont des chaînes aléatoires en base64 sans informations lisibles par le client, renforçant la sécurité.

Composants de génération de clés

• JwtTokenProvider : Trait pour la génération de JWT à partir de claims et d'une clé privée.
• OpaqueTokenProvider : Trait pour les tokens opaques via des octets aléatoires.
• Structure Claims : Inclut des champs standards comme sub (ID utilisateur), jti (ID token), iat (émission) et exp (expiration).

Exemple d'implémentation JwtTokenProvider :

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

Vérification et validation des tokens

La vérification JWT utilise la clé publique pour bloquer les clés privées compromises. Le trait IJwtTokenValidator gère les contrôles de signature et l'intégrité des tokens.

Points forts de la validation

• Format PEM : Clés stockées en fichiers PEM, compatibles avec certificats et chaînes de confiance.
• Algorithmes de chiffrement : Support symétrique (ex. HS256) et asymétrique (ex. RS256), préférant ce dernier pour une sécurité optimale.
• Conversion des claims : Modèles de claims adaptés à la bibliothèque, comme DateTime vers usize.

Exemple de code de vérification :

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

Stockage et orchestration des tokens

TokenManager et KeyManager gèrent tokens et clés. TokenManager génère, vérifie et stocke en Redis via des abstractions flexibles.

Implémentation RedisIO

RedisIO simplifie les opérations de stockage avec setex, get et delete, réduisant le code redondant et améliorant la lisibilité.

Exemple :

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(())
    }
}

Fonctionnalités de TokenManager

Utilise des génériques pour providers et validateurs, facilitant les échanges. Méthodes clés :

• generate_pair : Crée un couple accès/rafraîchissement, stocke en Redis avec TTL.
• verify_access : Valide existence et intégrité du token d'accès.

Exemple d'usage :

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();
    // Logique de stockage Redis
    Ok((access_token, refresh_token))
}

Points clés à retenir

• Chiffrement asymétrique RS256 pour JWT surpasse les méthodes symétriques en sécurité.
• Tokens opaques sous forme de chaînes base64 aléatoires résistent à la contrefaçon.
• Les traits facilitent tests et échanges.
• Stockage Redis avec TTL gère les sessions efficacement, soulageant la base de données.
• Séparation stricte clé privée/publique prévient les failles.

Pièges courants et solutions

Le développement a révélé des problèmes :

• Gonflement base64 : 32 octets deviennent 43, risquant des erreurs de stockage.
• Mauvaise gestion des clés : Utiliser une clé privée pour vérification est interdit.
• Incompatibilités de types : DateTime vers usize nécessite validation.

Solutions :

• Tester les cas limites avec tailles variées.
• Imposer des contrôles stricts sur types/formats de clés.
• S'appuyer sur des bibliothèques JWT/crypto éprouvées.

— Editorial Team