Partager via

Flux OAuth avec code d’autorisation pour les compléments SharePoint

  • Article

Remarque

Cet article suppose que vous connaissez déjà la rubrique Création de compléments SharePoint qui utilisent l’autorisation à faible niveau de fiabilité, ainsi que les concepts et principes sur lesquels se fonde OAuth. Pour plus d’informations sur OAuth, consultez la rubrique OAuth.net et Protocole d’autorisation web (oauth).

Importante

Le contrôle d’accès Azure (ACS), un service d’Azure Active Directory (Azure AD), ne sera plus disponible à partir du 7 novembre 2018. Cette mise hors service n’a pas d’impact sur le modèle de complément SharePoint, qui utilise le https://accounts.accesscontrol.windows.net nom d’hôte (qui n’est pas affecté par cette mise hors service). Pour plus d’informations, reportez-vous à Conséquences du retrait du contrôle d’accès Azure pour les compléments SharePoint.

Dans certains cas, un complément peut demander l’autorisation d’accéder aux ressources SharePoint à la volée ; autrement dit, un complément peut demander l’autorisation d’accéder aux ressources SharePoint de manière dynamique lors de l’exécution, et non au moment de l’installation du complément. Ce type de complément n’a pas besoin d’être lancé depuis SharePoint ou même d’être installé sur SharePoint. Par exemple, il peut s’agir d’un complément de périphérique natif, d’un complément lancé depuis n’importe quel site web ou d’un complément Office lancé à partir d’une application Office qui souhaite accéder à des ressources sur SharePoint à la volée.

Remarque

Ce type de complément ne peut être exécuté que par les utilisateurs disposant des autorisations Gérer sur les ressources auxquelles le complément souhaite accéder. Par exemple, si un complément demande seulement une autorisation en lecture pour un site web, un utilisateur doté de droits d'accès en lecture, mais pas en gestion, sur le site web ne peut pas exécuter le complément.

Pour pouvoir appeler SharePoint, ce type de complément doit d’abord être inscrit via le Tableau de bord du vendeur ou la page AppRegNew.aspx. Pour plus d’informations sur l’inscription des compléments via le Tableau de bord du vendeur ou AppRegNew.aspx, consultez la rubrique Enregistrement des compléments SharePoint.

Une fois votre complément enregistré, il devient un principal de sécurité et possède une identité, tout comme les utilisateurs et les groupes. Cette identité est qualifiée de principal de complément. Comme les utilisateurs et les groupes, un principal de complément dispose de certaines autorisations. Pour plus d’informations sur les principaux de complément, consultez la rubrique Enregistrement des compléments SharePoint.

Lorsque vous inscrivez le complément, vous obtenez un ID client, une clé secrète client, un domaine de complément et un URI de redirection pour le principal de complément. Ces informations sont inscrites auprès du serveur d’autorisation, Microsoft Azure Access Control Service (ACS).

Flux OAuth avec code d’autorisation pour compléments demandant des autorisations à la volée

Cette section résume l’authentification OAuth et le flux d’autorisation pour un complément SharePoint demandant des autorisations à la volée. Le flux est appelé flux de code d’autorisation. La séquence décrit comment un complément qui n’est pas lancé depuis SharePoint peut accéder aux ressources dans SharePoint.

Remarque

Le flux implique une série d’interactions entre votre complément, SharePoint, le serveur d’autorisation (c’est-à-dire ACS) et l’utilisateur final lors de l’exécution. Par conséquent, le flux requiert SharePoint Online ou une batterie de serveurs SharePoint connectée à Internet pour pouvoir communiquer avec ACS. Les batteries de serveurs SharePoint qui ne sont pas connectées à Internet doivent utiliser le système d’autorisation à haut niveau de fiabilité.

Il doit y avoir une application web ou un service hébergé séparément de SharePoint. Même si le complément est un complément de périphérique, il doit disposer d’une application web ou d’une URL de service qui peut être enregistrée avec ACS, même si le composant web n’est utilisé pour rien d’autre.

