OpenID Connect sur la plateforme d’identité Microsoft

OpenID Connect (OIDC) étend le protocole d’autorisation OAuth 2.0 pour l’utiliser également comme protocole d’authentification. Vous pouvez utiliser OIDC pour activer l’authentification unique (SSO) entre vos applications OAuth à l’aide d’un jeton de sécurité appelé jeton d’ID.

La spécification complète pour OIDC est disponible sur le site web d’OpenID Foundation, à la page Spécification OpenID Connect Core 1.0.

Flux de protocole : Connexion

Ce diagramme montre le flux de connexion OpenID Connect de base. Les étapes du flux sont décrites plus en détail dans les sections ultérieures de l’article.

Diagramme swimlane montrant le flux de connexion OpenID Connect.

Conseil

Essayez d’exécuter cette requête dans Postman
Essayez d’exécuter cette requête et plus encore dans Postman -- n’oubliez pas de remplacer les jetons et les ID !

Activer les jetons d’ID

Le jeton d’ID introduit par OpenID Connect est émis par le serveur d’autorisation (la plateforme d’identité Microsoft) lorsque l’application cliente en demande un au moment de l’authentification utilisateur. Le jeton d’ID permet à une application cliente de vérifier l’identité de l’utilisateur et d’obtenir d’autres informations (revendications) le concernant.

Les jetons d’ID ne sont pas émis par défaut pour une application inscrite auprès de la plateforme d’identité Microsoft. Activez les jetons d’ID pour une application en choisissant l’une des méthodes suivantes.

Pour activer les jetons d’ID pour votre application, accédez au portail Azure, puis :

  1. Sélectionnez Azure Active Directory>Inscriptions des applications><votre application>>Authentification.
  2. Sous Flux d’octroi implicite et flux hybride, cochez la case Jetons d’ID (utilisés pour les flux implicites et hybrides).

Ou :

  1. Sélectionnez Azure Active Directory>Inscriptions des applications><votre application>>Manifeste.
  2. Définissez oauth2AllowIdTokenImplicitFlow sur true dans le manifeste d’application de l’inscription de l’application.

Si vous oubliez d’activer les jetons d’ID pour votre application et que vous en demandez un, la plateforme d’identité Microsoft retourne une erreur unsupported_response de ce type :

La valeur fournie pour le paramètre d’entrée 'response_type' n’est pas autorisée pour ce client. La valeur attendue est 'code'.

La demande d’un jeton d’ID en spécifiant id_token comme response_type est expliquée dans la section Envoyer la requête de connexion, plus loin dans l’article.

Récupérer le document de configuration OpenID

Les fournisseurs OpenID comme la plateforme d’identité Microsoft fournissent un document de configuration de fournisseur OpenID sur un point de terminaison accessible publiquement, contenant les points de terminaison OIDC, les revendications prises en charge et d’autres métadonnées du fournisseur. Les applications clientes peuvent utiliser les métadonnées pour découvrir les URL à utiliser pour l’authentification ainsi que les clés de signature publiques du service d’authentification, entre autres.

Les bibliothèques d’authentification sont les consommateurs les plus courants du document de configuration OpenID, qu’elles utilisent pour la découverte des URL d’authentification, des clés de signature publiques du fournisseur et d’autres métadonnées du service. Si vous utilisez une bibliothèque d’authentification dans votre application (ce que nous recommandons), vous n’aurez probablement pas besoin de coder vous-même les requêtes et réponses depuis le point de terminaison du document de configuration OpenID.

Rechercher l’URI du document de configuration OpenID de votre application

À chaque inscription d’application dans Azure AD est fourni un point de terminaison qui est accessible publiquement et sert de document de configuration OpenID. Pour déterminer l’URI du point de terminaison du document de configuration pour votre application, ajoutez le chemin de la configuration OpenID connue à l’URL de l’autorité de votre inscription d’application.

  • Chemin du document de la configuration connue : /.well-known/openid-configuration
  • URL de l'autorité : https://login.microsoftonline.com/{tenant}/v2.0

La valeur de {tenant} varie en fonction de l’audience de connexion de l’application, comme indiqué dans le tableau suivant. L’URL de l’autorité dépend aussi de l’instance cloud.

