When you want to use the CSOM (Client Side Object Model) with SharePoint Online, you currently have quite a few options on how to authenticate. For a SharePoint newcomer or even experienced SharePoint developers, it can be quite tricky to know when to use what, this post is an attempt to provide an overview.
The reason for this article was the SharePoint code published together with the MyShuttle example from Visual Studio Connect 2014, code can be found here. The code sample contains an Azure WebJob (MyShuttle.WebJob) that sends invoices to a SharePoint site, during the presentation of the code it’s mentioned that the sample was created with Office 365 API, but when the code was released that wasn’t the case. I also believe that the way they authenticate in the code is no longer best practice, which is why I wanted to publish this article.
How do CSOM authenticate
First things first, how does the CSOM actually authenticate when used with SharePoint online? It might not be obvious when you use the library, but everything you do in CSOM eventually turns into a REST call to SharePoint. So the CSOM library uses the REST API endpoints hosted at sharepointsite.sharepoint.com/_api/?
Hold on, not so quick, unfortunately that is not the case, because the CSOM was invented before the SharePoint product team decided that it was a good idea to have a open REST implementation. So all calls from CSOM end up at sharepointsite.sharepoint.com/_vti_bin/client.svc instead. At some point down the road we will hopefully see that the api endpoint will have the same functionality as the client.svc endpoint, and Microsoft will be able to change the implementation of the CSOM library to use the api endpoint, but that’s not where we are now.
Enough history lets get back to authentication, or in essence how do SharePoint know who we are when we call from CSOM? There are two options:
- We have a fedauth authentication cookie, that we pass along with our request
- We have an access token, that we pass along with our request in the http-header
Now, it might seem a little confusing that there are two different methods to authenticate your calls, but again it’s due to the history of SharePoint the fedauth cookie, is the old way of doing things, while the access token is the new school (OAuth2) way of doing it.
So how do you obtain either one of them? This is were it gets interesting, because depending on how you use the CSOM library you will end up with different methods of authentication. Currently there exists three practical ways to authenticate when using CSOM.
- MsOnlineClaimsHelper (fedauth)
- SharePointOnlineCredentials (fedauth)
- Acccess Token (ADAL/Office 365 API)
MsOnlineClaimsHelper
In the early days of SharePoint Online development, some smart people wrote a class named MsOnlineClaimsHelper that could be used to get the the fedauth cookie that was needed to make authenticated requests to SharePoint online. This class have since been floating around on the internet in different versions. One of the first (if not the first) blog post about it was done by Wictor Willen who was very involved in it.
A different version of this MsOnlineClaimsHelper class is also the one that Microsoft used in their MyShuttle example.
Personally I don’t think you should be using this class for SharePoint online, because SharePointOnlineCredentials class maintained by Microsoft, and part of the Microsoft.SharePoint.Client.Runtime assembly does pretty much the same.
There might be some hybrid scenarios where you might still benefit from having access to change the source code, where MsOnlineClaimsHelper is the way to go, but for everyday SharePoint online use, you should go with SharePointOnlineCredentials.
SharePointOnlineCredentials
With release of SharePoint 2013, and the big push towards SharePoint online, Microsoft obviously needed a more frictionless way to have people use CSOM with SharePoint Online than before. Due to that they added SharePointOnlineCredentials to the client side framework, so people easily could provider username and password of a user account and use that users permissions when accessing SharePoint via. CSOM.
The simplest example would be something like this.
[csharp]
using Microsoft.SharePoint.Client;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
using (var context = new ClientContext("https://tenant.sharepoint.com/"))
{
var ss = new System.Security.SecureString();
Array.ForEach("Pass@w0rd".ToCharArray(),(c) => { ss.AppendChar(c); });
context.Credentials = new SharePointOnlineCredentials("[email protected]", ss);
var web = context.Web;
context.Load(web);
context.ExecuteQuery();
var title = web.Title;
Console.WriteLine(title);
}
}
}
}
[/csharp]
Acccess Token (ADAL/Office 365 API)
In 2014 we have seen Microsoft invest a lot in what they called the Office 365 API tools. These tools use the REST (_api) endpoint of SharePoint Online and gets authenticated by the access token in a header. The access token is coming from an Azure Active Directory Application that is registered to allow delegation of access to SharePoint. The level of access to SharePoint is always equal to the access level of the user executing the call.
Right now the functionality of the Office 365 API client libraries are rather limited (Microsoft.Office365.SharePoint) so if you want to do anything other than the most simple things you have to build the REST request yourself. That can be annoying and also as mentioned not everything can be accomplished by the REST endpoint. So if you want you are actually also able to use the acquired access token to authenticate with the CSOM, in that way the full client side functionality is available to use.
If you are interested in the Access Token approach, I encourage you to read Steve Peschka’s blog post on the topic.
One final note, when working with SharePoint apps, you are also using the Access Token approach. Hope this article helps clear up a few things.