Sécurité OAuth : Guide du développeur

OAuth 2.0 est la norme de l'industrie pour l'autorisation déléguée. Elle permet aux applications tierces d'accéder à des ressources limitées au nom d'un utilisateur sans exposer ses identifiants. Cependant, la mise en œuvre d'OAuth de manière sécurisée est complexe. Ce guide offre une analyse approfondie des meilleures pratiques de sécurité OAuth pour les développeurs, couvrant les vulnérabilités courantes et les stratégies d'atténuation.

Point clé 1 La sécurité OAuth ne concerne pas uniquement le fournisseur OAuth ; il s'agit d'une responsabilité partagée entre le fournisseur, l'application cliente et le serveur de ressources.

Point clé 2 La validation correcte des URI de redirection est essentielle pour empêcher les attaques d'interception de code d'autorisation.

Point clé 3 L'utilisation de jetons d'accès de courte durée et de la rotation des jetons de rafraîchissement réduit considérablement l'impact d'une compromission de jeton.

Point clé 4 L'audit régulier de votre implémentation OAuth et la mise à jour des meilleures pratiques de sécurité sont essentiels.

Comprendre les flux OAuth et les vulnérabilités

OAuth 2.0 définit plusieurs types d'octroi, chacun adapté à différents scénarios d'application. Les plus courants sont :

• Octroi de code d'autorisation : Utilisé pour les applications web et mobiles où le client peut stocker en toute sécurité un secret client.
• Octroi implicite : (Obsolète) Utilisé pour les applications monopages (SPA) mais est moins sécurisé en raison de l'exposition des jetons d'accès dans l'URL.
• Octroi d'identifiants de mot de passe du propriétaire de la ressource : (Déconseillé) Nécessite que le client collecte le nom d'utilisateur et le mot de passe de l'utilisateur, ce qui pose un risque pour la sécurité.
• Octroi d'identifiants client : Utilisé pour l'authentification de machine à machine où aucun contexte utilisateur n'est disponible.

Plusieurs vulnérabilités peuvent survenir pendant le flux OAuth :

• Interception du code d'autorisation : Les attaquants redirigent les utilisateurs vers un site malveillant qui ressemble au serveur d'autorisation, dérobant le code d'autorisation.
• Manipulation de l'URI de redirection : Exploitation des URI de redirection mal configurés pour envoyer des codes d'autorisation à des serveurs contrôlés par des attaquants.
• Falsification de requête intersite (CSRF) : Les attaquants incitent les utilisateurs à autoriser une application malveillante.
• Vol de jeton : Compromission des jetons d'accès ou des jetons de rafraîchissement en raison de vulnérabilités de stockage ou d'interception réseau.
• Usurpation d'identité du client : Les attaquants utilisant un ID client et un secret compromis pour accéder aux ressources.

Sécuriser votre implémentation OAuth

L'atténuation de ces vulnérabilités nécessite une approche à plusieurs niveaux :

1. Validation de l'URI de redirection

Validez strictement les URI de redirection. N'autorisez que les URI de redirection préenregistrés et explicitement définis. Mettez en œuvre une approche de liste blanche et évitez les modèles génériques. Assurez-vous que le schéma de l'URI de redirection (http ou https) est également validé. OAuth 2.0 RFC 6749 section 3.1.2 souligne l'importance de la validation de l'URI de redirection.

2. Paramètre d'état et Nonce

Utilisez le paramètre state pour prévenir les attaques CSRF. Générez une valeur state cryptographiquement aléatoire avant de rediriger vers le serveur d'autorisation et vérifiez-la lors de la réception du rappel. Envisagez également d'utiliser un paramètre nonce pour une sécurité accrue.

3. PKCE (Proof Key for Code Exchange)

Mettez en œuvre PKCE, en particulier pour les clients publics (par exemple, applications mobiles, SPA) qui ne peuvent pas stocker en toute sécurité un secret client. PKCE ajoute une couche de protection supplémentaire en garantissant que seule l'application qui a initié la demande d'autorisation peut échanger le code d'autorisation contre un jeton d'accès.

// Exemple de code PKCE (simplifié)
// Générer un vérificateur de code
let codeVerifier = generateRandomString();
// Générer un défi de code à partir du vérificateur de code
let codeChallenge = generateCodeChallenge(codeVerifier);
// Inclure codeChallenge et codeChallengeMethod dans la demande d'autorisation
// ...
// Échanger le code d'autorisation contre un jeton d'accès, en fournissant le vérificateur de code
// ...

4. Gestion des jetons

Utilisez des jetons d'accès de courte durée pour minimiser l'impact d'une compromission de jeton. Mettez en œuvre la rotation des jetons de rafraîchissement, où un nouveau jeton de rafraîchissement est émis à chaque actualisation du jeton d'accès, invalidant le jeton de rafraîchissement précédent. Stockez les jetons en toute sécurité en utilisant le cryptage et les contrôles d'accès. Ne stockez jamais de jetons dans le code côté client.

Considérations sur la sécurité de l'API

La sécurisation de vos points de terminaison d'API est tout aussi cruciale que la sécurisation du flux OAuth. Mettez en œuvre les meilleures pratiques suivantes :

• Validation des jetons : Validez soigneusement les jetons d'accès avant d'accorder l'accès aux ressources. Vérifiez la signature du jeton, la date d'expiration et le public (aud claim).
• Validation des étendues : Appliquez les restrictions d'étendue. Assurez-vous que le jeton d'accès dispose des étendues nécessaires pour accéder à la ressource demandée.
• Limitation du débit : Mettez en œuvre une limitation du débit pour empêcher les abus et les attaques par déni de service.
• Validation des entrées : Validez toutes les entrées de l'API pour prévenir les attaques par injection.
• HTTPS uniquement : Appliquez HTTPS pour toutes les communications API.

Comment Didit aide

Didit fournit des capacités robustes de vérification de l'identité et d'évaluation des risques qui complètent la sécurité OAuth. En intégrant Didit à votre flux OAuth, vous pouvez :

• Vérifier l'identité de l'utilisateur avant d'émettre des jetons d'accès.
• Détecter les activités frauduleuses et empêcher l'accès non autorisé.
• Améliorer la sécurité de l'API avec un contrôle d'accès basé sur les risques.
• Respecter les exigences réglementaires relatives à la vérification de l'identité et à la lutte contre le blanchiment d'argent (LCB).

Le module de dépistage des PEP de Didit peut être intégré pour vérifier les utilisateurs par rapport aux listes de surveillance mondiales pendant le processus OAuth, ajoutant une couche de sécurité supplémentaire.

Prêt à démarrer ?

La mise en œuvre d'une sécurité OAuth robuste est essentielle pour protéger votre application et les données de vos utilisateurs. En suivant les meilleures pratiques décrites dans ce guide, vous pouvez réduire considérablement le risque de vulnérabilités liées à OAuth.

Ressources :

• Tarifs Didit
• Documentation Didit
• OAuth 2.0 RFC 6749