À des fins de simplicité, cet article part du principe que le complément est une application web appelée Contoso.com. L’application utilise le modèle objet client SharePoint (CSOM) ou les API REST de SharePoint pour transmettre des appels à SharePoint. Lorsque l’application tente d’accéder à SharePoint pour la première fois, SharePoint demande à ACS un code d’autorisation qu’il peut envoyer à l’application Contoso.com. L’application peut ensuite utiliser le code d’autorisation pour demander à ACS un jeton d’accès. Une fois qu’elle a le jeton d’accès, l’application Contoso.com l’inclut dans toutes ses requêtes en direction de SharePoint.

Exemple détaillé du flux

Supposons que Contoso propose un service d’impression de photos en ligne. Un utilisateur souhaite imprimer des photos. Il souhaite permettre à un service d’impression de photos Contoso d’accéder à un ensemble de bibliothèques de photos et d’imprimer des photos à partir de celles-ci. L’utilisateur gère ces bibliothèques de photos sur un site SharePoint Online fabrikam.sharepoint.com.

Vue d’ensemble d’OAuth

L’application d’impression de photos est inscrite, de telle sorte qu’elle a un ID client, une clé secrète client et un URI de redirection. L’URI de redirection fourni par Contoso lors de l’inscription du complément est https://contoso.com/RedirectAccept.aspx. Les informations d’ID client et de clé secrète client sont stockées dans le fichier web.config de l’application d’impression de photos. L’exemple qui suit illustre la manière dont l’ID client et la clé secrète client sont entrés dans le fichier web.config.

<configuration>
  <appSettings>
    <add key="ClientId" value="c78d058c-7f82-44ca-a077-fba855e14d38 "/>
    <add key="ClientSecret" value="SbALAKghPXTjbBiLQZP+GnbmN+vrgeCMMvptbgk7T6w= "/>
  </appSettings>
</configuration>

Étapes de flux de code d’autorisation

Voici les étapes décrites dans le flux du code d’autorisation.

Conseil

Ces étapes font référence aux méthodes du fichier TokenHelper.cs. Ce code géré n’étant pas compilé, il n’y a pas de rubriques de référence. Cependant, le fichier est entièrement commenté et comporte des descriptions de chaque classe, paramètre de membre et valeur renvoyée. Pensez à laisser une copie de ce fichier ouverte pour pouvoir vous y référer à mesure que vous parcourez ces étapes.

Étape 1 : le client ouvre une application, puis la dirige vers un site SharePoint pour les données

Flux OAuth à trois étapes – Étape 1

Un utilisateur accède au site web d’impression de photos Contoso, où l’interface utilisateur indique que l’utilisateur peut imprimer des photos conservées sur n’importe quel site SharePoint Online.

Dans cet exemple, l’URL est https://contoso.com/print/home.aspx

Le complément d’impression de photos demande à l’utilisateur d’entrer l’URL de la collection de photos. L’utilisateur entre une URL pointant vers le site SharePoint Online : https://fabrikam.sharepoint.com/

Étape 2 : le complément est redirigé vers l’URL d’autorisation du site SharePoint

Flux OAuth à trois étapes – Étape 2

Lorsque l’utilisateur utilise le bouton permettant d’obtenir les photos, le complément d’impression de photos Contoso redirige le navigateur vers https://fabrikam.sharepoint.com/ ; cette redirection est une réponse de redirection HTTP 302.

Si vous utilisez Microsoft .NET, Response.Redirect vous permet d’effectuer une redirection à partir de votre code. À l’aide du fichier TokenHelper.cs dans votre projet, votre code peut appeler la méthode de GetAuthorizationUrl surchargée (à l’aide de la surcharge avec trois arguments). Cette méthode crée l'URL de redirection OAuthAuthorize.aspx à votre place. Votre code peut également créer manuellement l’URL.

