Autoriser l’accès aux applications web à l’aide d’OpenID Connect et d’Azure Active Directory

OpenID Connect est une couche d’identité simple basée sur le protocole OAuth 2.0. OAuth 2.0 définit des mécanismes permettant d’obtenir et d’utiliser des jetons d’accès pour accéder aux ressources protégées, mais ils ne définissent pas de méthodes standard pour fournir des informations d’identité. OpenID Connect implémente l’authentification en tant qu’extension au processus d’autorisation OAuth 2.0. Il fournit des informations sur l’utilisateur final sous la forme d’un id_token élément qui vérifie l’identité de l’utilisateur et fournit des informations de profil de base sur l’utilisateur.

OpenID Connect est notre recommandation si vous créez une application web hébergée sur un serveur et accessible via un navigateur.

Enregistrez votre application auprès de votre locataire Azure AD

Tout d’abord, inscrivez votre application auprès de votre locataire Azure Active Directory (Azure AD). Cela vous donnera un identifiant d'application pour votre application, et lui permettra de recevoir des jetons.

1. Connectez-vous au portail Azure.

2. Choisissez votre locataire Azure AD en sélectionnant votre compte dans le coin supérieur droit de la page, puis en sélectionnant la navigation dans le répertoire switch , puis en sélectionnant le locataire approprié.

   • Ignorez cette étape si vous n’avez qu’un seul locataire Azure AD sous votre compte ou si vous avez déjà sélectionné le locataire Azure AD approprié.

3. Dans le portail Azure, recherchez et sélectionnez Azure Active Directory.

4. Dans le menu de gauche d’Azure Active Directory , sélectionnez Inscriptions d’applications, puis Nouvelle inscription.

5. Suivez les instructions et créez une nouvelle application. Il n’est pas important qu’il s’agisse d’une application web ou d’une application cliente publique (mobile et bureau) pour ce didacticiel, mais si vous souhaitez des exemples spécifiques pour les applications web ou les applications clientes publiques, consultez nos guides de démarrage rapide.

   • Le nom est le nom de l’application et décrit votre application aux utilisateurs finaux.
   • Sous Types de comptes pris en charge, sélectionnez Comptes dans un annuaire organisationnel et comptes personnels Microsoft.
   • Fournissez l’URI de redirection. Pour les applications web, il s’agit de l’URL de base de votre application où les utilisateurs peuvent se connecter. Par exemple : http://localhost:12345. Pour le client public (mobile &desktop), Azure AD l’utilise pour retourner des réponses de jeton. Entrez une valeur spécifique à votre application. Par exemple : http://MyFirstAADApp.

6. Une fois l’inscription terminée, Azure AD affecte à votre application un identificateur client unique ( ID d’application). Vous avez besoin de cette valeur dans les sections suivantes. Copiez-la donc à partir de la page de l’application.

7. Pour rechercher votre application dans le portail Azure, sélectionnez Inscriptions d’applications, puis Affichez toutes les applications.

Flux d’authentification à l’aide d’OpenID Connect

Le flux de connexion le plus simple contient les étapes suivantes : chacune d’elles est décrite en détail ci-dessous.

Document de métadonnées OpenID Connect

OpenID Connect décrit un document de métadonnées qui contient la plupart des informations requises pour qu’une application effectue la connexion. Cela inclut des informations telles que les URL à utiliser et l’emplacement des clés de signature publiques du service. Le document de métadonnées OpenID Connect se trouve à l’adresse suivante :

https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration

Les métadonnées sont un document JSON (JavaScript Object Notation). Consultez l’extrait de code suivant pour obtenir un exemple. Le contenu de l’extrait de code est entièrement décrit dans la spécification OpenID Connect. Notez que fournir un ID de locataire au lieu de common à la place de {tenant} ci-dessus entraînera l’envoi d’URI spécifiques au locataire dans l’objet JSON retourné.

