Recommandations de sécurité

Ressources

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

• Cadre d'autorisation OAuth 2.0

• OAuth 2.0 Considérations relatives au modèle de menace et à la sécurité

• Jeton Web JSON (JWT)

• Profil de jeton Web JSON (JWT) pour les autorisations et l'authentification de client OAuth 2.0

Liste de vérification des recommandations de sécurité

Cette page répertorie les recommandations de sécurité les plus pertinentes en tant que liste de vérification, 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 pendant la transmission du code d'autorisation, les jetons d'accès, les jetons d'actualisation, les données d'identification de client et les données d'identification d'utilisateur, et empêche les attaques de réexécution.

• Établir l'authentification du serveur (HTTPS avec validation de l'autorité de certification approuvée)

  L'authentification du 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 approuvée.

  Si le serveur ne fournit pas de certificat approuvé (fourni par une autorité de certification approuvée et avec un nom d'hôte correspondant), la communication est considérée comme une attaque homme-dans-le-moyen.

  L'authentification du serveur empêche les attaques d'usurpation d'identité, de proxy, de man-in-the-middle et de phishing pour capturer les codes d'autorisation, les jetons d'accès, les données d'identification du client et les données d'identification de l'utilisateur.

• Envisagez d'utiliser une assertion approuvée avec des domaines d'identité

  Les clients de sécurité critiques peuvent utiliser une assertion de client avec cryptographie de clé (au lieu d'une clé secrète client) pour l'authentification.

• Protéger l'URI de redirection avec la validation HTTPS et de l'autorité de certification approuvée

  Le protocole HTTPS et l'utilisation d'une validation approuvée par l'autorité de certification empêchent l'hameçonnage pour le "code" des autorisations et l'emprunt d'identité de session d'utilisateur.

Administration

• Configurer les applications selon le principe du moindre privilège

  Les applications doivent être configurées dans un domaine d'identité avec les droits minimums requis pour leur fonctionnement.

  La réduction de la portée, des flux, des types de subvention et des opérations améliore la sécurité et réduit l'impact d'une application compromise.

• Fournir un nom et une description significatifs pour les applications

  Les données de l'application s'affichent pour les utilisateurs dans les pages Mes applications et de consentement.

  L'utilisation de noms d'application et de descriptions significatifs peut empêcher les utilisateurs de commettre des erreurs pendant l'autorisation de consentement et contribue également à améliorer les rapports d'audit.

• Fournir une description pertinente pour les étendues

  La description de l'étendue est affichée dans la page de consentement. Expliquer la portée, que l'utilisateur est sur le point d'accorder, d'une manière compréhensible empêche l'utilisateur de faire des erreurs lors de l'autorisation et contribue à de meilleurs rapports d'audit.

• Éviter les portées fournies sans consentement

  Pour tirer parti de la transparence et compter sur le responsable de la ressource, fournissez des étendues sans autorisation uniquement lorsqu'une portée est obligatoire et que l'utilisateur ne doit pas être en mesure de la refuser.

• Réduire la temporisation du jeton d'accès et utiliser les 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 mettre en oeuvre la révocation en temps opportun, vous pouvez configurer le jeton d'accès avec une durée de vie courte, puis utiliser le jeton d'actualisation pour demander de nouveaux jetons d'accès. Pour effectuer une révocation en temps opportun, vous devez révoquer le jeton d'actualisation.

• Effectuer la rotation des clés secrètes de client de l'application

  Pour les mises en oeuvre critiques en matière de sécurité, mettez en oeuvre une rotation de clé secrète client. Cela réduit le risque d'exploration d'une clé secrète client compromise.

Responsable de la ressource (utilisateur)

• Informer le responsable de la ressource

  L'utilisation de la portée avec consentement assure la transparence au responsable de la ressource et empêche les applications de demander des portées qui ne sont pas requises.

• Détection d'utilisateur

  Apprenez aux utilisateurs à protéger leurs données d'identification et à identifier le client, l'application du 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 d'hameçonnage et la compromission des données d'identification des utilisateurs.

Application Development

• Protéger les codes, les jetons d'accès, les jetons d'actualisation et les données d'identification de client

  Les applications doivent préserver la confidentialité des codes, des jetons d'accès, des jetons d'actualisation et des données d'identification du client. Lorsque vous développez l'application, tenez compte des mesures suivantes (entre autres mesures de sécurité des applications) :

  • Ne stockez pas de codes (utilisez le code uniquement lors de l'exécution pour obtenir le jeton d'accès)

  • Conserver les jetons d'accès en mémoire temporaire et limiter leurs droits

  • Stocker les jetons d'actualisation et les données d'identification de client dans des endroits sécurisés accessibles uniquement par l'application

• Protéger l'URL de redirection

  L'URL de redirection (à 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 contrefaçon de demande inter-sites et le déni de service.

• Lire les jetons à partir du système de fichiers des applications natives

  Les attaquants peuvent essayer d'obtenir l'accès au système de fichiers sur l'appareil et 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 de l'appareil pour empêcher l'accès non autorisé à l'appareil.

• Mettre en oeuvre des contrôles pour les appareils clonés et volés avec des 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évoquer 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, sans s'y limiter, l'accès indirect aux bases de données et au stockage des applications, le détournement de sélection, les scripts intersites, l'injection de script/SQL et les flux de confidentialité des informations sur l'application.

• Appliquer le moins de privilèges lors de la demande d'étendue

  Les applications client doivent demander des jetons qui contiennent uniquement des étendues 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 étendues étendues étendues peut augmenter l'impact sur la sécurité lorsqu'un jeton est compromis.

  Voir Portées 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é.

• Valider les jetons JWT

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

  Voir Validation de jeton pour plus d'informations sur la validation du jeton.

  Note
  
  Les serveurs de ressources ne doivent traiter les informations qu'une fois la validation JWT complète effectuée.

• Recevoir correctement les jetons JWT

  Les applications du serveur de ressources doivent recevoir le jeton d'accès en utilisant uniquement l'en-tête Authorization: bearer <token> pour éviter les menaces liées à la mise en mémoire cache des paramètres.

• Implémenter le protocole TLS à 2 voies entre les applications client et serveur de ressources

  Pour les applications critiques en matière de sécurité, vous pouvez mettre en oeuvre 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 d'emprunt d'identité.

  N'écrivez pas les applications qui collectent des informations d'authentification directement auprès des utilisateurs.

• Empêcher le Select-Jacking

  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 suppression d'images JavaScript peuvent être utilisées, mais peuvent ne pas être efficaces dans tous les navigateurs.

• Éviter l'utilisation des données d'identification par mot de passe du responsable de la ressource

  Le flux du responsable de la ressource permet à un client de demander un jeton d'accès à l'aide de l'ID utilisateur final, du mot de passe et des données 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 de subvention.

• Utiliser l'en-tête Cache-Control="no-store"

  Cet en-tête réduit le risque de ne pas protéger le contenu authentifié et de fuite de données confidentielles dans les mandataires HTTP.

• Éviter les demandes avec des informations sensibles envoyées à l'aide de paramètres d'URL

  Les paramètres d'URL (utilisés sur les demandes GET) peuvent être enregistré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 de réseau.

  Les domaines d'identité mettent en oeuvre d'autres points d'extrémité REST de recherche à l'aide de la fonction POST qui traite ce risque. Pour plus d'informations, voir la page Paramètres d'interrogation.