Créer des applications SharePoint Embedded

  • 6 minutes

Les développeurs peuvent créer des applications qui utilisent les puissantes fonctionnalités de gestion de fichiers et de documents dans SharePoint via SharePoint Embedded. Ces types d’applications ont deux composants distincts.

  • Un composant est chargé d’effectuer des opérations CRUD sur SharePoint Embedded à l’aide des API Microsoft Graph.
  • L’autre composant implémente l’interface permettant aux utilisateurs de consommer et de stocker les documents stockés dans SharePoint Embedded.

Présentation de SharePoint Embedded

SharePoint Embedded permet aux développeurs de créer plus rapidement des applications axées sur les fichiers et les documents. SharePoint Embedded est alimenté par SharePoint. Les développeurs peuvent intégrer les mêmes puissantes fonctionnalités de fichiers et de documents que SharePoint a à offrir dans leurs propres applications personnalisées.

Une autre façon d’examiner SharePoint Embedded est que votre application personnalisée utilise SharePoint pour toutes les fonctionnalités de stockage de documents et de collaboration. Cela utilise efficacement SharePoint Embedded comme « API sans tête » pour le système de stockage de documents de SharePoint.

Les documents d’application restent dans leur locataire Microsoft 365

Lorsqu’un consommateur installe/inscrit une application SharePoint Embedded dans son locataire Microsoft 365, SharePoint Embedded crée une autre partition SharePoint. Cette partition de stockage n’a pas d’interface utilisateur, mais au lieu de cela, les documents de la partition sont uniquement accessibles via des API. Cela signifie que tous les documents sont accessibles à l’éditeur de logiciels indépendant ou à l’application du développeur, mais qu’ils résident uniquement dans le locataire Microsoft 365 du consommateur.

Les paramètres Microsoft 365 grand public s’appliquent aux documents d’application

Tous les documents stockés dans la partition SharePoint créée par l’application SharePoint Embedded se trouvent dans le client Microsoft 365 du consommateur et sont donc soumis aux paramètres du client Microsoft 365 du consommateur.

Présentation des différents types d’autorisations d’application et du flux On-Behalf-Of

Lorsque vous créez des applications pour accéder à des API REST comme Microsoft Graph et SharePoint Online, différentes tâches nécessitent différents types d’accès. Pour résoudre ce problème, OAuth v2.0 est une norme ouverte pour l’autorisation utilisée pour l’accès à l’API, notamment Microsoft Graph et SharePoint Online. Il fournit aux applications un accès délégué aux ressources protégées pour le compte d’un utilisateur. Cela inclut deux types d’autorisations : Application+Utilisateur (également appelé Délégué) et Application seule (ou Application).

  • Autorisations d’application+utilisateur (ou déléguées) : ce modèle concerne un modèle d’autorisation bi-partie. L’application effectue des tâches et appelle des API pour le compte d’un utilisateur connecté. L’application obtient des autorisations déléguées de l’utilisateur qui s’y connecte, en héritant des privilèges dont dispose l’utilisateur, y compris les restrictions telles que l’impossibilité d’accéder à certaines données ou d’effectuer certaines actions. Celles-ci reflètent les tâches que l’utilisateur a autorisées l’application à effectuer en son nom pendant sa session.

    Par exemple, une application peut être autorisée à envoyer un e-mail au nom d’un utilisateur, mais si l’utilisateur n’a pas l’autorisation d’envoyer un e-mail, l’application ne pourra pas non plus l’envoyer.

    Ce type d’autorisation est souvent utilisé lorsque vous souhaitez que votre application fonctionne comme le ferait l’utilisateur connecté, dans les scénarios d’application où l’interaction est au nom d’un utilisateur et où les autorisations doivent varier selon l’utilisateur qui accorde le consentement.

  • Autorisations d’application uniquement (ou d’application) : les autorisations d’application uniquement, à l’inverse, sont utilisées lorsqu’une application doit accéder aux ressources indépendamment d’un utilisateur. L’application obtient les autorisations directement accordées à elle-même, quelles que soient les autorisations de l’utilisateur. Il permet à l’application d’accéder au service d’API avec sa propre identité et ses propres privilèges. Cela est idéal pour les services ou démons en arrière-plan qui s’exécutent indépendamment d’une session utilisateur.

Par exemple, si vous avez une application qui doit accéder à tous les fichiers d’une bibliothèque de documents, même ceux qui ne sont partagés avec aucun utilisateur, des autorisations d’application uniquement sont le bon choix.

Les autorisations d’application ne peuvent être autorisées que par un administrateur, car ils accordent souvent des privilèges plus élevés.

En plus de ces deux options, un troisième flux OAuth 2.0, On-Behalf-Of (également appelé flux OBO ) peut être utilisé lorsqu’une application doit effectuer une tâche pour le compte de l’utilisateur. Voici comment fonctionne l’ensemble du flux OBO :

  1. Une application cliente s’authentifie auprès du serveur d’autorisation (comme l’ID Microsoft Entra) et demande un jeton d’accès pour une API (comme le serveur d’API de notre projet).
  2. L’utilisateur se connecte et autorise l’application à agir en son nom.
  3. L’application cliente reçoit un jeton d’accès et un jeton d’actualisation représentant la session de l’utilisateur.
  4. Lorsque l’application cliente doit appeler un autre service, tel que SharePoint Online, au nom de l’utilisateur, elle envoie le jeton d’accès obtenu précédemment dans l’en-tête Authorization HTTP.
  5. Notre API côté serveur valide le jeton d’accès et traite la requête. S’il doit appeler un autre service (comme SharePoint Online) au nom de l’utilisateur, il extrait un jeton de l’ID Microsoft Entra en présentant ce jeton déjà obtenu.
  6. L’ID Microsoft Entra émet un « nouveau » jeton d’accès pour SharePoint Online que le serveur d’API de notre projet peut désormais utiliser pour appeler SharePoint Online.

Dans un scénario pratique concernant Microsoft Graph ou SharePoint Online, lorsqu’un utilisateur souhaite qu’une application accède à son calendrier, il n’est pas idéal que l’application se connecte pour chaque opération individuelle. Au lieu de cela, avec le flux OBO, l’utilisateur ne doit s’authentifier qu’une seule fois et l’application effectue toutes les opérations autorisées en son nom.

Ainsi, le flux OBO simplifie l’expérience utilisateur et améliore la sécurité du système en veillant à ce que les autorisations soient validées chaque fois qu’une chaîne d’appels est effectuée.

Résumé

Dans cette section, vous avez effectué les étapes initiales pour créer une application web qui effectuera des opérations CRUD sur un conteneur SharePoint Embedded.