Implémenter l’authentification unique à partir d’applications natives vers des vues web incorporées

S’applique à : cercle vert avec un symbole de coche blanc qui indique que le contenu suivant s’applique aux locataires externes. Locataires externes (en savoir plus)

Lorsque votre application mobile inclut des fonctionnalités web telles qu’une page de mise à jour de profil ou un tableau de bord de récompenses, les utilisateurs s’attendent à une expérience d’authentification unique transparente. Ils ne doivent pas rencontrer une deuxième invite de connexion après la connexion via l’application native.

Cet article explique comment implémenter l’authentification unique (SSO) entre une application mobile native et une ressource web hébergée dans une vue web incorporée (par exemple, WKWebView sur iOS ou WebView sur Android). Contrairement aux navigateurs système, les vues web incorporées vous permettent de manipuler les requêtes réseau avant leur envoi. Cette fonctionnalité permet à votre application d’injecter l’état d’authentification de l’utilisateur directement dans les en-têtes de requête.

Le flux recommandé fonctionne comme suit :

  1. L’utilisateur se connecte via l’interface utilisateur native de l’application mobile à l’aide du SDK d’authentification native ou de l’API d’authentification native.
  2. Avant de charger la vue web, l’application récupère un jeton d’accès valide à partir du Kit de développement logiciel (SDK) ou de l’API.
  3. L’application charge la vue web avec une demande personnalisée qui inclut le jeton d’accès dans l’en-tête Authorization: Bearer <access_token> .
  4. La ressource web valide le jeton et accorde immédiatement l’accès.

Le diagramme suivant montre l’interaction entre la ressource web, l’application mobile, le SDK et le service d’identité (ESTS) :

Diagramme de séquence montrant le flux d’authentification unique où l’application mobile se connecte via le SDK, reçoit des jetons et charge l’affichage web avec le jeton d’accès dans l’en-tête d’autorisation.

Prerequisites

Se connecter avec l’authentification native

Terminez le flux de connexion standard à l’aide du Kit de développement logiciel (SDK) d’authentification native ou de l’API d’authentification native. Lorsque la connexion réussit à utiliser le Kit de développement logiciel (SDK), elle met en cache le jeton d’accès, le jeton d’ID et le jeton d’actualisation en toute sécurité. Si vous utilisez directement l’API, votre application est chargée de stocker en toute sécurité les jetons qu’elle reçoit.

Pour obtenir des instructions détaillées d’implémentation de connexion, consultez :

Récupérer le jeton d’accès

Lorsque l’utilisateur déclenche l’action pour ouvrir la vue web, vérifiez que l’application dispose d’un jeton d’accès valide et non expiré avant de charger la ressource web.

Si vous utilisez le Kit de développement logiciel (SDK) d’authentification native, demandez un jeton en mode silencieux. Le Kit de développement logiciel (SDK) fournit une getAccessToken() méthode qui récupère un jeton valide à partir du cache ou l’actualise silencieusement. Pour plus d’informations sur l’acquisition de jetons d’accès avec des périmètres spécifiques, consultez :

Si vous utilisez directement l’API d’authentification native, votre application récupère des jetons via le point de terminaison de l’API /oauth/v2.0/token . Pour plus d’informations, consultez la référence de l’API d’authentification native.

Demandez le jeton avec les périmètres exacts requis par la ressource web. Pour connaître les exigences relatives à l’étendue, consultez Limitations et exigences de configuration.

Charger l’affichage web avec l’authentification

Il existe deux méthodes pour passer l’état d’authentification à l’affichage web. L’approche recommandée utilise des en-têtes d’autorisation. Un secours basé sur les cookies est disponible pour les scénarios hérités, mais il est déconseillé.

Injectez le jeton d’accès directement dans l’en-tête Authorization de la requête HTTP initiale utilisée pour charger la vue web. Il s’agit de la méthode la plus sécurisée et la plus robuste.

Cette approche est préférée, car elle :

  • Est sans état : il ne s’appuie pas sur les cookies persistants côté client.
  • Isole le jeton : il limite strictement le jeton à ce flux de requête spécifique.
  • Évite les vecteurs d’attaque basés sur le web : il évite les problèmes de sécurité courants associés aux sessions gérées par le navigateur.

