Flujo de OAuth de código de autorización para Complementos de SharePoint

Nota:

Este artículo asume que está familiarizado con la creación de complementos para SharePoint que utilizan una autorización de baja confianza y con los conceptos y principios detrás de OAuth. Para obtener más información sobre OAuth, vea OAuth.net y Protocolo de autorización web (oauth).

Importante

Azure Access Control (ACS), un servicio de Azure Active Directory (Azure AD), se retirará el 7 de noviembre de 2018. Esta retirada no afecta al modelo de complemento de SharePoint, que usa el https://accounts.accesscontrol.windows.net nombre de host (que no se ve afectado por esta retirada). Para obtener más información, vea Impacto de la retirada de Azure Access Control para Complementos de SharePoint.

En algunos escenarios, un complemento puede solicitar permisos de acceso a los recursos de SharePoint al instante; es decir, un complemento puede solicitar permisos de acceso a los recursos de SharePoint dinámicamente en el runtime, en lugar de solicitarlo durante el tiempo de instalación del complemento. Este tipo de complemento no tiene que ser lanzado desde, o incluso instalado en, SharePoint. Por ejemplo, podría tratarse de un complemento de dispositivo nativo, un complemento que se inicie desde cualquier sitio web o un complemento de Office que se inicie desde una aplicación de Office que quiere tener acceso a los recursos de SharePoint al instante.

Nota:

Este tipo de complementos solo pueden ejecutarlos usuarios que tienen permisos de administración sobre los recursos a los que el complemento quiere acceder. Por ejemplo, si un complemento solicita solo un permiso de lectura para un sitio web, un usuario que tenga derechos de lectura, pero no de administración, en el sitio web no podrá ejecutar el complemento.

Para poder llamar a SharePoint, este tipo de complemento debe registrarse primero a través del Panel de vendedores o de la páginaAppRegNew.aspx. Para obtener más información sobre el registro de complementos a través del Panel de vendedores oAppRegNew.aspx, consulteconsulte Registrar complementos de SharePoint.

Después de registrar su complemento, es unaEntidad de seguridady tiene una identidad al igual que los usuarios y grupos. Esta identidad se conoce como entidad de seguridad de complemento. Como los usuarios y grupos, una entidad de seguridad de complemento tiene determinados permisos. Para obtener más información sobre las entidades de seguridad de complemento, vea Registrar complementos de SharePoint 2013.

Cuando registre el complemento, obtendrá un identificador de cliente, un secreto de cliente, un dominio de complemento y un URI de redireccionamiento para la entidad de seguridad de complemento. Esta información se registra en el servidor de autorizaciones, Microsoft Azure Access Control Service (ACS).

Flujo de OAuth para complementos que solicitan permisos al instante

En esta sección se resume el flujo de autorización y autenticación de OAuth para un complemento de SharePoint que solicita permisos al instante. El flujo se llama el flujo del Código de autorización.. La secuencia describe cómo un complemento que no es iniciado desde el interior de SharePoint puede acceder a los recursos de SharePoint.

Nota:

El flujo implica una serie de interacciones entre el complemento, SharePoint, el servidor de autorización (que es ACS) y el usuario final durante el tiempo de ejecución. Por lo que el flujo requiere SharePoint Online o una granja de SharePoint que esté conectada a Internet, para que pueda comunicarse con ACS. Las granjas de SharePoint que no están conectadas a Internet deben usar el sistema de autorización de elevada confianza.

Tiene que haber una aplicación o un servicio web que se hospede separado de SharePoint. Aunque el complemento sea un complemento de dispositivo, debe tener una dirección URL de servicio o aplicación web que se pueda registrar con ACS, aunque el componente web no se use para nada más.

Para simplificar, en este artículo se presupone que el complemento es una aplicación web llamada Contoso.com. Contoso.com utiliza el modelo de objetos de cliente (CSOM) de SharePoint o las API de REST de SharePoint para realizar llamadas a SharePoint. Cuando la aplicación intenta tener acceso por primera vez a SharePoint, SharePoint solicita un código de autorización a ACS que puede enviar a la aplicación de Contoso.com. Después, la aplicación usa el código de autorización para solicitar un token de acceso a ACS. Cuando tiene el token de acceso, la aplicación de Contoso.com lo incluye en todas sus solicitudes a SharePoint.

Ejemplo detallado del flujo

Suponga que Contoso ofrece un servicio de impresión fotográfica en línea. Un usuario quiere imprimir algunas fotos. Además, quiere conceder autorización de acceso al servicio de impresión fotográfica de Contoso para imprimir fotos de un conjunto de bibliotecas de fotos que el usuario tiene en un sitio de SharePoint Online, fabrikam.sharepoint.com.