Par exemple, si vous choisissez d’appeler la méthode GetAuthorizationUrl pour créer l’URL de redirection OAuthAuthorize.aspx pour vous, en utilisant le fichier TokenHelper.cs dans votre projet, le code est le suivant : 

Response.Redirect(
  TokenHelper.GetAuthorizationUrl(
    sharePointSiteUrl.ToString(),
    "Web.Read List.Write",
    "https://contoso.com/RedirectAccept.aspx"
  )
);

Si vous examinez la surcharge à trois paramètres de la méthode GetAuthorizationUrl dans le fichier TokenHelper.cs, vous constatez que le deuxième paramètre est un paramètre d’étendue d’autorisation, soit une liste d’autorisations délimitée par des espaces, demandées par le complément au format abrégé. Pour plus d’informations sur les étendues d’autorisation, consultez la rubrique Alias d’étendue d’autorisation et utilisation de la page OAuthAuthorize.aspx.

Le troisième paramètre doit être le même URI de redirection que celui utilisé lorsque le complément est inscrit. Pour plus d’informations sur l’inscription, consultez la rubrique Enregistrement de compléments SharePoint. La chaîne renvoyée est une URL incluant des paramètres de chaîne de requête. Si vous préférez, vous pouvez construire manuellement l’URL de redirection OAuthAuthorize.aspx. Par exemple, l’URL vers laquelle le complément d’impression de photos Contoso renvoie l’utilisateur dans ce cas est (Ajout de sauts de ligne pour plus de lisibilité) :

https://fabrikam.sharepoint.com/_layouts/15/OAuthAuthorize.aspx?
    client_id=client_GUID
    &scope=app_permissions_list
    &response_type=code
    &redirect_uri=redirect_uri

Comme le montre l’exemple, le complément d’impression de photos Contoso envoie l’ID client OAuth et l’URI de redirection au site Fabrikam sous forme de paramètres de chaîne de requête. Voici un exemple de la demande GET avec des exemples de valeurs de chaîne de requête. L’URL cible réelle forme une seule ligne.

GET /_layouts/15/OAuthAuthorize.aspx?client_id=c78d058c-7f82-44ca-a077-fba855e14d38&scope=list.read&response_type=code&redirect_uri=https%3A%2F%2Fcontoso%2Ecom%2Fredirectaccept.aspx HTTP/1.1
Host: fabrikam.sharepoint.com

Si vous souhaitez une fenêtre contextuelle de consentement distincte, vous pouvez ajouter le paramètre de requête IsDlg=1 à la création de l’URL, comme indiqué ci-dessous : /oauthauthorize.aspx?IsDlg=1&client_id=c78d058c-7f82-44ca-a077-fba855e14d38&scope=list.read&response_type=code&redirect_uri=https%3A%2F%2Fcontoso%2Ecom%2Fredirectaccept.aspx

Étape 3 : SharePoint affiche la page de consentement afin que l’utilisateur puisse accorder les autorisations au complément.

Flux OAuth à trois étapes – Étape 3

Si l’utilisateur n’est pas déjà connecté au site SharePoint Online Fabrikam, il est invité à le faire. Lorsque l’utilisateur est connecté, SharePoint affiche une page de consentement HTML. La page de consentement invite l’utilisateur à accorder (ou refuser) au complément d’impression de photos Contoso les autorisations demandées par le complément. Dans ce cas, l’utilisateur peut accorder au complément l’accès en lecture à la bibliothèque d’images de l’utilisateur sur Fabrikam.

Étape 4 : SharePoint demande à ACS un code d’autorisation à durée de vie limitée

Flux OAuth à trois étapes – Étape 4

Le site SharePoint Online Fabrikam demande au service ACS de créer un code d'autorisation à durée limitée (environ 5 minutes) unique pour cette combinaison utilisateur/complément. ACS envoie le code d’autorisation au site Fabrikam.

