OpenID Notes de mise en œuvre de Connect

Modifier en ligne

IBM® Verify continue d'apporter des améliorations en matière de sécurité à la mise en œuvre d' OpenID Connect en suivant les meilleures pratiques en la matière. La compatibilité avec les versions antérieures sera préservée autant que possible, mais vous devrez modifier certains éléments afin d'améliorer la sécurité.

Modifications apportées à la mise en œuvre d' OpenID Connect

  • Certains messages d'erreur peuvent être mis à jour, mais leur identifiant reste le même. Si l'un de vos processus comporte une logique qui lit les messages de réponse, utilisez plutôt l'identifiant du message.
  • Lorsque l'interface d'autorisation est sollicitée pour obtenir un code d'autorisation ou des jetons, elle peut rediriger l'utilisateur vers une page de connexion ou d'authentification multifactorielle. Dans un navigateur, cette action entraîne plusieurs redirections automatiques. Si votre automatisation des tests s'articule autour de ce flux, veillez à suivre automatiquement les redirections également.
  • Pour les points de terminaison qui renvoient une portée, le fait de ne pas renvoyer de portée ou de renvoyer une chaîne vide est traité de la même manière.
  • Une barre oblique (/) dans une chaîne JSON peut ne pas être échappée. Assurez-vous que votre analyseur JSON prend en charge les deux.
  • Les autorisations API n'apparaissent plus dans la fenêtre de demande de consentement de l'utilisateur. Les autorisations API sont toujours accordées aux jetons générés pour ce client.
  • La spécification autorise l'utilisation du http schéma dans le redirect_uri uniquement si le hostname est localhost ou s'il s'agit des littéraux de boucle de retour IP. Voir OpenID, section « Connect Core » 1.0:, rubrique 3.1.2.1. Demande d'authentification.
  • On ne s'attend pas toujours à ce que les paramètres de requête soient dans le même ordre. Lors du traitement des paramètres de requête, utilisez la bibliothèque appropriée ou mettez en place un mécanisme fiable regex capable de détecter le paramètre quel que soit son ordre.

Évolutions à venir concernant la mise en œuvre d' OpenID Connect

Il n'est pas nécessaire d'apporter de modifications immédiates concernant les points suivants. Il est toutefois fortement recommandé de modifier ces éléments afin de vous assurer que votre implémentation d' OpenID Connect respecte les meilleures pratiques et soit prête à s'adapter aux changements futurs.
  • En règle générale, il est plus sûr d'inclure les paramètres dans le corps de la requête plutôt que dans les paramètres de requête pour les requêtes POST.
  • Le nonce paramètre doit être une valeur aléatoire cryptographique afin qu'il soit impossible à deviner pour les pirates. Assurez-vous qu'il soit suffisamment long et aléatoire. Voir les notes de mise en œuvre de Nonce. Il est recommandé d'utiliser au moins 8 caractères.
  • Le serveur d'autorisation (IBM Verify) génère un code d'autorisation et des jetons pouvant être de n'importe quelle longueur, ce qui pourrait changer à l'avenir pour des raisons de sécurité. Lors de l'enregistrement des jetons, prévoyez une longueur d'au moins 1 024 caractères. La longueur des jetons au format JWT, tels que le jeton d'identification ou le jeton d'accès au format JWT, dépend du contenu du JWT. Le contenu du JWT s'enrichit à mesure que de nouveaux attributs y sont associés.
  • Le type de jeton pour les jetons au porteur n'est pas sensible à la casse; par exemple, « Bearer » ou « bearer ». N'utilisez pas de validation tenant compte de la casse pour cette valeur.
  • Lorsque le processus de renouvellement du jeton d'authentification est exécuté, les nouveaux jetons d'identification ne contiennent pas le nonce d'origine. Le nonce renvoyé par le flux initial sert à atténuer les attaques par rejeu sur les demandes d'autorisation; cette mesure de protection n'est pas requise pour les demandes de jeton suivantes dans le cadre du flux de jeton d'actualisation.
  • Tout comme nonce, le vérificateur de code PKCE doit être une valeur aléatoire d'un point de vue cryptographique et impossible à deviner. Selon les spécifications, le code de vérification doit comporter au moins 43 caractères. Voir la RFC 7636.
  • Utilisez le state paramètre pour empêcher la falsification de requêtes intersites en lui attribuant une valeur impossible à deviner et pouvant être validée. Par exemple, générez un hachage du cookie de session utilisé pour authentifier l'agent utilisateur. Voir la RFC 6749. Il est recommandé d'utiliser au moins 8 caractères.
  • La valeur « aud audience » peut être une chaîne de caractères ou un tableau. En particulier, s'il n'existe qu'une seule valeur pour l'audience, il peut s'agir d'une chaîne de caractères ou d'un tableau contenant une seule chaîne.
  • Le type d'octroi « client-credential » est destiné à générer des jetons d'accès pour les communications entre machines. Ne vous attendez pas à ce que ce type d'autorisation génère un jeton d'identification ni à ce que le jeton d'accès permette d'accéder au userinfo point de terminaison.
  • Le typ paramètre d'en-tête (type) dans le jeton d'identification est facultatif. La partie qui se fie au jeton ne doit pas s'attendre à trouver un typ paramètre d'en-tête dans le jeton d'identification.