Autorisation auprès de fournisseurs d’identité non-Microsoft

De nombreux fournisseurs d’identité, en plus de la Plateforme d'identités Microsoft, peuvent fonctionner avec votre complément. Ces fournisseurs permettent aux utilisateurs d’accorder à un complément Office l’accès à leurs comptes dans d’autres services.

L’infrastructure standard dans le secteur permettant d’activer l’accès d’une application web à un service en ligne est appelée OAuth 2.0. En règle générale, vous n’avez pas besoin de connaître les détails du fonctionnement de l’infrastructure pour pouvoir l’utiliser dans votre complément. Ces détails sont simplifiés pour vous dans de nombreuses bibliothèques disponibles.

L’une des idées fondamentales d’OAuth est qu’une application peut être un principal de sécurité en elle-même, de la même façon qu’un utilisateur ou un groupe, avec sa propre identité et son ensemble d’autorisations. Dans un flux classique, un utilisateur effectue une action dans le complément qui nécessite un autre service. Le complément demande un ensemble spécifique d’autorisations sur le compte de cet utilisateur. Le service invite ensuite l’utilisateur à accorder ces autorisations.

Une fois l’autorisation accordée, le service envoie au complément un jeton d’accès encodé. Le complément inclut le jeton dans les demandes adressées aux API du service. Le jeton accorde uniquement les autorisations approuvées par l’utilisateur et expire après un délai spécifié.

Choisir un flux OAuth 2.0

Plusieurs modèles OAuth, appelés flux ou types d’accès accordé, sont conçus pour différents scénarios. Les deux modèles suivants sont les plus couramment implémentés.

• Flux implicite : la communication entre le complément et le service en ligne est mise en œuvre avec JavaScript côté client. Ce flux est couramment utilisé dans les applications à page unique (SPA).
• Flux de code d’autorisation : la communication est effectuée de serveur à serveur entre l’application web de votre complément et le service en ligne. Par conséquent, elle est mise en œuvre avec du code côté serveur.

L’objectif d’un flux OAuth est de sécuriser l’identité et l’autorisation de l’application. Dans le flux de code d’autorisation, le fournisseur d’identité émet une clé secrète client qui doit rester confidentielle. Une application qui n’a pas de back-end côté serveur, telle qu’une spa, ne peut pas stocker ce secret en toute sécurité. Nous vous recommandons donc le flux implicite pour les spas.

Vous devez être familiarisé avec les avantages et inconvénients du flux implicite et du flux de code d’autorisation. Pour plus d’informations sur ces deux flux, reportez-vous à Code d’autorisation et Implicite.

Utiliser le flux implicite dans les compléments Office

Consultez la documentation du fournisseur d’identité pour vérifier qu’il prend en charge le flux implicite.

Pour plus d’informations sur les bibliothèques prenant en charge le flux implicite, consultez la rubrique bibliothèques plus loin dans cet article.

Utiliser le flux de code d’autorisation dans les compléments Office

De nombreuses bibliothèques sont disponibles pour l’implémentation du flux de code d’autorisation dans différentes langues et infrastructures. Pour obtenir quelques exemples, consultez la section Bibliothèques plus loin dans cet article.

Bibliothèques

Des bibliothèques sont disponibles dans de nombreuses langues et sur de nombreuses plateformes, aussi bien pour le flux implicite que pour le flux de code d’autorisation. Certaines sont destinées à un usage général, d’autres sont propres à des services en ligne bien spécifiques.

• Facebook : cherchez « bibliothèque » ou « sdk » sur le site Facebook pour les développeurs.
• Général OAuth 2.0 : le groupe de travail OAuth de l’IETF gère le code OAuth, une page de liens de bibliothèque pour plus d’une douzaine de langues. Certaines de ces bibliothèques sont destinées à l’implémentation d’un service conforme À OAuth. Pour un complément Office, recherchez les bibliothèques clientes , car votre serveur web est un client du service compatible OAuth.

Services intermédiaires

Votre complément peut utiliser un service intermédiaire tel que OAuth.io ou Auth0 pour effectuer l’autorisation. Un service intermédiaire peut fournir des jetons d’accès pour les services en ligne populaires, simplifier la connexion sociale pour votre complément, ou les deux. Votre complément peut se connecter au service d’intermédiaire à l’aide d’un script côté client ou d’un code côté serveur, et le service intermédiaire retourne tous les jetons requis pour le service en ligne.

Nous vous recommandons que l’interface utilisateur pour l’authentification et l’autorisation dans votre complément utilise l’API de boîte de dialogue Office pour ouvrir une page de connexion. Pour plus d’informations, voir Authentifier et autoriser avec l’API de boîte de dialogue Office.

Lorsque vous ouvrez une boîte de dialogue Office de cette façon, la boîte de dialogue s’exécute dans un navigateur distinct et instance du moteur JavaScript de la page parente, comme le volet Office ou le fichier de fonction du complément. Un jeton et toutes les autres informations qui peuvent être converties en chaîne sont repassés au parent à l’aide messageParentde . La page parent peut ensuite utiliser le jeton pour passer des appels autorisés à la ressource.

En raison de cette architecture, soyez prudent lorsque vous utilisez des API à partir d’un service intermédiaire. Certains services fournissent un ensemble d’API dans lequel le code crée un objet de contexte qui obtient un jeton et utilise ce jeton dans les appels ultérieurs à la ressource. Certains services utilisent même une seule méthode d’API qui effectue l’appel initial et crée l’objet de contexte. Un tel objet ne peut pas être entièrement stringifié. Il ne peut donc pas être passé de la boîte de dialogue Office à la page parente.

Les services intermédiaires fournissent généralement un deuxième ensemble d’API à un niveau d’abstraction inférieur, comme une API REST. Cet ensemble d’API de niveau inférieur inclut généralement une API qui obtient un jeton du service et d’autres API qui le transmettent au service lors de la demande d’accès à la ressource. Utilisez cet ensemble d’API de niveau inférieur pour que la boîte de dialogue Office puisse obtenir le jeton, puis le transmettre à la page parente à l’aide messageParentde .

Que signifie l’acronyme CORS ?

CORS signifie Cross-Origin Resource Sharing. Pour plus d’informations sur l’utilisation de CORS dans les compléments, voir Résolution des limitations de stratégie de même origine dans les compléments Office.

Voir aussi

• Vue d’ensemble de l’authentification et de l’autorisation dans les compléments Office