Applications monopage

Les applications monopage sont généralement structurées en tant que couche de présentation JavaScript (front-end) qui s’exécute dans le navigateur, et un back-end d’API web qui s’exécute sur un serveur et implémente la logique métier de l’application. Pour en savoir plus sur l’octroi d’autorisation implicite et vous aider à déterminer s’il est approprié pour votre scénario d’application, consultez Présentation du flux d’octroi implicite OAuth2 dans Azure Active Directory.

Dans ce scénario, lorsque l’utilisateur se connecte, le serveur frontal JavaScript utilise la bibliothèque d’authentification Active Directory pour JavaScript (ADAL.JS) et l’octroi d’autorisation implicite pour obtenir un jeton d’ID (id_token) auprès d’Azure AD. Le jeton est mis en cache et le client l’attache à la requête en tant que jeton du porteur lors de l’appel à son back-end d’API web, qui est sécurisé à l’aide du middleware OWIN.

Diagramme

Flux de protocole

1. L’utilisateur accède à l’application web.
2. L’application retourne le front-end JavaScript (couche de présentation) au navigateur.
3. L’utilisateur lance la connexion, par exemple en cliquant sur un lien de connexion. Le navigateur envoie un GET au point de terminaison d’autorisation Azure AD pour demander un jeton d’ID. Cette demande inclut l’ID d’application et l’URL de réponse dans les paramètres de requête.
4. Azure AD valide l’URL de réponse par rapport à l’URL de réponse inscrite configurée dans le portail Azure.
5. L’utilisateur se connecte à la page de connexion.
6. Si l’authentification réussit, Azure AD crée un jeton d’ID et le retourne en tant que fragment d’URL (#) à l’URL de réponse de l’application. Pour une application de production, cette URL de réponse doit être HTTPS. Le jeton retourné inclut des revendications concernant l’utilisateur et Azure AD requis par l’application pour valider le jeton.
7. Le code client JavaScript exécuté dans le navigateur extrait le jeton de la réponse à utiliser pour sécuriser les appels au back-end de l’API web de l’application.
8. Le navigateur appelle le back-end de l'API web de l'application, en plaçant le jeton d'ID dans l'en-tête d'autorisation. Le service d’authentification Azure AD émet un jeton d’ID qui peut être utilisé comme jeton du porteur si la ressource est identique à l’ID client (dans ce cas, cela est vrai, car l’API web est le propre back-end de l’application).

Exemples de code

Consultez les exemples de code pour les scénarios d’application monopage. Veillez à vérifier fréquemment les nouveaux exemples à mesure que de nouveaux exemples sont ajoutés fréquemment.

Inscription d’application

• Locataire unique : si vous créez une application uniquement pour votre organisation, elle doit être inscrite dans l’annuaire de votre entreprise à l’aide du portail Azure.
• Multilocataire : si vous créez une application qui peut être utilisée par des utilisateurs externes à votre organisation, elle doit être inscrite dans l’annuaire de votre entreprise, mais également être inscrite dans l’annuaire de chaque organisation qui utilisera l’application. Pour rendre votre application disponible dans son annuaire, vous pouvez inclure un processus d’inscription pour vos clients qui leur permet de donner leur consentement à votre application. Lorsqu’ils s’inscrivent à votre application, ils sont présentés avec une boîte de dialogue qui affiche les autorisations requises par l’application, puis l’option de consentement. Selon les autorisations requises, un administrateur de l’autre organisation peut être tenu de donner son consentement. Lorsque l’utilisateur ou l’administrateur consent, l’application est inscrite dans son annuaire.

Après avoir inscrit l’application, elle doit être configurée pour utiliser le protocole d’octroi implicite OAuth 2.0. Par défaut, ce protocole est désactivé pour les applications. Pour activer le protocole d’octroi implicite OAuth2 pour votre application, modifiez son manifeste d’application à partir du portail Azure et définissez la valeur « oauth2AllowImplicitFlow » sur true. Pour plus d’informations, consultez l’article Manifeste d’application.

Expiration du jeton

L’utilisation de ADAL.js aide à :

• Actualisation d’un jeton expiré
• Demande d’un jeton d’accès pour appeler une ressource d’API web

Après une authentification réussie, Azure AD écrit un cookie dans le navigateur de l’utilisateur pour établir une session. Notez que la session existe entre l’utilisateur et Azure AD (et non entre l’utilisateur et l’application web). Lorsqu’un jeton expire, ADAL.js utilise cette session pour obtenir un autre jeton en mode silencieux. ADAL.js utilise un iFrame masqué pour envoyer et recevoir la requête à l’aide du protocole d’octroi implicite OAuth. ADAL.js pouvez également utiliser ce même mécanisme pour obtenir silencieusement des jetons d’accès pour d’autres ressources d’API web que l’application appelle tant que ces ressources prennent en charge le partage de ressources inter-origines (CORS), sont inscrites dans l’annuaire de l’utilisateur, et tout consentement requis a été donné par l’utilisateur pendant la connexion.

Étapes suivantes

• En savoir plus sur d’autres types d’applications et scénarios
• En savoir plus sur les principes de base de l’authentification azure AD