Étape 5 : le site SharePoint Online est redirigé vers l’URI de redirection inscrit de l’application, en transmettant le code d’autorisation au complément

Flux OAuth à trois étapes – Étape 5

Le site SharePoint Online de Fabrikam redirige le navigateur vers Contoso via la réponse HTTP 302. La construction d’URL pour cette redirection utilise l’URI de redirection qui a été spécifié lors de l’inscription du complément d’impression de photos. Il inclut également le code d’autorisation sous la forme d’une chaîne de requête.

L’URL de redirection est structurée comme suit : https://contoso.com/RedirectAccept.aspx?code=[authcode]

Étape 6 : le complément utilise le code d’autorisation pour demander un jeton d’accès au service ACS ; celui-ci valide la demande, invalide le code d’autorisation et envoie les jetons d’accès et d’actualisation au complément

Flux OAuth à trois étapes – Étape 6

Contoso récupère le code d'autorisation du paramètre de requête, puis l'inclut avec l'ID client et la clé secrète client dans une demande de jeton d'accès envoyée à ACS.

Si vous utilisez du code managé et le fichier CSOM SharePoint, le fichier TokenHelper.cs, méthode qui effectue la demande auprès d’ACS, est GetClientContextWithAuthorizationCode. Dans ce cas, le code ressemble à ce qui suit (où authCode est une variable à laquelle le code d’autorisation a été affecté) :

TokenHelper.GetClientContextWithAuthorizationCode(
  "https://fabrikam.sharepoint.com/",
  "00000003-0000-0ff1-ce00-000000000000",
  authCode,
  "1ee82b34-7c1b-471b-b27e-ff272accd564",
  new Uri(Request.Url.GetLeftPart(UriPartial.Path))
);

Si vous examinez le fichier TokenHelper.cs, le deuxième paramètre de la méthode GetClientContextWithAuthorizationCode est le targetPrincipalName. Cette valeur est toujours la constante 00000003-0000-0ff1-ce00-000000000000 dans un complément qui accède à SharePoint. Si vous suivez la hiérarchie d’appels à partir de GetClientContextWithAuthorizationCode, cette méthode obtient l’ID client et la clé secrète à partir du fichier web.config.

ACS reçoit la demande de Contoso et valide l’ID client, la clé secrète client, l’URI de redirection et le code d’autorisation. Si tous sont valables, ACS invalide le code d’autorisation (il ne peut être utilisé qu’une seule fois) et crée un jeton d’actualisation et un jeton d’accès, qu’il renvoie à Contoso. L’application Contoso peut mettre en cache ce jeton d’accès pour le réutiliser lors de demandes ultérieures. Par défaut, les jetons d’accès sont efficaces pendant 12 heures environ.

Chaque jeton d’accès est spécifique au compte d’utilisateur spécifié dans la demande d’autorisation d’origine et il n’accorde l’accès qu’aux services spécifiés dans cette demande. Votre complément doit stocker le jeton d’accès de manière sécurisée. L’application Contoso peut également mettre en cache le jeton d’actualisation. Par défaut, les jetons d’actualisation sont efficaces pendant six mois. Le jeton d’actualisation peut être échangé contre un nouveau jeton d’accès émis par ACS à chaque fois que le jeton d’accès expire.

Pour plus d’informations sur les jetons, consultez la rubrique Gestion des jetons de sécurité dans les compléments SharePoint à faible niveau de fiabilité hébergés par le fournisseur.

Étape 7 : le complément peut désormais utiliser le jeton d’accès pour demander des données au site SharePoint afin de les afficher ensuite pour l’utilisateur

Flux OAuth à trois étapes – Étape 7

Contoso contient le jeton d'accès nécessaire pour envoyer un appel d'API REST ou une demande CSOM à SharePoint, en insérant le jeton d'accès OAuth dans l'en-tête HTTP Authorization. SharePoint renvoie des informations demandées par Contoso.

