Recommandations de sécurité

Pour intégrer en toute sécurité vos applications aux domaines d'identité à l'aide de OAuth, vous devez implémenter les contrôles de sécurité recommandés par la norme.

Les contrôles de sécurité peuvent être considérés comme obligatoires ou facultatifs en fonction des exigences de confidentialité, d'intégrité et de disponibilité de votre application.

Une intégration OAuth sécurisée requiert les éléments suivants :

Contrôles de sécurité implémentés sur tous les participants OAuth, y compris le serveur d'autorisation (IAM), le propriétaire de la ressource (utilisateur), le client et les applications du serveur de ressources
Confidentialité des informations clés : code, access_token, refresh_token, informations d'identification client et informations d'identification utilisateur
Authentification du serveur établie entre les participants OAuth (pour éviter les attaques par emprunt d'identité)
Validation des informations appropriées pour toute demande (en particulier pour les jetons d'accès JWT (JSON Web Token))
Utilisation de jetons avec des portées minimales et un délai d'expiration (pour réduire l'exposition en cas de divulgation et pour soutenir la révocation du jeton)
Utilisation de principes types de sécurité des informations, tels que le moindre privilège

Ressources

Pour plus d'informations sur la sécurité OAuth, accédez aux liens suivants :

Remarque

Nous vous recommandons de surveiller la sécurité de manière proactive afin de pouvoir identifier rapidement les nouvelles menaces de sécurité.

Liste de contrôle des recommandations de sécurité

Cette page répertorie les recommandations de sécurité les plus pertinentes sous forme de liste de contrôle, afin que vous puissiez valider la sécurité de votre application et traiter les éléments de sécurité en fonction de vos attentes.

cryptage

Utiliser TLS dans les applications client et serveur de ressources

L'utilisation de TLS avec toutes les applications assure la confidentialité des communications entre le domaine d'identité, les propriétaires de ressources, les applications client et les applications de serveur de ressources. Cela empêche l'écoute électronique lors de la transmission du code d'autorisation, des jetons d'accès, des jetons d'actualisation, des informations d'identification client et des informations d'identification utilisateur, et empêche les attaques par réexécution.
Etablir l'authentification du serveur (HTTPS avec validation d'autorité de certification sécurisée)

L'authentification de serveur permet aux clients, aux serveurs de ressources et aux propriétaires de ressources d'établir une communication entre eux et avec un domaine d'identité après avoir vérifié le certificat public par rapport à l'autorité de certification sécurisée.

