Documentation Oracle Cloud Infrastructure

Gestion de l'autorisation à l'aide de l'API

L'API REST des domaines d'identité prend en charge à la fois l'autorisation basée sur un jeton et les signatures de demande OCI. Pour des raisons de sécurité, l'API REST des domaines d'identité n'est pas accessible à l'aide uniquement du nom utilisateur et du mot de passe que vous utilisez pour vous connecter au domaine d'identité. Pour accéder à l'API REST des domaines d'identité, vous avez besoin d'un jeton d'accès OAuth2 ou d'une clé d'API à utiliser pour l'autorisation.

l'API REST des domaines d'identité utilise le protocole OAuth 2.0 pour l'authentification et l'autorisation, et prend en charge les scénarios d'autorisation courants suivants :

  • Serveur Web

  • Mobile

  • Applications JavaScript

La section Autorisation traite des scénarios OAuth 2.0 pris en charge par les domaines d'identité.

Cette section comprend les rubriques suivantes :

Inscription d'une application client

Une application doit être enregistrée en tant que client OAuth 2 à l'aide du domaine d'identité. Les clients OAuth sont des clients HTTP qui peuvent obtenir puis utiliser un jeton d'accès.

Pour utiliser un client OAuth pour accéder à l'API REST des domaines d'identité, procédez comme suit :

  1. Connectez-vous au domaine d'identité à l'aide du nom utilisateur et du mot de passe figurant dans votre courriel de bienvenue.

  2. Créez une application client OAuth et notez l'ID client et la clé secrète client.

    Remarque

    Lorsque vous configurez l'application client OAuth, sélectionnez les rôles d'application à affecter à l'application. Cela permet à votre application d'accéder aux API REST auxquelles chacun des rôles d'application affectés peut accéder. Chaque rôle d'application est associé à des portées qui définissent un niveau d'accès encore plus précis aux opérations d'API. Par exemple, sélectionnez Administrateur de domaine d'identité dans la liste. Toutes les opérations d'API REST disponibles pour l'administrateur de domaine d'identité sont accessibles pour l'application.

  3. Utilisez l'ID client et la clé secrète client pour demander un jeton d'accès au service OAuth IAM.

  4. Incluez le jeton d'accès dans l'en-tête HTTP approprié lorsque vous effectuez des appels d'API REST.

Plus d'informations

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 nécessite :

  • Contrôles de sécurité implémentés sur tous les participants OAuth, notamment le serveur d'autorisation (IAM), le propriétaire de la ressource (utilisateur), le client et les applications de serveur de ressources

  • Confidentialité des informations clés : code, access_token, refresh_token, informations d'identification client et informations d'identification utilisateur

  • Authentification de 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 JSON Web Token (JWT))

  • 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 prendre en charge la révocation de jeton)

  • Utilisation des principes classiques 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.

Chiffrement

  • Utiliser TLS dans les applications client et de 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 de réexécution.

  • Etablir l'authentification du serveur (HTTPS avec validation de l'autorité de certification sécurisé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 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 de type man-in-the-middle.

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

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

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

  • Protéger l'URI de redirection avec HTTPS et la 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 l'hameçonnage de code 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 requis pour leur fonctionnement.

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

  • Fournir un nom et une description significatifs 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 commettre des erreurs lors de l'autorisation du consentement et contribue également à améliorer les rapports d'audit.

  • Fournir une description significative des portées

    La description du périmètre s'affiche sur la page de consentement. Expliquer la portée, que l'utilisateur est sur le point d'accorder, évite de manière compréhensible à l'utilisateur de faire des erreurs pendant l'autorisation et contribue à un meilleur reporting d'audit.

  • Eviter les portées fournies sans consentement

    Pour tirer parti de la transparence et s'appuyer sur le propriétaire de la ressource, fournissez des portées sans autorisation uniquement 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 opportun, 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'exploration d'une clé secrète client compromise.

Propriétaire de la ressource (utilisateur)

  • Informer le propriétaire de la ressource

    L'utilisation du périmètre 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.

  • Connaissance de l'utilisateur

    Enseignez aux utilisateurs comment 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 les pages d'authentification et de consentement apparaissent). Cela réduit le risque d'attaques de phishing et la compromission des informations d'identification utilisateur.

Développement d'applications

  • Protéger les codes, les jetons d'accès, les jetons d'actualisation et les 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, tenez compte des mesures suivantes (entre autres mesures de sécurité) :

    • Ne pas stocker les codes (utiliser le code uniquement pendant l'exécution pour obtenir le jeton d'accès)

    • Conserver les jetons d'accès dans une mémoire non persistante 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 (d'où 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 des demandes intersites et le refus de service.

  • Lecture de jetons à partir du système de fichiers des 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 l'accès non autorisé au périphérique.

  • Implémenter des contrôles pour les appareils clonés et volés avec des applications natives

    Pour réduire les risques de clonage ou de vol d'un appareil doté d'applications natives, 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é des applications avant leur publication

    Testez la sécurité de l'application et de son environnement d'hébergement avant de publier l'application pour 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 incluent, mais 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 moindre privilège lors de la demande de périmètre

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

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

    Un jeton avec des portées étendues é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) d'une partie quelconque (à l'exception du serveur de domaine d'identité dans une demande directe de votre application), validez le jeton JWT en suivant le profil JWT pour les autorisations d'authentification et d'autorisation client OAuth 2.0 et les RFC JWT.

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

    Remarque

    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 de 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 cache des paramètres.

  • Implémenter le protocole TLS 2 voies entre les applications client et de 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 d'emprunt d'identité.

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

  • Empêcher la sélection

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

    Pour les navigateurs plus anciens, les techniques de suppression de trame JavaScript peuvent être utilisées, mais elles peuvent ne pas être efficaces dans tous les navigateurs.

  • Eviter l'utilisation des informations d'identification de mot de passe du propriétaire de la ressource

    Le flux de propriétaire de ressource permet à un client de demander un jeton d'accès à l'aide de l'ID, du mot de passe et des informations d'identification propres au client d'un utilisateur final. 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 (conserve l'anti-modèle UID/mot de passe).

    • Ne présente pas d'écran de consentement pour les demandes de périmètre.

    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 réduit le risque de ne pas protéger le contenu authentifié et de fuite de 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 connectés à 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 à la page Paramètres de requête.