Documentation sur Oracle Cloud Infrastructure

Gestion des autorisations à l'aide de l'API

L'API REST des domaines d'identité prend en charge 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 en utilisant uniquement le nom d'utilisateur et le 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

  • Téléphone cellulaire

  • Applications JavaScript

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

Cette section traite des sujets suivants :

Enregistrement 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.

Effectuez les étapes suivantes pour utiliser un client OAuth pour accéder à l'API REST des domaines d'identité :

  1. Connectez-vous au domaine d'identité à l'aide du nom d'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.

    Note

    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 a des portées qui lui sont affectées et qui définissent un niveau d'accès encore plus fin 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 du domaine d'identité seront accessibles à l'application.

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

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

Informations supplémentaires

Recommandations en matière de sécurité

Pour intégrer en toute sécurité vos applications avec des domaines d'identité à l'aide de OAuth, vous devez mettre en oeuvre 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 sécurisée à OAuth nécessite les éléments suivants :

  • Contrôles de sécurité mis en œuvre pour tous les participants OAuth, notamment le serveur d'autorisation (IAM), le responsable de la ressource (utilisateur), le client et les applications du serveur de ressources

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

  • Authentification du serveur établie entre les participants OAuth (pour éviter les attaques d'emprunt d'identité)

  • Validation correcte des informations pour toute demande (en particulier pour les jetons d'accès JSON Web Token (JWT))

  • Utilisation de jetons avec une portée et une temporisation minimales (pour réduire l'exposition en cas de divulgation et pour soutenir la révocation du jeton)

  • Utilisation de principes typiques de sécurité de l'information tels que le privilège minimal

Ressources

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

Note

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

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

Cette page répertorie les recommandations de sécurité les plus pertinentes sous forme de 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 lors de la transmission du code d'autorisation, des jetons d'accès, des jetons d'actualisation, des données d'identification du client et des données d'identification de l'utilisateur, et empêche les attaques de réexécution.

  • Établir l'authentification de serveur (HTTPS avec validation de l'autorité de certification approuvé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 approuvée.

    Si le serveur ne parvient pas à fournir un 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 man-in-the-middle.

    L'authentification du serveur empêche les attaques d'usurpation d'identité, de proxy, de man-in-the-middle et d'hameçonnage pour saisir 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.

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

    Les clients de sécurité critiques peuvent utiliser une assertion de 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 de confiance

    HTTPS et l'utilisation d'une validation approuvée de l'autorité de certification empêchent l'hameçonnage par code d'autorisation et l'emprunt d'identité de session d'utilisateur.

Administration

  • Configurer les applications en suivant le principe du moindre privilège

    Les applications doivent être configurées dans un domaine d'identité avec uniquement les droits minimaux 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'incidence d'une application compromise.

  • Fournir un nom significatif et une description pour les applications

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

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

  • Fournir une description significative pour les portées

    La description de la portée s'affiche dans 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 faire des erreurs lors de l'autorisation et contribue à une meilleure production de rapports d'audit.

  • Éviter les portées fournies sans consentement

    Pour tirer parti de la transparence et s'appuyer sur le responsable 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éduire la temporisation du jeton d'accès et utiliser 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 mettre en oeuvre 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 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 essentielles à la 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 fournit une transparence au responsable de la ressource et empêche les applications de demander des portées qui ne sont pas requises.

  • Détection de l'utilisateur

    Enseignez aux utilisateurs comment protéger leurs données 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 de compromission des informations 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é de l'application) :

    • 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 la mémoire transitoire et limiter leurs autorisations

    • 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 (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 contrefaçon de demande inter-sites et le déni de service.

  • Jetons de lecture à partir du système de fichiers des applications natives

    Les attaquants peuvent essayer d'obtenir un 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 du périphérique pour empêcher l'accès non autorisé au périphérique.

  • 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 l'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 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 comprennent, sans toutefois 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 inter-sites, 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 contenant 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.

    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 n'importe quelle 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 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 mémoire cache des paramètres.

  • Implémenter 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'usurpation 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 de trame 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, 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'UID/mot de passe anti-modèle).

    • 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'autorisation.

  • 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 fuir les données confidentielles dans les mandataires HTTP.

  • Éviter les demandes avec 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 enregistrés dans n'importe quel composant entre des applications telles que les journaux d'application, les serveurs mandataires, 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.