Valeur Description
common Les utilisateurs avec un compte Microsoft personnel et un compte professionnel ou scolaire Azure AD peuvent se connecter à l’application.
organizations Seuls les utilisateurs avec des comptes professionnels ou scolaires Azure AD peuvent se connecter à l’application.
consumers Seuls les utilisateurs avec un compte personnel Microsoft peuvent se connecter à l’application.
8eaef023-2b34-4da1-9baa-8bc8c9d6a490 ou contoso.onmicrosoft.com Seuls les utilisateurs d’un locataire Azure AD spécifique (membres de l’annuaire avec un compte professionnel ou scolaire ou bien invités de l’annuaire avec un compte Microsoft personnel) peuvent se connecter à l’application.

La valeur peut être le nom de domaine du locataire Azure AD ou l’ID du locataire au format GUID. Vous pouvez également utiliser le GUID du locataire consommateur ,9188040d-6c67-4c5b-b112-36a304b66dad, à la place de consumers.

Conseil

Notez qu’en cas d’utilisation de l’autorité common ou consumers pour des comptes Microsoft personnels, vous devez configurer l’application de ressource consommatrice pour prendre en charge ce type de compte conformément à signInAudience.

Vous pouvez aussi rechercher l’URI du document de configuration OpenID de votre application dans son inscription d’application dans le portail Azure.

Pour rechercher le document de configuration OIDC de votre application, accédez au portail Azure, puis :

  1. Sélectionnez Azure Active Directory>Inscriptions des applications><votre application>>Points de terminaison.
  2. Recherchez l’URI sous Document de métadonnées OpenID Connect.

Exemple de requête

Cette requête obtient les métadonnées de configuration OpenID à partir du point de terminaison du document de configuration OpenID de l’autorité common sur le cloud public Azure :

GET /common/v2.0/.well-known/openid-configuration
Host: login.microsoftonline.com

Conseil

Essayez ! Pour voir le document de configuration OpenID de l’autorité common d’une application, accédez à https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration.

Exemple de réponse

Les métadonnées de configuration sont retournées au format JSON, comme illustré dans l’exemple suivant (tronqué par souci de concision). Les métadonnées retournées dans la réponse JSON sont décrites en détail dans la spécification de découverte OpenID Connect 1.0.

{
  "authorization_endpoint": "https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize",
  "token_endpoint": "https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token",
  "token_endpoint_auth_methods_supported": [
    "client_secret_post",
    "private_key_jwt"
  ],
  "jwks_uri": "https://login.microsoftonline.com/{tenant}/discovery/v2.0/keys",
  "userinfo_endpoint": "https://graph.microsoft.com/oidc/userinfo",
  "subject_types_supported": [
      "pairwise"
  ],
  ...
}

Envoyer la requête de connexion

Pour authentifier un utilisateur et demander un jeton d’ID à utiliser dans votre application, redirigez sa requête user-agent vers le point de terminaison /authorize de la plateforme d’identité Microsoft. La requête est similaire au premier tronçon du flux de code d’autorisation OAuth 2.0, avec toutefois ces distinctions :

  • Incluez l’étendue openid dans le paramètre scope.
  • Spécifiez id_token ou code+id_token dans le paramètre response_type.
  • Incluez le paramètre nonce.

Exemple de requête de connexion (sauts de ligne inclus uniquement pour une meilleure lisibilité) :

