Restrictions et grandes lignes des URI de redirection (URL de réponse)

Pour connecter un utilisateur, votre application doit envoyer une demande de connexion au point de terminaison d’autorisation Microsoft Entra avec un URI de redirection spécifié comme paramètre. L’URI de redirection est une fonctionnalité de sécurité critique qui garantit que le serveur d’authentification Microsoft Entra envoie uniquement des codes d’autorisation et des jetons d’accès au destinataire prévu. Cet article présente les fonctionnalités et restrictions des URI de redirection dans la plateforme d’identités Microsoft.

Qu’est-ce qu’un URI de redirection ?

Un URI de redirection, ou URL de réponse, correspond à l’emplacement vers lequel le serveur d’authentification Microsoft Entra envoie l’utilisateur une fois l’application correctement autorisée et un jeton d’accès attribué. Pour connecter un utilisateur, votre application doit envoyer une demande de connexion avec un URI de redirection spécifié comme paramètre. Par conséquent, une fois que l’utilisateur s’est connecté, le serveur d’authentification redirige l’utilisateur et émet un jeton d’accès vers l’URI de redirection spécifié dans la demande de connexion.

Pourquoi les URI de redirection doivent-ils être ajoutés à une inscription d’application ?

Pour des raisons de sécurité, le serveur d’authentification ne redirige pas les utilisateurs ni n’envoie de jetons à un URI qui n’est pas ajouté à l’inscription de l’application. Les serveurs de connexion Microsoft Entra ne redirige des utilisateurs et n’envoie des jetons qu’aux URI de redirection ajoutés à une inscription d’application. Si l’URI de redirection spécifié dans la demande de connexion ne correspond pas aux URI de redirection ajoutés dans votre application, vous recevez un message d’erreur tel que AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application.

Si vous souhaitez découvrir plus d’informations sur les codes d’erreur, consultez Codes d’erreur d’authentification et d’autorisation Microsoft Entra.

Dois-je ajouter un URI de redirection à une inscription d’application ?

L'ajout d’un URI de redirection à une inscription d’application dépend du protocole d’autorisation utilisé par votre application. Vous devez ajouter des URI de redirection appropriés à votre inscription d’application si votre application utilise les protocoles d’autorisation suivants :

• Flux du code d’autorisation OAuth 2.0
• Flux d’informations d’identification du client OAuth 2.0
• Flux de l’octroi implicite OAuth 2.0
• OpenID Connect
• Protocole SAML d’authentification unique

Vous n’avez pas besoin d’ajouter d’URI de redirection à votre inscription d’application si votre application utilise les protocoles ou fonctionnalités d’autorisation suivants.

• Authentification native
• Flux du code d’appareil OAuth 2.0
• Flux OAuth 2.0 On-Behalf-Of
• Flux d’informations de mot de passe du propriétaire de la ressource OAuth 2.0
• Flux d’authentification intégré Windows
• Fournisseur d’identité (IdP) SAML 2.0 pour l’authentification unique

À quelle plateforme dois-je ajouter mes URI de redirection ?

Si l’application que vous générez contient un ou plusieurs URI de redirection dans votre inscription d’application, vous pouvez activer une configuration de flux client publique. Les tableaux suivants fournissent des conseils sur le type d’URI de redirection que vous devez ou ne devez pas ajouter en fonction de la plateforme sur laquelle vous générez votre application.

Configuration des URI de redirection d’application web

Configuration des URI de redirection d’application de bureau et mobile

Si vous générez une application iOS en tirant parti de l’une des méthodes suivantes, utilisez une plateforme d’applications de bureau et mobiles afin d’ajouter un URI de redirection :

• Applications iOS utilisant des Kits de développement logiciel (SDK) hérités (ADAL)
• Applications iOS utilisant des Kits de développement logiciel (SDK) open source (AppAuth)
• Applications iOS utilisant une technologie interplateforme que nous ne prenons pas en charge (Flutter)
• Applications iOS implémentant directement nos protocoles OAuth
• Applications macOS utilisant une technologie interplateforme que nous ne prenons pas en charge (Electron)

Applications n’exigeant pas d’URI de redirection

Quelles sont les restrictions des URI de redirection pour des applications Microsoft Entra ?

Le modèle d’application Microsoft Entra spécifie les restrictions suivantes pour rediriger des URI :

• Les URI de redirection doivent commencer par le schéma https, avec des exceptions pour certaines URI de redirection localhost.