Pour en savoir plus sur la réalisation de cette demande, consultez la rubrique Gestion des jetons de sécurité dans les compléments SharePoint à faible niveau de fiabilité hébergés par le fournisseur.

Alias d’étendue d’autorisation et utilisation de la page OAuthAuthorize.aspx

Cette section suppose que vous connaissez l’article Autorisations des compléments dans SharePoint. Le Tableau 1 présente les URI d’étendue de demande d’autorisation de complément indiqués dans cet article, à la différence qu’il comporte une colonne supplémentaire (Alias d’étendue) et que le droit Contrôle total n’est pas disponible dans la colonne Droits disponibles, car un complément qui demande l’autorisation d’accéder à des ressources SharePoint à la volée ne peut pas demander le droit Contrôle total.

Les valeurs figurant dans la colonne Alias d’étendue sont des versions raccourcies de leurs équivalents dans la colonne URI d’étendue. Les alias ne peuvent être utilisés que par des compléments qui demandent l’autorisation d’accéder aux ressources SharePoint à la volée. (Les valeurs d’URI d’étendue sont utilisées dans le manifeste de complément des compléments lancés à partir de SharePoint. Ces compléments demandent des autorisations pendant l’installation du complément.)

Les alias d’étendue sont utilisés uniquement dans le cadre de l’utilisation de la page de redirection OAuthAuthorize.aspx. Comme le montre l’étape 2 du flux OAuth décrit dans la section précédente, lorsque le complément utilise du code géré, les alias sont utilisés lorsque vous appelez la méthode GetAuthorizationUrl du fichier TokenHelper.cs dans votre projet. Voici un autre exemple :

Response.Redirect(TokenHelper.GetAuthorizationUrl(
    sharePointSiteUrl.ToString(),
    "Web.Read List.Write ",
    "https://contoso.com/RedirectAccept.aspx ")
);

La valeur du paramètre étendue, Web.Read List.Write, est un exemple de la manière dont vous pouvez demander des autorisations à l’aide des alias d’étendue. Le paramètre étendue est un ensemble séparé par des espaces de l’étendue d’autorisation et des demandes de droit.

Si vous n’utilisez pas de code managé, les alias d’étendue sont utilisés dans le champ de l’étendue dans l’URL de redirection. Par exemple :

https://fabrikam.sharepoint.com/_layout/15/OAuthAuthorize.aspx?client_id=c78d058c-7f82-44ca-a077-fba855e14d38&scope=list.write&response_type=code&redirect_uri=https%3A%2F%2Fcontoso%2Ecom%2Fredirectaccept.aspx

Remarque

Pour obtenir une description des étendues, consultez la rubrique Autorisations de complément dans SharePoint.

Tableau 1. URI d’étendue de demande d’autorisation de complément SharePoint et les alias connexes

URI d’étendue Alias d’étendue Droits disponibles
https://sharepoint/content/sitecollection Site Lecture, Écriture, Gestion
https://sharepoint/content/sitecollection/web Web Lecture, Écriture, Gestion
https://sharepoint/content/sitecollection/web/list Répertorier Lecture, Écriture, Gestion
https://sharepoint/content/tenant AllSites Lecture, Écriture, Gestion
https://sharepoint/bcs/connection Aucun (non pris en charge actuellement) Lecture
https://sharepoint/search Rechercher QueryAsUserIgnoreAppPrincipal
https://sharepoint/projectserver ProjectAdmin Gestion
https://sharepoint/projectserver/projects Projets Lecture, Écriture
https://sharepoint/projectserver/projects/project Projet Lecture, Écriture
https://sharepoint/projectserver/enterpriseresources ProjectResources Lecture, Écriture
https://sharepoint/projectserver/statusing ProjectStatusing SubmitStatus
https://sharepoint/projectserver/reporting ProjectReporting Lecture
https://sharepoint/projectserver/workflow ProjectWorkflow Élever
https://sharepoint/social/tenant AllProfiles Lecture, Écriture, Gestion
https://sharepoint/social/core Social Lecture, Écriture, Gestion
https://sharepoint/social/microfeed Microfeed Lecture, Écriture, Gestion
https://sharepoint/taxonomy TermStore Lecture, Écriture