{
    "authorization_endpoint": "https://login.microsoftonline.com/{tenant}/oauth2/authorize",
    "token_endpoint": "https://login.microsoftonline.com/{tenant}/oauth2/token",
    "token_endpoint_auth_methods_supported":
    [
        "client_secret_post",
        "private_key_jwt",
        "client_secret_basic"
    ],
    "jwks_uri": "https://login.microsoftonline.com/common/discovery/keys"
    "userinfo_endpoint":"https://login.microsoftonline.com/{tenant}/openid/userinfo",
    ...
}

Si votre application a des clés de signature personnalisées en raison de l’utilisation de la fonctionnalité de mappage des revendications , vous devez ajouter un appid paramètre de requête contenant l’ID d’application pour obtenir un jwks_uri pointage vers les informations de clé de signature de votre application. Par exemple : https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration?appid=6731de76-14a6-49ae-97bc-6eba6914391e contient un jwks_uri de https://login.microsoftonline.com/{tenant}/discovery/keys?appid=6731de76-14a6-49ae-97bc-6eba6914391e.

Envoyer la requête de connexion

Lorsque votre application web doit authentifier l’utilisateur, elle doit diriger l’utilisateur vers le /authorize point de terminaison. Cette demande est similaire à la première étape du flux de code d’autorisation OAuth 2.0, avec quelques distinctions importantes :

• La requête doit inclure l’étendue openid dans le scope paramètre.
• Le response_type paramètre doit inclure id_token.
• La demande doit inclure le nonce paramètre.

Par conséquent, un exemple de requête ressemblerait à ceci :

// Line breaks for legibility only

GET https://login.microsoftonline.com/{tenant}/oauth2/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=id_token
&redirect_uri=http%3A%2F%2Flocalhost%3a12345
&response_mode=form_post
&scope=openid
&state=12345
&nonce=7362CAEA-9CA5-4B43-9BA3-34D7C303EBA7

À ce stade, l’utilisateur est invité à saisir ses informations d’identification et à exécuter l’authentification.

Exemple de réponse

Un exemple de réponse, envoyé à la redirect_uri demande de connexion spécifiée après l’authentification de l’utilisateur, peut ressembler à ceci :

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

id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNB...&state=12345

Réponse d’erreur

Les réponses d’erreur peuvent également être envoyées à l’élément redirect_uri , de manière à ce que l’application puisse les traiter de manière appropriée :

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

error=access_denied&error_description=the+user+canceled+the+authentication

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

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

Valider le id_token

La réception d’une demande id_token n’est pas suffisante pour authentifier l’utilisateur ; vous devez valider la signature et vérifier les revendications en id_token fonction des exigences de votre application. Le point de terminaison Azure AD utilise des jetons web JSON (JWT) et un chiffrement à clé publique pour signer des jetons et vérifier qu’ils sont valides.

Vous pouvez choisir de valider le id_token dans le code client, mais une pratique courante consiste à envoyer le id_token à un serveur back-end et à effectuer la validation là-bas.

Vous pouvez également valider des revendications supplémentaires en fonction de votre scénario. Voici quelques validations courantes :

• S’assurer que l’utilisateur/l’organisation s’est inscrit pour l’application.
• S'assurer que l'utilisateur dispose des autorisations/privilèges appropriés à l'aide des revendications wids ou roles.
• S’assurer qu’un niveau suffisant d’authentification est assuré, tel que l’authentification multifacteur.

Une fois que vous avez validé le id_token, vous pouvez commencer une session avec l'utilisateur et utiliser les droits d'accès dans le id_token afin d'obtenir des informations sur l'utilisateur dans votre application. Ces informations peuvent être utilisées pour l'affichage, les enregistrements, la personnalisation, etc. Pour plus d'informations sur id_tokens et les revendications, consultez les id_tokens AAD.

Envoi d’une demande de déconnexion