GET https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=id_token
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=form_post
&scope=openid
&state=12345
&nonce=678910
Paramètre Condition Description
tenant Obligatoire Vous pouvez utiliser la valeur {tenant} dans le chemin d’accès de la requête pour contrôler les utilisateurs qui peuvent se connecter à l’application. Les valeurs autorisées sont common, organizations, consumers et les identificateurs du client. Pour plus d’informations, consultez les principes de base du protocole. Notez que dans les scénarios d’invités, où vous connectez l’utilisateur d’un locataire à un autre locataire, vous devez impérativement fournir l’identificateur du locataire pour connecter correctement l’utilisateur au locataire des ressources.
client_id Obligatoire L’ID (client) d’application attribué à votre application par l’environnement Inscriptions d’applications du portail Azure.
response_type Obligatoire Doit inclure id_token pour la connexion à OpenID Connect. Il peut également inclure d’autres valeurs response_type, par exemple code.
redirect_uri Recommandé L’URI de redirection de votre application, vers lequel votre application peut envoyer et recevoir des réponses d’authentification. Il doit correspondre exactement à un des URI de redirection inscrits dans le portail, sauf qu’il doit être codé dans une URL. Si vous ne disposez pas d’un URI de redirection, le point de terminaison sélectionnera un élément redirect_uri inscrit au hasard vers lequel il redirigera l’utilisateur.
scope Obligatoire Une liste d’étendues séparées par des espaces. Pour OpenID Connect, vous devez inclure l’étendue openid, qui correspond à l’autorisation Vous connecter dans l’interface utilisateur de consentement. Vous pouvez inclure d’autres étendues dans cette requête pour solliciter le consentement.
nonce Obligatoire Valeur générée et envoyée par votre application dans sa requête de jeton d’ID. La même valeur nonce est incluse dans le jeton d’ID qui est retourné à votre application par la plateforme d’identité Microsoft. Pour atténuer les attaques par relecture de jetons, votre application doit vérifier que la valeur nonce dans le jeton d’ID est la même valeur qu’elle a envoyée lors de la demande du jeton. La valeur est généralement une chaîne unique et aléatoire.
response_mode Recommandé Spécifie la méthode à utiliser pour envoyer le code d’autorisation résultant à votre application. Peut être form_post ou fragment. Pour les applications web, nous vous recommandons d’utiliser response_mode=form_post pour garantir le transfert le plus sécurisé des jetons à votre application.
state Recommandé Une valeur incluse dans la requête qui sera également renvoyée dans la réponse de jeton. Il peut s’agir d’une chaîne du contenu de votre choix. Une valeur unique générée de manière aléatoire est généralement utilisée pour empêcher les attaques par falsification de requête intersites. La valeur d’état est également utilisée pour coder les informations sur l’état de l’utilisateur dans l’application avant la requête d’authentification, comme la page ou l’écran sur lequel ou laquelle il était positionné.
prompt Facultatif Indique le type d’interaction utilisateur requis. Les seules valeurs valides pour l’instant sont login, none, consent et select_account. La revendication prompt=login oblige l'utilisateur à saisir ses informations d'identification lors de cette requête, annulant de fait l'authentification unique. Le paramètreprompt=none est le contraire et doit être associé à login_hint pour indiquer quel utilisateur doit être connecté. Ces paramètres garantissent qu’aucune invite interactive n’est présentée à l’utilisateur. Si la demande ne peut pas être exécutée en mode silencieux au moyen d’une authentification unique, la plateforme d’identités Microsoft renvoie une erreur. Les causes possibles sont : aucun utilisateur n’est connecté, l’utilisateur avec indicateur n’est pas connecté, ou plusieurs utilisateurs sont connectés, mais aucun indicateur n’a été fourni. La revendication prompt=consent déclenche l'affichage de la boîte de dialogue de consentement OAuth une fois que l’utilisateur se connecte. La boîte de dialogue invite l’utilisateur à accorder des autorisations à l’application. Enfin, select_account montre à l’utilisateur un sélecteur de compte, en annulant l’authentification unique sans assistance, mais en permettant à l’utilisateur de choisir le compte avec lequel il envisage de se connecter, sans avoir besoin d’entrer une entrée d’identification. Vous ne pouvez pas utiliser login_hint et select_account simultanément.
login_hint Facultatif Vous pouvez utiliser ce paramètre pour remplir au préalable le champ réservé au nom d’utilisateur et à l’adresse électronique de la page de connexion de l’utilisateur si vous connaissez déjà son nom d’utilisateur. Les applications utilisent souvent ce paramètre durant la réauthentification, après avoir extrait la login_hintrevendication facultative à partir d’une connexion antérieure.
domain_hint Facultatif Le domaine de l’utilisateur dans un répertoire fédéré. Ce paramètre ignore le processus de découverte par e-mail auquel l’utilisateur doit se soumettre sur la page de connexion, ce qui améliore légèrement l’expérience utilisateur. Pour les clients fédérés par le biais d’un répertoire local comme AD FS, cela aboutit généralement à une connexion fluide en raison d’une ouverture de session existante.

À ce stade, l’utilisateur est invité à saisir ses informations d’identification et à exécuter l’authentification. La plateforme d’identités Microsoft vérifie que l’utilisateur a accepté les autorisations indiquées dans le paramètre de requête scope. Si l’utilisateur n’a pas accepté l’une ou plusieurs de ces autorisations, la plateforme d’identités Microsoft lui demande de corriger ce manquement. Vous pouvez en savoir plus sur les autorisations, consentements et applications mutualisées.

Une fois que l’utilisateur a procédé à l’authentification et accordé son consentement, la plateforme d’identités Microsoft renvoie une réponse à votre application à l’URI de redirection indiqué, à l’aide de la méthode spécifiée dans le paramètre response_mode.

Réponse correcte