La aplicación de impresión fotográfica se registra para disponer de un identificador de cliente, un secreto de cliente y un URI de redireccionamiento. El URI de redireccionamiento que Contoso proporcionó durante el registro del complemento es https://contoso.com/RedirectAccept.aspx. La información de identificador de cliente y secreto de cliente se incluye en el archivo Web.config de la aplicación de impresión fotográfica. Este es un ejemplo de cómo se especifica la información de identificador de cliente y secreto de cliente en el archivo Web.config.

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

Pasos del flujo del Código de autorización

A continuación se detallan los pasos del flujo del Código de autorización.

Sugerencia

Estos pasos se refieren a los métodos del archivo TokenHelper.cs. Este código administrado no está compilado, así que no hay temas de referencia para él. No obstante, el archivo en sí está comentado con descripciones de toda clase, parámetros de miembro y valores devueltos. Contemple tener una copia de este archivo abierta para consultar a medida que lea estos pasos.

Paso 1: El cliente abre una aplicación y la dirige a un sitio de SharePoint para obtener datos.

Un usuario explora el sitio web de impresión fotográfica de Contoso, donde la interfaz de usuario indica que el usuario puede imprimir fotos que se guardan en cualquier sitio de SharePoint Online.

En este ejemplo, la dirección URL es https://contoso.com/print/home.aspx

El complemento de impresión fotográfica pide al usuario que escriba la dirección URL de la colección de fotos. El usuario escribe una dirección URL que apunta al sitio de SharePoint Online: https://fabrikam.sharepoint.com/

Paso 2: El complemento se redirige a la dirección URL de autorización del sitio de SharePoint.

Cuando el usuario selecciona el botón para obtener las fotos, el complemento de impresión fotográfica de Contoso redirige el explorador a https://fabrikam.sharepoint.com/. Este redireccionamiento es una respuesta de redireccionamiento de HTTP 302.

Si está usando Microsoft .NET, Response.Redirect es una de las varias maneras en que puede hacer la redirección desde su código. Al usar el archivo TokenHelper.csen su proyecto, su código puede llamar al método de sobrecarga GetAuthorizationUrl(usando la sobrecarga con tres argumentos). Este método construye la URL de redireccionamiento OAuthAuthorize.aspxpara usted. O, su código puede construir manualmente la URL.

Por ejemplo, si elige llamar al GetAuthorizationUrlmétodo para construir el URL de redireccionamientoOAuthAuthorize.aspxpara usted, usando elTokenHelper.cs en su proyecto, el código es el siguiente:

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

Si observa la sobrecarga de tres parámetros del GetAuthorizationUrlmétodo en TokenHelper.cs, se ve que el segundo parámetro es un parámetro de alcance de permisos, que es una lista delimitada por el espacio de los permisos que el complemento solicita en formato abreviado. Para obtener más información sobre los ámbitos de permisos, vea Alias de ámbito de permiso y el uso de la página OAuthAuthorize.aspx.

El tercer parámetro debe ser el mismo URI de redireccionamiento que se usa al registrar el complemento. Para obtener más información sobre el registro, vea Registrar complementos de SharePoint. La cadena devuelta es una dirección URL como parámetros de cadena de la consulta. Si lo prefiere, puede construir manualmente el URL de redireccionamientoOAuthAuthorize.aspx. Por ejemplo, la URL a la que el complemento de impresión fotográfica Contoso redirige al usuario en este caso es (se agregan saltos de línea para facilitar la lectura):

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

Como se muestra en el ejemplo, el complemento de impresión fotográfica de Contoso envía el identificador de cliente y el URI de redireccionamiento de OAuth al sitio de Fabrikam como parámetro de cadena de consulta. Este es un ejemplo de la solicitud GET con valores de cadena de consulta de ejemplo. El URL del objetivo real es una sola línea.

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 quiere que el consentimiento aparezca en un cuadro de diálogo emergente aparte, puede agregar el parámetro de consulta IsDlg=1 a la construcción de dirección URL tal y como se muestra aquí: /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

Paso 3: SharePoint muestra la página de consentimiento para que el usuario pueda otorgar los permisos del complemento.

Si el usuario aún no ha iniciado sesión en el sitio de Fabrikam SharePoint Online, se le pide que lo haga. Cuando el usuario haya iniciado sesión, SharePoint representará una página HTML de consentimiento. La página de consentimiento solicita al usuario que conceda (o deniegue) al complemento de impresión fotográfica de Contoso los permisos que solicita. En este caso, el usuario podría conceder al complemento acceso de lectura a la biblioteca de imágenes del usuario de Fabrikam.

