Autorisation avec des fournisseurs d’identité autres que Microsoft

De nombreux fournisseurs d’identités, en plus de la Plateforme d’identités Microsoft, peuvent travailler avec votre complément. Ces fournisseurs permettent aux utilisateurs d’accorder à un complément Office l’accès à leur compte 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 jeu d’autorisations spécifiques pour 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 codé. 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 une date spécifiée.

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’un SPA, ne peut pas stocker ce secret en toute sécurité. Nous vous recommandons donc d’utiliser le flux implicite pour les SPA.

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 confirmer 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 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 des 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.
• OAuth 2.0 général : Le groupe de travail OAuth de l’IETF maintient OAuth Code, une page de liens de bibliothèque pour plus d’une douzaine de langues. Certaines de ces bibliothèques permettent d’implémenter un service conforme à OAuth. Pour un complément Office, recherchez des bibliothèques clientes , car votre serveur web est un client du service conforme à OAuth.

Services intermédiaires

Votre complément peut utiliser un service intermédiaire, tel que 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 intermédiaire avec un script côté client ou un code côté serveur, et le service intermédiaire renvoie les jetons requis pour le service en ligne.

Nous recommandons que l’interface utilisateur d’authentification et d’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 manière, la boîte de dialogue s’exécute dans une instance de navigateur et de moteur JavaScript distincte de la page parente, comme le volet Office ou le fichier de fonction du complément. Un jeton et toute autre information pouvant être convertie en chaîne sont transmis 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 les API 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 à la fois l’appel initial et crée l’objet contextuel. Un objet comme celui-ci ne peut pas être entièrement transformé en chaînes, il ne peut donc pas passer de la boîte de dialogue Office à la page parente.

Les services intermédiaires fournissent généralement également un deuxième jeu d’API à un niveau d’abstraction inférieur, comme une API REST. Ce jeu d’API de niveau inférieur inclut généralement une API qui obtient un jeton du service et d’autres API qui repassent le jeton 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 récupérer 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