App and User Context in API Calls
SharePoint provides the ability for
apps to make calls to SharePoint with access tokens that are either on
behalf of a user or without user context, also known as app-only
context. When an access token is used that is on behalf of a user,
SharePoint treats the call as if the user is making the call. This
means it is subject to the same permissions that user has.
Additionally, an app can make an app-only call to SharePoint, which
means no user context is passed and only the permissions that the app
has been granted apply.
The TokenHelper
class provides helper methods for getting each of these types of
tokens. To get an access token that includes the calling user’s
context, use the following method:
TokenHelper.GetAccessToken
To get an app-only access token, use the following method:
TokenHelper.GetAppOnlyAccessToken
Managing Tokens in Your Application
When an
application is launched by a user a context token is passed to it.
After this has happened it is up to the application to handle the
tokens and potentially store them for future use or pass between app
pages. These tasks are left to the application to manage because
SharePoint has no knowledge of the inner workings of the application.
The developer must decide how she wants to manage these tokens when the
application passes them after it is launched. Some basic options are
available, including the following:
- Cache the token for a period of time.
- Pass the token around as needed but don’t store it.
To assist with caching, the tokens provide a CacheKey and an expiry that can make caching more straightforward for the developer. The CacheKey
is a property on the token that is unique to that particular token. It
can be used, as the name suggests, as a primary key for that token in a
cache of the developer’s choosing, such as ASP.NET application state.
Additionally, the expiry time can be used in the application to flush
the old tokens from the cache after they have expired.
CACHE THE REFRESH TOKEN
As part of the context token, SharePoint
provides another token called a refresh token. This token is typically
valid for six months and can be used to request access tokens for a
particular user. This capability is very handy if your app needs to
make calls into SharePoint as a particular user when the user isn’t
using the app; for example, on a timed basis such as a timer job.
The following exercise walks through a simple
example of how to use ASP.NET application state to cache the
appropriate tokens so that they can be used between page requests.
TRY IT OUT: Caching Tokens (TokenCache.zip)
In this exercise you create an Autohosted application that, when run, receives and then caches the ContextToken using application state.
1. Create a
new SharePoint App project in Visual Studio by choosing File ⇒ New ⇒
Project. Select the App for SharePoint 2013 project template.
2. Name your app SharePointTokenCacheApp and click OK.
3. If required, specify the URL of your SharePoint online site for the site to use for debugging.
4. Ensure Autohosted is selected in the hosting type drop-down menu.
5. Click Finish.
6. Locate and open the TokenHelper.cs file.
7. Find the
CreateJsonWebSecurityTokenHandler function and make the function public instead of private as follows:
public static JsonWebSecurityTokenHandler CreateJsonWebSecurityTokenHandler()
8. Locate and open the
Default.aspx file and add the following code inside the
<div> tags:
<asp:Button ID="Button1" runat="server" Text="Process" OnClick="Button1_Click"/>
9. Locate and open the
Default.aspx.cs file and replace the contents with the following code:
using System;
using System.Collections.Generic;
using System.IdentityModel.Tokens;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using Microsoft.IdentityModel.S2S.Tokens;
namespace SharePointTokenCacheAppWeb.Pages
{
public partial class Default : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
if (!this.IsPostBack)
{
var contextToken =
TokenHelper.GetContextTokenFromRequest(Page.Request);
var hostWeb = Page.Request["SPHostUrl"];
JsonWebSecurityTokenHandler tokenHandler =
TokenHelper.CreateJsonWebSecurityTokenHandler();
SecurityToken securityToken = tokenHandler.ReadToken(contextToken);
JsonWebSecurityToken jsonToken =
securityToken as JsonWebSecurityToken;
SharePointContextToken token =
SharePointContextToken.Create(jsonToken);
Application[token.CacheKey] = contextToken;
Button1.CommandArgument = token.CacheKey;
}
}
protected void Button1_Click(object sender, EventArgs e)
{
var contextToken =
(string)Application[((Button) sender).CommandArgument];
var hostWeb = Page.Request["SPHostUrl"];
using (var clientContext =
TokenHelper.GetClientContextWithContextToken(hostWeb, contextToken,
Request.Url.Authority))
{
clientContext.Load(clientContext.Web, web => web.Title);
clientContext.ExecuteQuery();
Response.Write(clientContext.Web.Title);
clientContext.ToString();
}
}
}
}
10. Press F5 to run and debug the project.
11. If prompted to trust the application, click Trust It.
12. When presented with the list of apps in your site, locate and click your new application.
13. A Web page appears with the Process button on it. Click the button. The page will display the Title of your Website.
How It Works
In this exercise you created a new application that cached the ContextToken passed to it in the ASP.NET application cache. It used the CacheKey property to uniquely key the token in the cache. This allowed subsequent page requests to locate the ContextToken in the cache and use it to make API calls to SharePoint. Without caching the ContextToken in this manner, subsequent page requests or postbacks wouldn’t include the ContextToken in the POST parameters and API calls wouldn’t be possible.