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

Article
06/02/2024

Un URI de redirection, ou URL de réponse, correspond à l’emplacement vers lequel le serveur d’autorisation Microsoft Entra envoie l’utilisateur une fois l’application correctement autorisée et un code d’autorisation ou un jeton d’accès attribué. 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. Le serveur d’authentification Microsoft Entra vérifie l’ajout de l’URI de redirection reçu à l’inscription de l’application. L’URI de redirection est une fonctionnalité de sécurité critique qui veille à ce que les codes d’autorisation et les jetons d’accès soient uniquement envoyé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.

Raison pour laquelle un URI de redirection doit être ajouté dans l’inscription d’une application

Pour des raisons de sécurité, le serveur d’autorisation Microsoft Entra ne redirige pas les utilisateurs ou n’envoie aucun jeton à un URI non ajouté dans l’inscription d’application. Les serveurs de connexion 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.

Quelles plateformes nécessitent un 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

Type de votre application	Langages/infrastructures courants	Plateforme pour ajouter un URI de redirection dans Inscriptions d’application
Application web traditionnelle où la plupart de la logique d’application est effectuée sur le serveur	Node.js, web, ASP.NET, Python, Java, ASP.NET Core, PHP, Ruby, Blazor Server	web
Application monopage où la plupart de la logique d’interface utilisateur est effectuée dans un navigateur web communiquant avec le serveur web principalement en tirant parti d’une API web	JavaScript, Angular, React, Blazor WebAssembly, Vue.js	Application monopage (SPA)

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

Type de votre application	Langages/infrastructures courants	Plateforme pour ajouter un URI de redirection dans Inscriptions d’application
Application iOS ou macOS excluant les scénarios répertoriés en-dessous de cette table	Swift, Objective-C, Xamarin	IOS/macOS
Application Android	Java, Kotlin, Xamarin	Android
Application qui s’exécute en mode natif sur un appareil mobile ou un ordinateur de bureau	Node.js electron, Bureau Windows, UWP, React Native, Xamarin, Android, iOS/macOS	Applications de bureau et mobiles

Si vous générez une application iOS en tirant parti de l’une des méthodes suivantes, veuillez 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

Type d’application	Exemples/notes	Flux OAuth associé
Applications s’exécutant sur des appareils sans clavier	Applications s’exécutant sur une télévision connectée, un appareil IoT ou une imprimante	Flux de code de l’appareil Découvrir plus d’informations
Applications qui gèrent les mots de passe entrés directement par des utilisateurs, au lieu de rediriger des utilisateurs vers le site web de connexion hébergé Entra et laisser Entra gérer les mots de passe des utilisateurs de manière sécurisée.	Vous devez uniquement utiliser ce flux lorsque d’autres flux plus sécurisés, tels que le Flux du code d’autorisation, ne sont pas viables car ils ne sont pas autant sécurisés.	Flux des informations d’identification liées au mot de passe du propriétaire de ressource découvrir plus d’informations
Applications mobiles ou de bureau s’exécutant sous Windows ou sur une machine connectée dans un domaine Windows (AD ou jointe à Azure AD) en tirant parti du flux d’authentification intégré Windows au lieu du gestionnaire de compte web	Une application mobile ou de bureau doit automatiquement être connectée après la connexion de l’utilisateur dans le système PC Windows avec des informations d’identification Entra	Flux d’authentification intégré Windows découvrir plus d’informations

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 : ! $ ' ( ) , ;

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.

Comptes en cours de connexion	Nombre maximal d'URI de redirection	Description
Comptes professionnels ou scolaires Microsoft dans le tenant Microsoft Entra d’une organisation	256	Dans le manifeste de l'application, le champ `signInAudience` est défini sur AzureADMyOrg ou AzureADMultipleOrgs
Comptes personnels ou professionnels et scolaires Microsoft	100	Dans le manifeste de l'application, le champ `signInAudience` est défini sur AzureADandPersonalMicrosoftAccount

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.

Exemple d’URI de redirection	Validité
`https://contoso.com`	Valide
`https://contoso.com/abc/response-oidc`	Valide
`https://localhost`	Valide
`http://contoso.com/abc/response-oidc`	Non valide
`http://localhost`	Valide
`http://localhost/abc`	Valide

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 :

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
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 :

Boîte de dialogue d’erreur dans le portail Azure présentant l’URI de redirection de bouclage http non autorisé

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 :

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.
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.
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.
Lorsque Microsoft Entra ID envoie une réponse à l’URI de redirection « partagé », il renvoie le paramètre d’état à l’application.
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.

Avertissement

Cette approche permet à un client compromis de modifier les paramètres supplémentaires envoyés dans le paramètre d'état, redirigeant ainsi l'utilisateur vers une URL différente, ce qui correspond à la menace de redirecteur ouvert décrite dans le document RFC 6819. Par conséquent, le client doit protéger ces paramètres en chiffrant l’état ou en le vérifiant par un autre moyen, tel que la validation du nom de domaine dans l’URI de redirection par rapport au jeton.

Étapes suivantes

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

Partage via