Lorsque vous souhaitez déconnecter l’utilisateur de l’application, il n’est pas suffisant d’effacer les cookies de votre application ou de mettre fin à la session avec l’utilisateur. Vous devez également rediriger l’utilisateur vers la end_session_endpoint déconnexion. Si vous ne parvenez pas à le faire, l’utilisateur pourra réauthentifier votre application sans entrer à nouveau ses informations d’identification, car il aura une session d’authentification unique valide avec le point de terminaison Azure AD.

Vous pouvez simplement rediriger l’utilisateur vers le end_session_endpoint répertorié dans le document de métadonnées OpenID Connect.

GET https://login.microsoftonline.com/common/oauth2/logout?
post_logout_redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F

Déconnexion unique

Lorsque vous redirigez l’utilisateur vers l’instance end_session_endpoint, Azure AD efface la session de l’utilisateur à partir du navigateur. Toutefois, l’utilisateur peut toujours être connecté à d’autres applications qui utilisent Azure AD pour l’authentification. Pour permettre à ces applications de déconnecter l'utilisateur simultanément, Azure AD envoie une requête HTTP GET à l'endroit enregistré LogoutUrl 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 LogoutUrl type dans le code de votre application. Vous pouvez définir le LogoutUrl depuis le portail Azure :

1. Connectez-vous au portail Azure.
2. Choisissez votre Active Directory en cliquant sur votre compte dans le coin supérieur droit de la page.
3. Dans le volet de navigation de gauche, choisissez Azure Active Directory, puis choisissez Inscriptions d’applications et sélectionnez votre application.
4. Cliquez sur Paramètres, puis Propriétés et recherchez la zone de texte URL de déconnexion .

Acquisition de jetons

De nombreuses applications web doivent non seulement connecter l’utilisateur, mais également accéder à un service web pour le compte de cet utilisateur à l’aide d’OAuth. Ce scénario combine OpenID Connect pour l'authentification de l'utilisateur tout en acquérant simultanément un authorization_code qui peut être utilisé pour obtenir access_tokens via le flux de code d’autorisation OAuth.

Obtenir des jetons d’accès

Pour acquérir des jetons d’accès, vous devez modifier la demande de connexion ci-dessus :

// Line breaks for legibility only

GET https://login.microsoftonline.com/{tenant}/oauth2/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e        // Your registered Application ID
&response_type=id_token+code
&redirect_uri=http%3A%2F%2Flocalhost%3a12345          // Your registered Redirect Uri, url encoded
&response_mode=form_post                              // `form_post' or 'fragment'
&scope=openid
&resource=https%3A%2F%2Fservice.contoso.com%2F        // The identifier of the protected resource (web API) that your application needs access to
&state=12345                                          // Any value, provided by your app
&nonce=678910                                         // Any value, provided by your app

En incluant les étendues d’autorisation dans la demande et en utilisant response_type=code+id_token, le point de terminaison authorize garantit que l’utilisateur a consenti aux autorisations indiquées dans le paramètre de requête scope et retourne à votre application un code d’autorisation pour échanger contre un jeton d’accès.

Réponse réussie

Une réponse réussie, envoyée à redirect_uri en utilisant response_mode=form_post, ressemble à ceci :

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

id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNB...&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...&state=12345

Réponse d’erreur

Les réponses d’erreur peuvent également être envoyées à l’élément redirect_uri , de manière à ce 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

Pour obtenir une description des codes d’erreur possibles et de leur action client recommandée, consultez Codes d’erreur pour les erreurs de point de terminaison d’autorisation.

Une fois que vous avez obtenu une autorisation code et un id_token, vous pouvez connecter l’utilisateur et obtenir des jetons d’accès en son nom. Pour connecter l'utilisateur, vous devez valider id_token exactement comme décrit ci-dessus. Pour obtenir des jetons d’accès, vous pouvez suivre les étapes décrites dans la section « Utiliser le code d’autorisation pour demander un jeton d’accès » de notre documentation sur le flux de code OAuth.

Étapes suivantes

• En savoir plus sur les jetons d’accès.
• En savoir plus sur les id_token et les revendications.