Une réponse réussie lorsque vous utilisez response_mode=form_post ressemble à ceci :

POST /myapp/ HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded

id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNB...&state=12345
Paramètre Description
id_token Le jeton d'ID que l’application a demandé. Vous pouvez utiliser le paramètre id_token pour vérifier l’identité de l’utilisateur et démarrer une session avec lui. Pour plus d’informations sur les jetons d’ID et leur contenu, consultez les informations de référence sur les jetons d’ID.
state Si un paramètre state est inclus dans la demande, la même valeur doit apparaître dans la réponse. L’application doit vérifier que les valeurs d’état de la demande et de la réponse sont identiques.

Réponse d’erreur

Les réponses d’erreur peuvent également être envoyées à l'URI de redirection afin que l’application puisse les traiter. Par exemple :

POST /myapp/ HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded

error=access_denied&error_description=the+user+canceled+the+authentication
Paramètre Description
error Une chaîne de code d’erreur que vous pouvez utiliser pour classer les types d’erreur se produisant et pour intervenir face aux erreurs.
error_description Un message d’erreur spécifique qui peut vous aider à identifier la cause principale d’une erreur d’authentification.

Codes d’erreur pour les erreurs de point de terminaison d’autorisation

Le tableau suivant décrit les codes d’erreur qui peuvent être retournés dans le paramètre error de la réponse d’erreur :

Code d'erreur Description Action du client
invalid_request Erreur de protocole, par exemple paramètre obligatoire manquant. Corrigez l’erreur, puis envoyez à nouveau la demande. Cette erreur de développement doit être interceptée durant les tests de l’application.
unauthorized_client L’application cliente ne peut pas demander un code d’autorisation. Cette erreur peut se produire lorsque l’application cliente n’est pas inscrite dans Azure AD ou n’est pas ajoutée au client Azure AD de l’utilisateur. L’application peut proposer à l’utilisateur des instructions pour installer l’application et l’ajouter à Azure AD.
access_denied Le propriétaire de la ressource n’a pas accordé son consentement. L’application cliente peut avertir l’utilisateur qu’elle ne peut pas continuer sans son consentement.
unsupported_response_type Le serveur d’autorisation ne prend pas en charge le type de réponse dans la requête. Corrigez l’erreur, puis envoyez à nouveau la demande. Cette erreur de développement doit être interceptée durant les tests de l’application.
server_error Le serveur a rencontré une erreur inattendue. Relancez la requête. Ces erreurs peuvent résulter de conditions temporaires. L’application cliente peut expliquer à l’utilisateur que sa réponse est reportée en raison d’une erreur temporaire.
temporarily_unavailable Le serveur est temporairement trop occupé pour traiter la demande. Relancez la requête. L’application cliente peut expliquer à l’utilisateur que sa réponse est reportée en raison d’une condition temporaire.
invalid_resource La ressource cible n’est pas valide car elle n’existe pas, Azure AD ne la trouve pas ou elle est incorrectement configurée. Cette erreur indique que la ressource, si elle existe, n’a pas été configurée dans le locataire. L’application peut proposer à l’utilisateur des instructions pour installer l’application et l’ajouter à Azure AD.

Validation du jeton d’ID

La réception d’un jeton d’ID dans votre application peut ne pas toujours être suffisante pour authentifier entièrement l’utilisateur. Vous pouvez également avoir besoin de valider la signature du jeton d’ID et de vérifier ses revendications par rapport aux exigences de votre application. Comme tous les fournisseurs OpenID, les jetons d’ID de la plateforme d’identité Microsoft sont des jetons web JSON (JWT) signés par la méthode de cryptographie à clé publique.

Les applications web et les API web qui utilisent des jetons d’ID pour l’autorisation doivent les valider, car ces applications contrôlent l’accès aux données. Toutefois, d’autres types d’applications n’utilisent pas la validation de jeton d’ID. Les applications natives et monopages (SPA), par exemple, utilisent rarement la validation de jeton d’ID, car les entités ayant un accès physique à l’appareil ou au navigateur peuvent potentiellement contourner la validation.

Voici deux exemples de contournement de la validation des jetons :

  • Fourniture de jetons ou clés fictifs en redirigeant le trafic réseau vers l’appareil
  • Débogage de l’application et exécution pas à pas de la logique de validation pendant l’exécution du programme.

Si vous validez les jetons d’ID dans votre application, nous vous recommandons de ne pas le faire manuellement. À la place, utilisez une bibliothèque de validation des jetons pour analyser et valider des jetons. Les bibliothèques de validation des jetons sont disponibles pour la plupart des langages, frameworks et plateformes de développement.