URI de redirection et exemple de page de redirection

L’URI de redirection utilisé par les compléments demandant des autorisations à la volée est l’URI vers lequel SharePoint redirige le navigateur après accord de consentement (avec le code d’autorisation inclus comme paramètre de requête). L’étape 2 du flux OAuth fournit un exemple dans lequel l’URI est codé en dur dans un appel vers la méthode GetAuthorizationUrl. Sinon, un complément ASP.NET peut également stocker l’URI de redirection dans le fichier web.config, comme illustré dans l’exemple suivant :

<configuration>
  <appSettings>
    <add key="RedirectUri" value="https://contoso.com/RedirectAccept.aspx" />
  </appSettings>
<configuration>

Appelez WebConfigurationManager.AppSettings.Get("RedirectUri") pour récupérer la valeur.

L’extrémité vers l’RedirectUri obtient le code d’autorisation à partir du paramètre de requête et l’utilise pour obtenir un jeton d’accès, qui peut ensuite être utilisé pour accéder à SharePoint. En règle générale, l’extrémité est la même page, méthode de contrôleur ou méthode web que celle qui a tenté d’accéder à l’origine à SharePoint. Toutefois, il peut s’agir d’une page ou d’une méthode qui reçoit uniquement le jeton d’autorisation et qui redirige vers une autre page ou méthode. La page ou méthode spéciale peut transmettre le jeton d’autorisation ou le mettre en cache. (Il a une durée de vie de cinq minutes environ.) Elle peut également utiliser le jeton d’autorisation pour obtenir un jeton d’accès qu’elle met en cache.

Importante

Les RedirectUri doivent être au même point de terminaison que celles répertoriées lors de la création de l’application dans la page AppRegNew. aspx.

Voici un exemple du code-behind de ce type de page dans une application ASP.NET. Tenez compte des informations suivantes à propos de ce code :

  • Il utilise le fichier TokenHelper.cs qui est généré par les Outils de développement Office pour Visual Studio.
  • Le code part du principe qu’un paramètre de requête « code » contient un code d’autorisation. Cette page est fiable, car elle est appelée uniquement par SharePoint et uniquement lorsqu'elle transmet un code d'autorisation.
  • Il utilise l'objet de contexte client CSOM pour accéder à SharePoint, mais aurait pu avoir mis l'objet en cache sur le serveur et l'avoir redirigé vers une autre page.
  • La méthode GetClientContextWithAuthorizationCode utilise le code d’autorisation pour obtenir un code d’accès. Elle crée ensuite un objet de contexte client SharePoint, puis modifie le gestionnaire de l’objet pour l’événement ExecutingWebRequest afin que le gestionnaire inclut le jeton d’accès dans toutes les demandes adressées à SharePoint. Le jeton d’accès est, dans les faits, mis en cache à l’intérieur de l’objet.
  • La méthode GetClientContextWithAuthorizationCode renvoie l'URL de redirection à ACS dans le paramètre rUrl, mais le service ACS l'utilise comme une forme d'identification en cas de vol du code d'autorisation. Le service ACS ne l'utilise pas pour effectuer une autre redirection, de manière à ce qu'il n'exécute pas une boucle sans fin le redirigeant sur lui-même.
  • Le code ne prévoit aucune configuration pour traiter un jeton d’accès qui a expiré. Une fois l’objet de contexte client créé, il continue d’utiliser le même jeton d’accès. Il n’utilise plus du tout le jeton d’actualisation. C’est une stratégie appropriée pour les compléments utilisés uniquement dans des sessions d’une durée de vie inférieure à celle d’un jeton d’accès.