Paso 4: SharePoint pide un código de autorización de corta duración a ACS.

El sitio de Fabrikam de SharePoint Online solicita a ACS la creación de un código de autorización de corta duración (aproximadamente 5 minutos) único para esta combinación de usuario y complemento. ACS envía el código de autorización al sitio de Fabrikam.

Paso 5: El sitio de SharePoint Online se redirige al URI de redireccionamiento registrado de la aplicación y pasa el código de autorización al complemento.

El sitio de Fabrikam de SharePoint Online redirige el explorador a Contoso a través de la respuesta HTTP 302. La construcción de la URL para esta redirección utiliza la URI de redirección que se especificó cuando se registró el complemento de impresión fotográfica. También incluye el código de autorización como cadena de consulta.

La dirección URL de redireccionamiento se estructura de forma similar a la siguiente: https://contoso.com/RedirectAccept.aspx?code=[authcode]

Paso 6: El complemento usa el código de autorización para pedir un token de acceso a ACS, que valida la solicitud, invalida el código de autorización y, por último, envía tokens de acceso y actualización al complemento.

Contoso recupera el código de autorización a partir del parámetro de la consulta y lo incluye, junto con el identificador de cliente y el secreto de cliente, en una solicitud a ACS de un token de acceso.

Si se utiliza el código administrado y el CSOM de SharePoint, el archivoTokenHelper.csel método que realiza la solicitud a ACS esGetClientContextWithAuthorizationCode. En este caso, el código es similar al siguiente (donde authCode es una variable a la que se ha asignado el código de autorización):

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 observa el archivoTokenHelper.csel segundo parámetro del método GetClientContextWithAuthorizationCodetargetPrincipalName. Este valor corresponde siempre la constante 00000003-0000-0ff1-ce00-000000000000 en un complemento que obtiene acceso a SharePoint. Si realiza el seguimiento de la jerarquía de llamadas desde GetClientContextWithAuthorizationCode, este obtiene el identificador de cliente y el secreto de cliente del archivo Web.config.

ACS recibe la solicitud de Contoso y valida el identificador de cliente, el secreto de cliente, el URI de redireccionamiento y el código de autorización. Si todos son válidos, ACS invalida el código de autorización (puede usarse una sola vez) y crea un token de actualización y un token de acceso que devuelve a Contoso. La aplicación Contoso puede almacenar en caché este token de acceso para su reutilización en solicitudes posteriores. De forma predeterminada, los tokens de acceso son válidos durante aproximadamente 12 horas.

Cada token de acceso es específico para la cuenta de usuario que se especifica en la solicitud original de autorización y solo concede acceso a los servicios que se especifican en esa solicitud. El complemento tiene que almacenar el token de acceso de forma segura. La aplicación Contoso también puede almacenar en caché el token de actualización. Por defecto, los tokens de actualización son válidas durante seis meses. El token de actualización se puede canjear por un nuevo token de acceso de ACS cuando expire el token de acceso.

Para obtener más información sobre el usuario de tokens, vea Controlar tokens de seguridad en los complementos de SharePoint de baja confianza hospedados por el proveedor.

Paso 7: El complemento puede usar ahora el token de acceso para solicitar datos del sitio de SharePoint, que puede mostrar al usuario.

Contoso incluye el token de acceso para hacer una llamada a la API REST o enviar una solicitud de CSOM a SharePoint, pasando el token de acceso de OAuth que hay en el encabezado HTTP Authorization. SharePoint devuelve la información que Contoso ha solicitado.

Para obtener más información sobre cómo se realiza esta solicitud, vea Controlar tokens de seguridad en los complementos de SharePoint de baja confianza hospedados por el proveedor.

El alias del ámbito de permisos y la páginaOAuthAuthorize.aspx

Esta sección asume que está familiarizado con el artículo Permisos de complementos en SharePoint. La tabla 1 muestra los mismos identificadores URI de ámbito de solicitud de permisos de complemento que se indican en ese artículo, excepto que esta tabla tiene una columna más (Alias de ámbito) y el derecho de control total no está disponible en la columna Derechos disponibles, ya que los complementos que solicitan permiso de acceso a los recursos de SharePoint al instante no pueden solicitar este derecho.