Informations à valider dans un jeton d’ID

En plus de valider la signature du jeton d’ID, vous devez valider plusieurs de ses revendications, comme cela est expliqué dans Validation d’un jeton d’ID dans les informations de référence sur les jetons d’ID. Consultez également Informations importantes sur la substitution des clés de signature.

Plusieurs autres validations sont fréquemment demandées et varient selon le scénario d’application :

  • S’assurer que l’utilisateur/l’organisation s’est inscrit pour l’application.
  • S’assurer que l’utilisateur dispose de l’autorisation/des privilèges appropriés.
  • S’assurer de l’utilisation d’une force certaine d’authentification, comme une authentification multifacteur.

Une fois que vous avez validé le jeton d’ID, vous pouvez commencer une session avec l’utilisateur et utiliser les informations contenues dans les revendications du jeton pour la personnalisation de l’application, son affichage ou le stockage de ses données.

Schéma de protocole : Acquisition de jeton d'accès

Beaucoup d’applications doivent non seulement connecter un utilisateur, mais également accéder à une ressource protégée comme une API web pour le compte de l’utilisateur. Ce scénario utilise à la fois OpenID Connect, pour obtenir un jeton d’ID pour authentifier l’utilisateur, et OAuth 2.0 afin d’obtenir un jeton d’accès pour une ressource protégée.

Le flux complet de connexion OpenID Connect et d’acquisition des jetons ressemble à ce diagramme :

Protocole OpenID Connect : Acquisition de jeton

Obtenir un jeton d’accès pour le point de terminaison UserInfo

En plus du jeton d’ID, les informations de l’utilisateur authentifié sont également mises à disposition sur le point de terminaison UserInfo OIDC.

Pour obtenir un jeton d’accès pour le point de terminaison UserInfo OIDC, modifiez la requête de connexion comme ceci :

// Line breaks are for legibility only.

GET https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e        // Your app registration's Application (client) ID
&response_type=id_token%20token                       // Requests both an ID token and access token
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F       // Your application's redirect URI (URL-encoded)
&response_mode=form_post                              // 'form_post' or 'fragment'
&scope=openid+profile+email                           // 'openid' is required; 'profile' and 'email' provide information in the UserInfo endpoint as they do in an ID token. 
&state=12345                                          // Any value - provided by your app
&nonce=678910                                         // Any value - provided by your app

Vous pouvez utiliser le flux de code d’autorisation, le flux de code de l’appareil ou un jeton d’actualisation à la place de response_type=token pour obtenir un jeton d’accès pour votre application.

Réponse de jeton correcte

Réponse correcte après l’utilisation de response_mode=form_post :

POST /myapp/ HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
 access_token=eyJ0eXAiOiJKV1QiLCJub25jZSI6I....
 &token_type=Bearer
 &expires_in=3598
 &scope=email+openid+profile
 &id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI....
 &state=12345

Les paramètres de la réponse signifient la même chose quel que soit le flux utilisé pour les acquérir.

Paramètre Description
access_token Jeton qui sera utilisé pour appeler le point de terminaison UserInfo.
token_type Toujours « Porteur ».
expires_in Temps écoulé jusqu’à l’expiration du jeton d’accès, en secondes.
scope Autorisations d’accès accordées pour le jeton d’accès. Étant donné que le point de terminaison UserInfo est hébergé sur Microsoft Graph, il est possible pour scope de contenir d’autres autorisations précédemment accordées à l’application (par exemple, User.Read).
id_token Le jeton d'ID que l’application a demandé. Vous pouvez utiliser le jeton d'ID pour vérifier l’identité de l’utilisateur et démarrer une session avec lui. Pour plus de détails sur les jetons d’ID et leur contenu, consultez les informations de référence sur les jetons d’ID.
state Si un paramètre d’état est inclus dans la demande, la même valeur doit apparaître dans la réponse. L’application doit vérifier que les valeurs d’état de la demande et de la réponse sont identiques.

Avertissement

N’essayez pas de valider ou de lire des jetons pour des API dont vous n’êtes pas propriétaire, y compris les jetons de cet exemple, dans votre code. Les jetons associés aux services Microsoft peuvent utiliser un format spécial qui n’est pas validé comme jeton JWT, et peuvent également être chiffrés pour les utilisateurs consommateurs (de comptes Microsoft). Même si la lecture des jetons est un outil utile de débogage et d’apprentissage, n’y associez pas de dépendances dans votre code ou tenez compte des spécificités des jetons qui ne correspondent pas à une API que vous contrôlez.