Pour obtenir un exemple plus complexe de l’utilisation du jeton d’actualisation pour récupérer un nouveau jeton d’accès, reportez-vous à la section suivante.

public partial class RedirectAccept : System.Web.UI.Page
{
  protected void Page_Load(object sender, EventArgs e)
  {
    string authCode = Request.QueryString["code"];
    Uri rUri = new Uri("https://contoso.com/RedirectAccept.aspx");

    using (ClientContext context = TokenHelper.GetClientContextWithAuthorizationCode(
        "https://fabrikam.sharepoint.com/",
        "00000003-0000-0ff1-ce00-000000000000",
        authCode,
        "1ee82b34-7c1b-471b-b27e-ff272accd564".
        rUri))
    {
      context.Load(context.Web);
      context.ExecuteQuery();

      Response.Write("<p>" + context.Web.Title + "</p>");
    }
  }
}

Exemple de code-behind pour une page accédant à SharePoint

Voici le code-behind pour une page Default.aspx. Cette page suppose un scénario dans lequel la page Default est à la fois la page de démarrage du complément et l’URL de redirection inscrite pour le complément. Tenez compte des informations suivantes à propos de ce code :

  • La méthode Page_Load recherche d’abord un code d’autorisation dans la chaîne de requête. Il en existe une si le navigateur a été redirigé vers la page par SharePoint. Dans ce cas, le code l’utilise pour obtenir un nouveau jeton d’actualisation, qu’il met en cache dans un cache durable qui perdure au fil des sessions.

  • La méthode recherche ensuite un jeton d’actualisation dans le cache.

    • Si ce n’est pas le cas, elle en indique à SharePoint les autorisations dont elle a besoin (autorisation d’écriture sur l’étendue web) et demande à SharePoint un code d'autorisation. L’utilisateur est invité à accorder l’autorisation et, si son octroi est accordé, SharePoint obtient le code d’autorisation d’ACS et le renvoie sous forme de paramètre de requête sur une redirection vers cette même page.
    • S’il existe un jeton d’actualisation mis en cache, la méthode l’utilise pour obtenir un jeton d’accès directement auprès d’ACS. Comme dans l’exemple à la fin de la section précédente de cet article, le jeton d’accès est utilisé pour créer un objet de contexte client SharePoint. L’utilisation d’un jeton d’actualisation mis en cache pour obtenir un jeton d’accès directement auprès d’ACS évite un appel réseau supplémentaire vers SharePoint lors du démarrage de la session. Ainsi, les utilisateurs qui relancent l’exécution du complément au cours de la durée de vie du cache de jeton d’actualisation bénéficient d’un démarrage plus rapide.

  • Comme dans l’exemple à la fin de la section précédente, ce code ne prévoit aucune configuration pour traiter un jeton d’accès qui a expiré. Une fois l’objet de contexte client créé, il continue d’utiliser le même jeton d’accès. L’une des manières de se protéger d’un jeton d’accès qui a expiré consiste à mettre en cache le jeton d’accès, en plus du jeton d’actualisation. Vous pouvez ensuite modifier le code suivant pour qu’il appelle la méthode GetAccessToken uniquement en l’absence d’un jeton d’accès non expiré dans le cache.

    Toutefois, s’il est acceptable que le jeton d’actualisation soit mis en cache sur le client, dans un cookie par exemple, le jeton d’accès doit se trouver uniquement dans un cache côté serveur pour des raisons de sécurité. Le jeton d’actualisation est chiffré et ne peut être déchiffré que par ACS. Mais le jeton d’accès est codé de manière simple (codage base 64) et peut facilement être décodé par une attaque de l’intercepteur.

  • La classe TokenCache indiquée dans ce code est définie plus loin dans cette section.