Si le serveur ne parvient pas à fournir un certificat sécurisé (fourni par une autorité de certification de confiance et avec un nom d'hôte correspondant), la communication est considérée comme une attaque man-in-the-middle.

L'authentification du serveur empêche l'usurpation, le proxy, les attaques man-in-the-middle et l'hameçonnage pour capturer les codes d'autorisation, les jetons d'accès, les informations d'identification client et les informations d'identification utilisateur.
Envisager l'utilisation d'une assertion sécurisée avec des domaines d'identité

Les clients de sécurité critiques peuvent utiliser une assertion client avec la cryptographie par clé (au lieu d'une clé secrète client) pour l'authentification.
Protection de l'URI de redirection avec HTTPS et validation de l'autorité de certification sécurisée

HTTPS et l'utilisation de la validation d'autorité de certification sécurisée empêchent le phishing sur l'autorisation et l'emprunt d'identité de session utilisateur.

Administration

Configuration des applications suivant le principe du moindre privilège

Les applications doivent être configurées dans un domaine d'identité avec uniquement les droits minimum nécessaires à leur fonctionnement.

La réduction de la portée, des flux, des types d'octroi et des opérations améliore la sécurité et réduit l'impact d'une application compromise.
Fournir un nom et une description pertinents pour les applications

Les informations de l'application s'affichent pour les utilisateurs sous Mes applications et les pages de consentement.

L'utilisation de noms et de descriptions d'application significatifs peut empêcher les utilisateurs de faire des erreurs lors de l'autorisation de consentement et contribue également à un meilleur reporting d'audit.
Fournir une description pertinente pour les portées

La description de la portée s'affiche sur la page de consentement. Expliquer la portée, que l'utilisateur est sur le point d'accorder, de manière compréhensible, empêche l'utilisateur de commettre des erreurs lors de l'autorisation et contribue à un meilleur reporting d'audit.
Eviter les portées fournies sans consentement

Pour tirer parti de la transparence et compter sur le propriétaire de la ressource, ne fournissez des portées sans autorisation que lorsqu'une portée est obligatoire et que l'utilisateur ne doit pas être en mesure de la refuser.
Réduction du délai d'expiration du jeton d'accès et utilisation des jetons d'actualisation

Les domaines d'identité prennent en charge JWT, un jeton d'accès qui peut être validé dans les serveurs de ressources sans vérifier le jeton dans le domaine d'identité. Pour cette raison, les jetons d'accès de longue durée ne peuvent pas être facilement révoqués.

Pour implémenter la révocation en temps voulu, vous pouvez configurer le jeton d'accès avec une courte durée de vie, puis utiliser le jeton d'actualisation pour demander de nouveaux jetons d'accès. Pour effectuer une révocation en temps voulu, vous devez révoquer le jeton d'actualisation.
Rotation des clés secrètes client de l'application

Pour les implémentations critiques en matière de sécurité, implémentez une rotation de clé secrète client. Cela réduit le risque d'obtenir un secret client compromis exploré.

Propriétaire de ressource (utilisateur)

Informer le propriétaire de la ressource

L'utilisation du champ d'application avec consentement assure la transparence au propriétaire de la ressource et empêche les applications de demander des portées qui ne sont pas requises.
Sensibilisation des utilisateurs

Apprenez aux utilisateurs à protéger leurs informations d'identification et à identifier le client, l'application de serveur de ressources et la légitimité du domaine d'identité (en particulier lorsque des pages d'authentification et de consentement apparaissent). Cela réduit le risque d'attaques de phishing et la compromission des informations d'identification des utilisateurs.

Développement d'applications

Protection des codes, jetons d'accès, jetons d'actualisation et informations d'identification client

Les applications doivent préserver la confidentialité des codes, des jetons d'accès, des jetons d'actualisation et des informations d'identification client. Lorsque vous développez l'application, prenez en compte les mesures suivantes (entre autres mesures de sécurité) :
- Ne stockez pas les codes (utilisez le code uniquement lors de l'exécution pour obtenir le jeton d'accès)
- Conserver les jetons d'accès dans la mémoire transitoire et limiter leurs autorisations
- Stocker les jetons d'actualisation et les informations d'identification client dans des emplacements sécurisés accessibles uniquement par l'application
Protéger l'URL de réacheminement

L'URL de réacheminement (à partir de laquelle le domaine d'identité extrait le code d'autorisation) est considérée comme un composant clé pour la sécurité OAuth. Soyez prudent lorsque vous définissez cette URL pour éviter les menaces telles que la falsification de demandes intersites et le refus de service.
Lecture de jetons à partir du système de fichiers d'applications natives

Les pirates peuvent essayer d'obtenir l'accès au système de fichiers sur l'appareil et de lire les jetons d'actualisation à l'aide d'une application malveillante. Pour réduire ce risque, stockez les clés secrètes dans un stockage sécurisé et utilisez le verrouillage du périphérique pour empêcher tout accès non autorisé au périphérique.
Implémenter des contrôles pour les appareils clonés et volés à l'aide d'applications natives

Pour réduire les risques lorsqu'un appareil doté d'applications natives est cloné ou volé, utilisez le verrouillage de l'appareil pour empêcher tout accès non autorisé et révoquez les jetons d'actualisation.
Valider la sécurité de l'application avant la publication

Testez la sécurité de l'application et de son environnement d'hébergement avant de publier l'application afin de réduire les vulnérabilités. Les menaces liées à l'hébergement et au développement d'applications ne sont pas traitées par les domaines d'identité. Ces menaces comprennent, entre autres, l'accès indirect aux bases de données et au stockage des applications, le détournement de clics, les scripts intersites, l'injection de script/SQL et les flux de confidentialité des informations sur l'application.
Appliquer le moindre privilège lors de la demande de portée

Les applications client doivent demander des jetons qui contiennent uniquement des portées qu'elles utiliseront éventuellement ou réellement.

L'utilisation de urn:opc:idm:__myscopes__ scope, bien que pratique, peut extraire plus de jetons que nécessaire par l'application client.

Un jeton avec des portées étendues peut augmenter l'impact sur la sécurité lorsqu'un jeton est compromis.

Pour plus d'informations sur l'utilisation du paramètre de portée et d'un jeton d'accès pour accorder différents niveaux d'accès aux domaines d'identité, reportez-vous à Portées.
Valider les jetons JWT

Lors de la réception d'un jeton d'accès (JWT) de n'importe quelle partie (à l'exception du serveur de domaine d'identité dans une demande directe de votre application), validez le jeton JWT en suivant les documents RFC Profil JWT pour les autorisations et l'authentification client OAuth 2.0 et JWT.

Pour plus d'informations sur la validation du jeton, reportez-vous à Validation de jeton.

Remarque

Les serveurs de ressources doivent traiter les informations uniquement après la validation complète du jeton JWT.
Recevoir correctement les jetons JWT

Les applications de serveur de ressources doivent recevoir le jeton d'accès à l'aide de l'en-tête Authorization: bearer <token> uniquement pour éviter les menaces liées à la mise en cache des paramètres.
Implémenter le protocole TLS sur 2 critères entre les applications client et serveur de ressources

Pour les applications critiques en matière de sécurité, vous pouvez implémenter un protocole TLS à 2 voies entre les applications client et serveur de ressources afin de réduire le risque de déni de service (DoS) et d'attaques par usurpation d'identité.

N'écrivez pas d'applications qui collectent des informations d'authentification directement auprès des utilisateurs.
Empêcher le blocage des clics

Pour les navigateurs plus récents, évitez iFrames lors de l'autorisation en imposant l'utilisation de l'en-tête X-FRAME-OPTIONS.

Pour les navigateurs plus anciens, les techniques de création de trames JavaScript peuvent être utilisées, mais peuvent ne pas être efficaces dans tous les navigateurs.
Eviter l'utilisation des informations d'identification de mot de passe de propriétaire de ressource
Le flux de propriétaire de ressource permet à un client de demander un jeton d'accès à l'aide de l'ID d'un utilisateur final, du mot de passe et des informations d'identification du client. Ce type de subvention présente un risque plus élevé car :
- Il est chargé de collecter les informations d'identification de l'utilisateur sur l'application client (maintient l'anti-modèle UID/mot de passe).
- Ne présente pas d'écran de consentement pour les demandes de portée.
Sauf pour des raisons de migration, évitez d'utiliser ce type d'octroi.
Utiliser l'en-tête Cache-Control="no-store"

Cet en-tête minimise le risque de ne pas protéger le contenu authentifié et de ne pas divulguer les données confidentielles dans les proxies HTTP.
Eviter les demandes contenant des informations sensibles envoyées à l'aide des paramètres d'URL

Les paramètres d'URL (utilisés sur les demandes GET) peuvent être journalisés dans n'importe quel composant entre des applications telles que les journaux d'application, les serveurs proxy, les pare-feu et les composants en périphérie réseau.

Les domaines d'identité implémentent d'autres adresses REST de recherche à l'aide du POST qui résout ce risque. Pour plus d'informations, reportez-vous à Paramètres de requête.