Réponse d’erreur

Les réponses d’erreur peuvent également être envoyées à l'URI de redirection afin que l’application puisse les traiter de manière appropriée :

POST /myapp/ HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded

error=access_denied&error_description=the+user+canceled+the+authentication
Paramètre Description
error Une chaîne de code d’erreur que vous pouvez utiliser pour classer les types d’erreur se produisant et pour intervenir face aux erreurs.
error_description Un message d’erreur spécifique qui peut vous aider à identifier la cause principale d’une erreur d’authentification.

Pour obtenir une description des codes d’erreur éventuels et connaître les réponses client recommandées associées, consultez Codes d’erreur pour les erreurs de point de terminaison d’autorisation.

Une fois que vous avez obtenu un code d'autorisation et un jeton d'ID, vous pouvez connecter l’utilisateur et obtenir des jetons d’accès pour son compte. Pour connecter l’utilisateur, vous devez valider le jeton d'ID exactement comme décrit. Pour obtenir des jetons d’accès, suivez la procédure décrite dans la documentation du flux de code OAuth.

Appel du point de terminaison UserInfo

Consultez la documentation relative à UserInfo pour savoir comment appeler le point de terminaison UserInfo avec ce jeton.

Envoi d’une demande de déconnexion

Pour déconnecter un utilisateur, effectuez ces deux opérations :

  • Rediriger la requête user-agent de l’utilisateur vers l’URI de déconnexion de la plateforme d’identité Microsoft
  • Effacez les cookies de votre application ou mettez fin à la session de l’utilisateur dans votre application.

Si vous ne parvenez pas à effectuer l’une ou l’autre de ces opérations, l’utilisateur peut rester authentifié et ne pas être invité à se connecter la prochaine fois qu’il utilisera votre application.

Redirigez la requête user-agent vers end_session_endpoint comme cela est décrit dans le document de configuration OpenID Connect. end_session_endpoint prend en charge les requêtes HTTP GET et POST.

GET https://login.microsoftonline.com/common/oauth2/v2.0/logout?
post_logout_redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
Paramètre Condition Description
post_logout_redirect_uri Recommandé URL vers laquelle l’utilisateur est redirigé après sa déconnexion. Si le paramètre n’est pas inclus, un message générique généré par la plateforme d’identités Microsoft s’affiche sur l’écran de l’utilisateur. Cette URL doit correspondre exactement à l’un des URI de redirection inscrits pour votre application dans le portail d’inscription des applications.
logout_hint Facultatif Permet à la déconnexion de se produire sans inviter l’utilisateur à sélectionner un compte. Pour utiliser logout_hint, activez la login_hintrevendication facultative dans votre application cliente et utilisez la valeur de la revendication facultative login_hint comme le paramètre logout_hint. N’utilisez pas d’UPN ou de numéros de téléphone comme valeur du paramètre logout_hint.

Notes

Une fois la déconnexion réussie, les sessions actives sont définies sur inactives. S’il existe un jeton d’actualisation principal (PRT) valide pour l’utilisateur déconnecté et qu’une nouvelle connexion est exécutée, l’authentification unique est interrompue et l’utilisateur voit une invite avec un sélecteur de compte. Si l’option sélectionnée est le compte connecté qui fait référence au PRT, la connexion se poursuit automatiquement sans qu’il soit nécessaire d’insérer de nouvelles informations d’identification.

Déconnexion unique

Lorsque vous redirigez l’utilisateur vers le point end_session_endpoint, la plateforme d’identités Microsoft efface la session de l’utilisateur dans le navigateur. Toutefois, l’utilisateur peut rester connecté à d’autres applications qui utilisent des comptes Microsoft pour s’authentifier. Pour permettre à ces applications de déconnecter simultanément l’utilisateur, la plateforme d’identités Microsoft envoie une requête HTTP GET au lien LogoutUrl inscrit de toutes les applications auxquelles l’utilisateur est actuellement connecté. Les applications doivent répondre à cette requête en effaçant toute session qui identifie l’utilisateur et en renvoyant une réponse 200. Si vous souhaitez prendre en charge la déconnexion unique dans votre application, vous devez implémenter ce paramètre LogoutUrl dans le code de votre application. Vous pouvez définir le paramètre LogoutUrl à partir du portail d’inscription des applications.

Étapes suivantes