Code-behind pour une page Default.aspx

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using Microsoft.SharePoint.Samples;
using Microsoft.SharePoint.Client;

namespace DynamicAppPermissionRequest
{
  public partial class Default : System.Web.UI.Page
  {
    protected void Page_Load(object sender, EventArgs e)
    {
      Uri sharePointSiteUrl = new Uri("https://fabrikam.sharepoint.com/print/");

      if (Request.QueryString["code"] != null)
      {
        TokenCache.UpdateCacheWithCode(Request, Response, sharePointSiteUrl);
      }

      if (!TokenCache.IsTokenInCache(Request.Cookies))
      {
        Response.Redirect(TokenHelper.GetAuthorizationUrl(sharePointSiteUrl.ToString(), "Web.Write"));
      }
      else
      {
        string refreshToken = TokenCache.GetCachedRefreshToken(Request.Cookies);
        string accessToken =
        TokenHelper.GetAccessToken(
                    refreshToken,
                    "00000003-0000-0ff1-ce00-000000000000",
                    sharePointSiteUrl.Authority,
                    TokenHelper.GetRealmFromTargetUrl(sharePointSiteUrl)).AccessToken;

        using (ClientContext context =
                TokenHelper.GetClientContextWithAccessToken(sharePointSiteUrl.ToString(),
                                                            accessToken))
        {
          context.Load(context.Web);
          context.ExecuteQuery();

          Response.Write("<p>" + context.Web.Title + "</p>");
        }
      }
    }
  }
}

Voici un exemple de code pour un module du cache du jeton appelé par le précédent exemple de code. Il utilise des cookies comme cache. Il existe d’autres options de mise en cache. Pour plus d’informations, consultez la rubrique Gestion des jetons de sécurité dans les compléments SharePoint à faible niveau de fiabilité hébergés par le fournisseur.

Exemple de code pour un module du cache du jeton

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using Microsoft.SharePoint.Samples;

namespace DynamicAppPermissionRequest
{
  public static class TokenCache
  {
    private const string REFRESH_TOKEN_COOKIE_NAME = "RefreshToken";

    public static void UpdateCacheWithCode(HttpRequest request,
                                            HttpResponse response,
                                            Uri targetUri)
    {
      string refreshToken =
          TokenHelper.GetAccessToken(
              request.QueryString["code"],
              "00000003-0000-0ff1-ce00-000000000000",
              targetUri.Authority,
              TokenHelper.GetRealmFromTargetUrl(targetUri),
              new Uri(request.Url.GetLeftPart(UriPartial.Path))
          ).RefreshToken;
      SetRefreshTokenCookie(response.Cookies, refreshToken);
      SetRefreshTokenCookie(request.Cookies, refreshToken);
    }

    internal static string GetCachedRefreshToken(HttpCookieCollection requestCookies)
    {
      return GetRefreshTokenFromCookie(requestCookies);
    }

    internal static bool IsTokenInCache(HttpCookieCollection requestCookies)
    {
      return requestCookies[REFRESH_TOKEN_COOKIE_NAME] != null;
    }

    private static string GetRefreshTokenFromCookie(HttpCookieCollection cookies)
    {
      if (cookies[REFRESH_TOKEN_COOKIE_NAME] != null)
      {
        return cookies[REFRESH_TOKEN_COOKIE_NAME].Value;
      }
      else
      {
        return null;
      }
    }

    private static void SetRefreshTokenCookie(HttpCookieCollection cookies, string refreshToken)
    {
      if (cookies[REFRESH_TOKEN_COOKIE_NAME] != null)
      {
        cookies[REFRESH_TOKEN_COOKIE_NAME].Value = refreshToken;
      }
      else
      {
        HttpCookie cookie = new HttpCookie(REFRESH_TOKEN_COOKIE_NAME, refreshToken);
        cookie.Expires = DateTime.Now.AddDays(30);
        cookies.Add(cookie);
      }
    }
  }
}

Voir aussi