Los valores que aparecen en la columna Alias de ámbito son versiones breves de sus equivalentes en la columna URI de ámbito. Los alias solo pueden usarse con los complementos que solicitan permiso de acceso a los recursos de SharePoint al instante. (Los valores de URI de ámbito se usan en el manifiesto del complemento de los complementos que se inician desde SharePoint. Estos complementos solicitan permisos durante la instalación del complemento).

Los alias del ámbito de aplicación se utilizan únicamente en el contexto de la utilización de la página de redireccionamiento deOAuthAuthorize.aspx. Como se muestra en elpaso 2 del flujo de OAuth descrito en la sección anterior, cuando el complemento utiliza código administrado, los alias se utilizan cuando se llama GetAuthorizationUrlal método deTokenHelper.csen su proyecto. Este es otro ejemplo.

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

El valor del parámetro scope, Web.Read List.Write, es un ejemplo de cómo podría solicitar permisos con los alias de ámbito. El parámetro scope es un conjunto delimitado por espacios de solicitudes de derechos y ámbitos de permisos.

Si no está usando el código administrado, los alias de alcance se usan en el campo de alcance en la URL de redireccionamiento. Por ejemplo:

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

Nota:

Para obtener una descripción de los ámbitos, vea Permisos de complementos en SharePoint.

Tabla 1. Los URI de alcance de solicitud de permiso de complemento de SharePoint y sus alias correspondientes

URI de ámbito	Alias de ámbito	Derechos disponibles
https://sharepoint/content/sitecollection	Site	Read, Write, Manage
https://sharepoint/content/sitecollection/web	Web	Read, Write, Manage
https://sharepoint/content/sitecollection/web/list	List	Read, Write, Manage
https://sharepoint/content/tenant	AllSites	Read, Write, Manage
https://sharepoint/bcs/connection	None (no admitido actualmente)	Read
https://sharepoint/search	Search	QueryAsUserIgnoreAppPrincipal
https://sharepoint/projectserver	ProjectAdmin	Manage
https://sharepoint/projectserver/projects	Projects	Read, Write
https://sharepoint/projectserver/projects/project	Project	Read, Write
https://sharepoint/projectserver/enterpriseresources	ProjectResources	Read, Write
https://sharepoint/projectserver/statusing	ProjectStatusing	SubmitStatus
https://sharepoint/projectserver/reporting	ProjectReporting	Read
https://sharepoint/projectserver/workflow	ProjectWorkflow	Elevate
https://sharepoint/social/tenant	AllProfiles	Read, Write, Manage
https://sharepoint/social/core	Social	Read, Write, Manage
https://sharepoint/social/microfeed	Microfeed	Read, Write, Manage
https://sharepoint/taxonomy	TermStore	Read, Write

Identificadores URI de redireccionamiento y página de redireccionamiento de ejemplo

El URI de redireccionamiento que usan los complementos que solicitan permiso al instante es el identificador URI que SharePoint redirige al explorador después de concedido el consentimiento (con el código de autorización incluido como parámetro de consulta). El paso 2 del flujo de OAuth da un ejemplo en el que la URI está codificada en un método de llamadaGetAuthorizationUrl. También puede guardarse el URI de redireccionamiento del archivo Web.config en una aplicación ASP.NET, tal y como se muestra en este ejemplo:

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

El valor puede recuperarse con una llamada a WebConfigurationManager.AppSettings.Get("RedirectUri").

El punto final en el RedirectUri obtiene el código de autorización del parámetro de consulta y lo utiliza para obtener un token de acceso, que luego puede ser usado para acceder a SharePoint. Normalmente, el punto de conexión es la misma página, el método de controlador o el método web que originalmente intentó tener acceso a SharePoint. Pero, puede ser una página o un método que solo recibe el token de autorización y luego se redirige a otra página u otro método. El método o la página especial puede pasar el token de autorización o almacenarlo en caché. (Tiene una vida útil de unos 5 minutos.) Alternativamente, podría utilizar la ficha de autorización para obtener un token de acceso, que almacena en caché.

Importante

El RedirectUridebe ser el mismo punto final que el listado cuando creaste la aplicación en la páginaAppRegNew.aspx.

Este es un ejemplo del código subyacente de esa página en una aplicación ASP.NET. Tenga en cuenta lo siguiente en relación con este código:

• Utiliza el archivoTokenHelper.cs generado por las herramientas de desarrollo de Office para Visual Studio.
• El código asume que hay un "código" de parámetro de consulta que contiene un código de autorización. Esto es seguro porque la página sólo es llamada por SharePoint y sólo cuando pasa un código de autorización.
• Utiliza el objeto de contexto del cliente CSOM para acceder a SharePoint, pero también podría haber almacenado ese objeto en el servidor y redirigido a otra página.
• El métodoGetClientContextWithAuthorizationCodeutiliza el código de autorización para obtener un código de acceso. Luego crea un objeto de contexto de cliente de SharePoint y modifica el controlador del objeto en el evento ExecutingWebRequest para que incluya el token de acceso en todas las solicitudes a SharePoint. El token de acceso se almacena, de hecho, en el caché dentro del objeto.
• El métodoGetClientContextWithAuthorizationCodeenvía la URL de redireccionamiento de vuelta a ACS en el parámetro rUrl, pero ACS lo utiliza como forma de identificación en caso de que el código de autorización haya sido robado. ACS no lo usa para redirigir de nuevo, así que este código no se repite constantemente redirigiéndose a sí mismo.
• El código no tiene prevista ninguna acción en caso de que expire un token de acceso. Una vez creado, el objeto de contexto de cliente sigue usando el mismo token de acceso. No utiliza el token de actualización en absoluto. Esta es una estrategia adecuada para los complementos que solo se usan en sesiones cuya duración es inferior a la de un token de acceso.

Para ver un ejemplo más complejo que usa el token de actualización para obtener un nuevo token de acceso, vea la sección siguiente.

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>");
    }
  }
}

Código subyacente de ejemplo para una página con acceso a SharePoint

Este es el código subyacente de una página Default.aspx. Esta página presupone un escenario en el que la página Default es la página de inicio del complemento y también la dirección URL de redireccionamiento registrada para el complemento. Tenga en cuenta lo siguiente en relación con este código:

• El métodoPage_Loadprimero busca un código de autorización en la cadena de consulta. hay una si el navegador fue redirigido a la página por SharePoint. Si hay uno, el código lo usa para obtener un nuevo token de actualización, que almacena en un caché duradero que dura todas las sesiones.

• Luego, el método busca un token de actualización en la memoria caché.

  • Si no hay, obtiene uno indicando a SharePoint los permisos que necesita (permiso Write en el ámbito Web) y pide a SharePoint un código de autorización. Se le pide al usuario que conceda el permiso, y si se le concede, SharePoint obtiene el código de autorización de ACS y lo devuelve como un parámetro de consulta en una redirección a esta misma página.
  • Si hay un token de actualización en caché, el método lo utiliza para obtener un token de acceso directamente de ACS. Como en el ejemplo que figura al final de la sección anterior de este artículo, el token de acceso se utiliza para crear un objeto de contexto de cliente de SharePoint. Usar un token de actualización en caché para obtener un token de acceso directamente de ACS evita la llamada de red adicional a SharePoint al iniciar la sesión, por lo que los usuarios que vuelven a ejecutar la sesión durante la caché de tokens de actualización experimentan un inicio más rápido.

• Como en el ejemplo que figura al final de la sección anterior, este código no prevé el tratamiento de un token de acceso caducada. Una vez creado, el objeto de contexto de cliente sigue usando el mismo token de acceso. Una forma de protegerse contra un token de acceso expirado consiste en almacenar en la memoria caché el token de acceso, además del token de actualización. Después, puede modificar el código siguiente para que solo llame al método GetAccessToken si no hay un token de acceso sin expirar en la memoria caché.

  Sin embargo, si bien es aceptable que el token de actualización se almacene en la memoria caché del cliente, en una cookie, por ejemplo, el token de acceso sólo debe estar en una memoria caché del lado del servidor por razones de seguridad. El token de actualización se cifra y solo ACS puede descifrarlo. Pero el token de acceso solamente se codifica (con codificación Base 64) y se puede descodificar fácilmente mediante un ataque de tipo "Man in the middle".

• La claseTokenCache a la que se refiere este código se define más adelante en esta sección.

Código para una página 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>");
        }
      }
    }
  }
}

Este es un ejemplo de código para un módulo de caché de tokens al que el código de ejemplo anterior llama. Usa las cookies como memoria caché. Hay otras opciones de almacenamiento en caché. Para obtener más información, vea Controlar tokens de seguridad en los complementos de SharePoint de baja confianza hospedados por el proveedor.

Ejemplo de código para un token de módulo de caché

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);
      }
    }
  }
}

Consulte también

• Configurar un entorno de desarrollo local para complementos de SharePoint
• Introducción a la creación de complementos de SharePoint hospedados por el proveedor
• Crear complementos de SharePoint que usan la autorización de baja confianza
• Autorización y autenticación de complementos de SharePoint