• Les URI de redirection respectent la casse et doivent correspondre à la casse du chemin d’accès de l’URL de votre application en cours d’exécution.

  Exemples :

  • Si votre application comprend .../abc/response-oidc dans son chemin d’accès, ne spécifiez pas .../ABC/response-oidc dans l’URI de redirection. Étant donné que le navigateur web considère que les chemins respectent la casse, les cookies associés à .../abc/response-oidc peuvent être exclus s’ils sont redirigés vers l’URL .../ABC/response-oidc qui ne correspond pas à la casse.

• Les URI de redirection non configurés avec un segment de chemin d’accès sont retournés avec une barre oblique finale (« / ») dans la réponse. Cela ne s’applique que lorsque le mode de réponse est query ou fragment.

  Exemples :

  • https://contoso.com est retourné comme https://contoso.com/
  • http://localhost:7071 est retourné comme http://localhost:7071/

• Les URI de redirection qui contiennent un segment de chemin d’accès ne sont pas accompagnés d’une barre oblique finale dans la réponse.

  Exemples :

  • https://contoso.com/abc est retourné comme https://contoso.com/abc
  • https://contoso.com/abc/response-oidc est retourné comme https://contoso.com/abc/response-oidc

• Les URI de redirection ne prennent pas en charge les caractères spéciaux : ! $ ' ( ) , ;

• Les URI de redirection ne prennent pas en charge les noms de domaine internationaux

Nombre maximal d’URI de redirection et longueur d’URI

Le nombre maximal d’URI de redirection ne peut pas être augmenté pour des raisons de sécurité. Si votre scénario implique plus d’URI de redirection que la limite maximale autorisée, envisagez l’approche de paramètre d’état suivante en guise de solution. Le tableau suivant indique le nombre maximal d’URI de redirection que vous pouvez ajouter à une inscription d’application dans la plateforme d’identités Microsoft.

Vous pouvez utiliser un maximum de 256 caractères pour chaque URI de redirection que vous ajoutez à une inscription d’application.

URI de redirection dans les objets de principal de service et d’application

• Ajoutez toujours les URI de redirection à l’objet d’application uniquement.
• N’ajoutez jamais de valeurs d’URI de redirection à un principal de service, car ces valeurs peuvent être supprimées lorsque l’objet de principal de service est synchronisé avec l’objet d’application. Cela peut se produire dans le cadre d’une opération de mise à jour qui déclenche une synchronisation entre les deux objets.

Prise en charge des paramètres de requête dans les URI de redirection

Les paramètres de requête sont autorisés dans les URI de redirection pour les applications qui connectent uniquement les utilisateurs avec des comptes professionnels ou scolaires.

Les paramètres de requête ne sont pas autorisés dans les URI de redirection pour toute inscription d’application configurée pour connecter des utilisateurs avec des comptes Microsoft personnels tels que Outlook.com (Hotmail), Messenger, OneDrive, MSN, Xbox Live ou Microsoft 365.

Audience de connexion de l’inscription d’application	Prend en charge les paramètres de requête dans l’URI de redirection
Comptes dans ce répertoire d’organisation uniquement (Contoso uniquement – Locataire unique)
Comptes dans n’importe quel répertoire d’organisation (n’importe quel répertoire Microsoft Entra – Multi-locataire)
Comptes dans n’importe quel répertoire organisationnel (n’importe quel répertoire Microsoft Entra – Multilocataire) et comptes Microsoft personnels (par exemple Skype et Xbox)
Comptes Microsoft personnels uniquement

Schémas pris en charge