Pour charger l’affichage web avec l’authentification basée sur l’en-tête :

  1. Construisez l’URL de la ressource web. Vérifiez qu’il utilise HTTPS.
  2. Créez un objet de requête réseau personnalisé.
  3. Ajoutez l’en-tête Authorization: Bearer <access_token> à la requête.
  4. Chargez la requête dans le composant d’affichage web (par exemple, WKWebView sur iOS ou WebView sur Android).

Option B : Utiliser des cookies (solution de repli uniquement)

Si la ressource web cible ne peut pas gérer l'authentification basée sur l'en-tête (par exemple, certaines applications anciennes à une seule page), vous pouvez injecter le jeton sous forme de cookie. Cette approche est généralement déconseillée en raison des risques de sécurité.

L’injection de cookies dans une vue web confie l’état d’authentification à un mécanisme géré par le navigateur. Cela rend la session « ambiante » (automatiquement attachée aux requêtes), qui expose l’application aux classes d’attaque web standard :

  • XSS (script intersites) : la session est vulnérable au détournement si le contenu web est compromis.
  • CSRF (falsification de demande intersite) : il existe un risque de demandes authentifiées involontaires.
  • Fixation de session : un attaquant peut contrôler l’état de la session.
  • Conformité : cette approche est en conflit avec les meilleures pratiques de sécurité (par exemple, MASTG-KNOW-0018) concernant la persistance de l’état sensible dans les jars de cookies d’affichage web.

Avertissement

L’approche basée sur les cookies est approuvée de manière conditionnelle et généralement déconseillée. Utilisez-la uniquement lorsque la ressource web cible ne peut pas prendre en charge l’authentification basée sur l’en-tête.

Si vous utilisez l’approche basée sur les cookies, ces exigences s’appliquent :

  • Utilisez les cookies de session émis par le serveur si possible.
  • Évitez de placer des jetons d’accès bruts directement dans des cookies.
  • Définissez des cookies avec les attributs HttpOnly, Secure, et SameSite appropriés.
  • Appliquez une protection CSRF stricte côté serveur.

Valider et conserver le jeton sur le back-end

Lorsque la requête atteint la ressource web, le back-end traite le jeton pour établir la session.

Valider le jeton

Le serveur web intercepte les requêtes entrantes et vérifie la signature et les revendications du jeton. Pour ASP.NET back-ends Core, utilisez Microsoft.Identity.Web (MISE) pour gérer la validation automatiquement.

Vérifiez que la revendication de l’audience (aud) du jeton correspond à l’identificateur de l’API web et à la revendication de l’émetteur (iss) correspond à l’autorité attendue.

Conserver la session

La vue web ne conserve pas les en-têtes personnalisés sur les événements de navigation suivants (par exemple, lorsque l’utilisateur sélectionne un lien). Pour maintenir l’état authentifié après la demande initiale, le serveur émet un cookie de session standard (Set-Cookie) lors de la validation réussie du jeton du porteur initial.

Configurez le cookie de session avec les attributs suivants :

  • HttpOnly
  • Secure
  • Une stratégie appropriée SameSite

Limitations et exigences de configuration

Pour vous assurer que le jeton émis pour l’application mobile est accepté par la ressource web, gardez à l’esprit les configurations suivantes :

  • Identité du client partagé : l’application mobile et l’application web doivent partager le même ID client (ID d’application). S’ils ont des ID différents, le back-end rejette le jeton de l’application mobile en raison d'une incompatibilité d’audience.
  • Alignement de l’étendue : la demande de l'application mobile concernant le jeton d'accès inclut les étendues exactes requises par la ressource web (par exemple, Profile.Read, Orders.Write).

Note

Cette solution est adaptée spécifiquement au scénario d’affichage web. Une solution plus générique qui étend les fonctionnalités d’authentification unique aux navigateurs système et à d’autres scénarios complexes est prévue pour une prochaine version.

Contenu connexe

  • Last updated on