In this post, Senior Application Development Manager, Anant Dimri explains authentication options available to application developers who wish to interact with data in O365.

A developer writing applications that interact with SharePoint (SP) data (Lists/Events/Documents, etc.) will be faced with several options to setup authentication.  While there are numerous blog and support articles that cover authentication and API methods, they are spread out over multiple product areas and no one solution is right for every scenario.   This article attempts to consolidate and list out the options to help a developer/architect choose what works best for them.

O365 Architecture concepts

Before we begin to look at the possible options. A quick refresher on how O365 and Azure is structured. An identity in O365 can be created in one of the three possible ways:

1. Cloud Identity : Manage your user accounts in Office 365 only. No on-premises servers are required to manage users; it’s all done in the cloud

2. Synchronized Identity : Synchronize on-premises directory objects with Office 365 and manage your users on-premises. You can also synchronize passwords so that the users have the same password on-premises and in the cloud, but they will have to sign in again to use Office 365.

3. Federated Identity : Synchronize on-premises directory objects with Office 365 and manage your users on-premises. The users have the same password on-premises and in the cloud, and they do not have to sign in again to use Office 365. This is often referred to as single sign-on.

See this for more detailed setup and reference: https://support.office.com/en-us/article/Understanding-Office-365-identity-and-Azure-Active-Directory-06a189e7-5ec6-4af2-94bf-a22ea225a7a9

O365 Application options

Now lets look at way different style of applications can access the data from O365.

• .NET/PowerShell  application (Console/Windows/Service) : .NET applications that are not registered with SP and use REST and other API to interact with SP
• Non .NET applications on non windows machines: These could be jscripts/java/Scripting and other coding techniques.

O365 Authentication options

• O365 Integrated Applications : SP hosted/Provider hosted applications are native to SP and have access to SP APIs to access data directly using SPContext and no additional authentication is needed most times.

• .NET/PowerShell applications: These are the applications that are not registered with O365 but leverage direct API to access. They have 2 ways to access O365 data:

• • With Username/Password :
    • SharepointOnlineCredentials Class: This is the easiest way for .NET capable applications to load the Microsoft.Sharepoint.Client.dll and pass in the User credentials and all authentication is managed by the API for you.

context.Credentials = new SharePointOnlineCredentials(userName,password);
context.Load(context.Web, w => w.Title);
context.ExecuteQuery();

Dependency: SharePointOnlineCredentials is a wrapper class that is available in Microsoft.SharePoint.Client.Runtime.dll. There is no relevant one for other languages like Java, Python etc.

• • With an Application Identity :
    • Sharepoint Application Identity You may want the application to access data on O365 as an application and not a user. This would mean the application needs to be registered as an application and the application identity has to be given permission access. To complicate this further, there are 2 different ways to create application identity.Sharepoint Addin – ACS application: This is when an application is registered in the O365 – Sharepoint application. This provides the application a SP ID and ACS acts as a middle man negotiating the authentication and token on application’s behalf.Here are the step by step to setup an application in Sharepoint app in O365 https://msdn.microsoft.com/en-us/library/office/jj687469(v=office.15).aspx?tduid=(8a2485fa516454dcf30b06bb9cf43361)(256380)(2459594)(TnL5HPStwNw-IESeJoD3O1aleALEKp497Q)()

      Navigate to http://<SharePointWebsite>/_layouts/15/AppRegNew.aspx on the tenancy or farm. AppRegNew page form

      Here is a sample on how to use the Sharepoint Addin technique to be called from client application. The demonstrated way is using Powershell but this can be used by any client using Java/Python/jscript etc: https://blog.vgrem.com/2015/01/27/consuming-the-sharepoint-online-rest-api-from-powershell-part-2/

      Caveat: Since ACS manages the authentication, any AzureAD specific rules or processes maybe bypassed. For e.g. if your organization has restricted IP policy for O365 access in AzureAD that maybe be bypassed by this kind of application as it leverages ACS as a mediator.

• • O365/Azure AD Application Identity:
    • This is when an application is registered as an O365 application with AzureAD and leverages AzureAD for authentication. These apps then leverage O365 APIs to access Sharepoint data. This provides an advantage of integrating with O365 and can access data across multiple services. However the tradeoff is O365 APIs do not have the depth of the SP APIs and can be limited in the actions that can be performed. Also the security permissions are then set at the AzureAD level for this application. The permission levels are for the tenancy, so a read permissions will provide read level access to the Application. Granular level permissions can be enforced by making the application as either App only or App+User authentication. See below for details:Setting up permissions on AzureAD: https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-integrating-applications On your web client application’s configuration page in the Azure portal, set the permissions your application requires by using the menus in the Required Permissions section. This provides 2 further control options: 1.  App Only: This provides access to the O365 App(AzureAD app) access to O365-Sharepoint data based on the application credentials only. The user and/or Admin may still need to consent based on the permissions settings specified in AzureAD Permissions for the app. This kind of applications access is great for applications that need to access data across users/web/farm. However in my opinion this access needs to be governed strictly by the SP admins to ensure that only approved and certified apps are registered this way to ensure accidental business and data integrity leaks. 2.  App + User: This option provides an application access to data only with a combination of a user credential in combination with application identity.These are best explained with code samples here: https://developer.microsoft.com/en-us/graph/docs/authorization/auth_overview

      Here is also a great blog on O365 API access options: http://chakkaradeep.com/index.php/office-365-api-client-libraries-authenticating-your-client-to-office-365/

A few other points for consideration

App + User ACS(Sharepoint App/addin):

• Designed for web-based apps and not native clients (Console, Win Forms, Services, etc.)
• Supports refresh_token and authorization_code grant types
• The user browser session needs to authenticated with SharePoint, if it’s not, then the web app has to redirect to the SharePoint OAuth endpoint for user authentication (username/password)
• This model is demonstrated by a provider-hosted SPO app created in Visual Studio

App + User AAD(O365/AzureAD app):

• Designed for native clients and typically not web-based clients. With web-based clients, it’s possible to use this on the back-end for elevated-type behavior.
• The user’s security context is used to access resources (webs, lists, items, etc.), so the authorization is not limited to what the app is configured with as in app-only.

Hope this helps making your design choices in accessing SharePoint data in O365 easier .

Premier Support for Developers provides strategic technology guidance, critical support coverage, and a range of essential services to help teams optimize development lifecycles and improve software quality.  Contact your Application Development Manager (ADM) or email us to learn more about what we can do for you.