HTTPS : le schéma HTTPS (https://) est pris en charge pour tous les URI de redirection basés sur HTTP.

HTTP : le schéma HTTP (http://) est pris en charge uniquement pour les URI localhost et doit être utilisé uniquement pendant le développement et le test de l’application locale active.

Exceptions de Localhost

Selon le document RFC 8252 : sections 8.3 et 7.3, les URI de redirection « loopback » ou « localhost » comportent deux aspects particuliers à prendre en considération :

1. http Les schémas d’URI sont acceptables car la redirection ne quitte jamais l’appareil. Par conséquent, ces deux URI sont acceptables :
   • http://localhost/myApp
   • https://localhost/myApp
2. En raison des plages de ports éphémères souvent nécessaires aux applications natives, le composant de port (par exemple :5001 ou :443) est ignoré pour permettre une correspondance avec un URI de redirection. En conséquence, tous ces URI sont considérés comme équivalents :
   • http://localhost/MyApp
   • http://localhost:1234/MyApp
   • http://localhost:5000/MyApp
   • http://localhost:8080/MyApp

Du point de vue du développement, cela signifie plusieurs choses :

• N’inscrivez pas plusieurs URI de redirection quand seul le port diffère. Le serveur de connexion en choisit un arbitrairement et utilise le comportement associé à cet URI de redirection (par exemple, s’il s’agit d’une redirection de type web, native ou spa).

  Cela est particulièrement important lorsque vous souhaitez utiliser différents flux d’authentification dans la même inscription d’application, par exemple l’octroi d’un code d’autorisation et le flux implicite. Dans le but d’associer le comportement de réponse correct à chaque URI de redirection, le serveur de connexion doit pouvoir faire la distinction entre les URI de redirection et ne peut pas le faire lorsque seul le port diffère.

• Pour inscrire plusieurs URI de redirection sur localhost afin de tester différents flux pendant le développement, différenciez-les à l’aide du composant path de l’URI. Par exemple, http://localhost/MyWebApp ne correspond pas à http://localhost/MyNativeApp.

• L’adresse de bouclage IPv6 ([::1]) n’est pas prise en charge actuellement.

Donner la préférence à 127.0.0.1 plutôt qu’à localhost

Pour éviter que votre application ne soit interrompue en raison de pare-feux mal configurés ou d’interfaces réseau renommées, utilisez l’adresse IP de bouclage littérale 127.0.0.1 dans votre URI de redirection à la place de localhost. Par exemple : https://127.0.0.1.

Toutefois, vous ne pouvez pas utiliser la zone de texte URI de redirection dans le Portail Azure pour ajouter un URI de redirection basé sur un bouclage qui utilise le schéma http :

Pour ajouter un URI de redirection qui utilise le schéma http avec l’adresse de bouclage 127.0.0.1, vous devez actuellement modifier l’attribut replyUrlsWithType dans le manifeste de l’application.

Restrictions concernant les caractères génériques des URI de redirection

Les URI avec caractères génériques comme https://*.contoso.com peuvent paraître pratiques, mais doivent être évités en raison des implications en matière de sécurité. Selon la spécification OAuth 2.0 (section 3.1.2 de RFC 6749), un URI de point de terminaison de redirection doit être un URI absolu. Par conséquent, lorsqu’un URI générique configuré correspond à un URI de redirection, les chaînes et les fragments de requête de l’URI de redirection sont supprimés.

Les URI avec caractères génériques ne sont actuellement pas pris en charge dans les inscriptions d’applications configurées pour se connecter à des comptes Microsoft personnels et à des comptes professionnels ou scolaires. Les URI avec des caractères génériques sont autorisés, mais uniquement pour les applications configurées pour se connecter à des comptes professionnels ou scolaires dans un tenant Microsoft Entra d’une organisation.

Pour ajouter des URI de redirection avec des caractères génériques aux inscriptions d’applications qui se connectent à des comptes professionnels ou scolaires, utilisez l’éditeur de manifeste de l’application dans Inscriptions d’applications dans le portail Azure. Bien qu’il soit possible de définir un URI de redirection avec un caractère générique à l’aide de l’éditeur de manifeste, nous vous recommandons fortement de respecter la section 3.1.2 de la RFC 6749. et utilisent uniquement des URI absolus.

Si votre scénario implique plus d’URI de redirection que la limite maximale autorisée, envisagez l’approche de paramètre d’état suivante au lieu d’ajouter un URI de redirection avec caractères génériques.

Utiliser un paramètre d’état

Si vous avez plusieurs sous-domaines et que votre scénario implique que vous redirigiez des utilisateurs, en cas d’authentification réussie, vers la même page que celle où ils ont été démarrés, l’utilisation d’un paramètre d’état peut être utile.

Dans cette approche :

1. Créez un URI de redirection « partagé » par l’application pour traiter les jetons de sécurité que vous recevez du point de terminaison d’autorisation.
2. Votre application peut envoyer des paramètres qui lui sont spécifiques (URL de sous-domaine avec origine de l’utilisateur ou informations sur une marque, par exemple) dans le paramètre d’état. Lorsque vous utilisez un paramètre d’état, protégez-vous contre la falsification de requête intersites (CSRF, Cross Site Request Forgery) comme spécifié dans la section 10.12 de la RFC 6749.
3. Les paramètres spécifiques à l’application incluent toutes les informations requises pour permettre à l’application d’offrir une bonne expérience à l’utilisateur, à savoir, concevoir l’état d'application approprié. Le point de terminaison d’autorisation Microsoft Entra supprime le code HTML du paramètre d’état. Aussi, veillez à ne pas transmettre du contenu HTML dans ce paramètre.
4. Lorsque Microsoft Entra ID envoie une réponse à l’URI de redirection « partagé », il renvoie le paramètre d’état à l’application.
5. L'application peut ensuite utiliser la valeur du paramètre d'état pour déterminer l'URL vers laquelle envoyer l'utilisateur. Veillez à valider la protection CSRF.

Étapes suivantes

En savoir plus sur le Manifeste de l’application de l’inscription d’application.