1. SharePoint Online Authentication Patterns
Authentication options for connecting to SharePoint Online
Purvin Desai
Architect
5th April 2017

2. Objective
Talk about options available for authenticating with SharePoint Online for applications.
Footer
Date Month 2016

3. Authentication Models
SharePoint Add-In Models:
Add-In Only
User + Add-In
O365 API Models (or Azure AD Authentication):
Application Model (Certificate)
Delegate Model
Cloud Service Account (Legacy):
Username and Password
Footer
Date Month 2016

4. Add-In Only User + Add-In Only
SharePoint Add-In Models 1
Add-In Only User + Add-In Only
Footer
Date Month 2016

5. SharePoint Add-in Model
Implements what is called the “Low Trust” Model.
A provider-hosted SharePoint Add-in registers with the Microsoft Azure Access Control Service (ACS), which then issues an access token to the add-in allowing it to access resources on the SharePoint tenant on which it’s installed.
Azure ACS is the trusted token issuer in an OAuth 2.0 Framework "flow" that includes SharePoint and the remote components of the add-in.
Note: There is a “High Trust” model, however this is generally applicable to on-prem deployments.
Footer
Date Month 2016

6. SharePoint Add-In Model
Client Secret and Client ID
Client ID is used to identify your application.
Client Secret is a string used to verify your applications identity.
You need to ensure these are stored safely, and securely at all times. Treat them like a username and password.
If this information is exposed, then you need to take steps to change them.
Never store in plain text, and never hard code in your application.
Footer
Date Month 2016

7. SharePoint Add-In Model
Scope and Rights that can be requested by Applications:
Add-In can perform any operation that it has requested, to support doing:
Scope: eg. Tenant, Site Collection, Site, List.
Rights: eg. Read, Write, Full Control, Manage.
Footer
Date Month 2016

8. SharePoint Add-In Model: Add-In Only
Highlights:
Operates as an Application only
Does not require any interactive action by a user to authenticate.
Trust is established via the application manifest, which is registered either via a .app package, or the AppInv.aspx page, done by a user with appropriate permissions.
Add-In can perform any operation that it has requested.
When performing actions as an Application Only token retrieved by:
string addinOnlyAccessToken = TokenHelper.GetAppOnlyAccessToken(contextToken.TargetPrincipalName, sharepointUrl.Authority, contextToken.Realm).AccessToken;
Footer
Date Month 2016

9. SharePoint Add-in Model: Add-In Only
Examples of appropriate applications:
Any external applications that need to be able to connect to SharePoint content with a specific permission level. Includes console applications, web applications or windows services.
Solution which pulls the contents of a list on a nightly basis in order to drive a KPI Dashboard, or that performs nightly maintenance on a document library and which shouldn’t be associated to a user.
Examples of inappropriate applications:
Applications that need to perform operations as though they were the currently logged on user.
Footer
Date Month 2016

10. SharePoint Add-in Model: User + Add-In
Highlights:
This is the default model, and requires use of the App Catalog, a .app package, and appears as an “Apps from your organization”
Can operate either as a User + Application or Application Only, so it’s a superset of the Add-In Only model
Trust is established at the point in time the Application is added to the site, the user performing the trust of the Application must have at least the permissions requested by the Application in the manifest.
When performing actions as the User + Application token retrieved by:
string accessToken = TokenHelper.GetAccessToken(contextToken, sharepointUrl.Authority).AccessToken;
When performing actions as an Application Only token retrieved by:
string addinOnlyAccessToken = TokenHelper.GetAppOnlyAccessToken(contextToken.TargetPrincipalName, sharepointUrl.Authority, contextToken.Realm).AccessToken;
Footer
Date Month 2016

11. SharePoint Add-in Model: User + Add-In
Examples of appropriate applications:
Any applications that are suited to the “Add-In Only” approach and that additionally need to perform operations as a user.
Examples of inappropriate applications:
Applications that don’t need to perform operations under the context of a user.
Any applications identified as inappropriate in the “Add-In Only” approach section.
Footer
Date Month 2016

12. Application Model (Certificate) Delegate Model
O365 API Models (Azure AD Authentication) 2
Application Model (Certificate) Delegate Model
Footer
Date Month 2016

13. Office 365 API
The Office 365 API services use Azure Active Directory (Azure AD) to provide secure authentication and authorization to users' Office 365 data. Azure AD implements authorization flows according to the OAuth 2.0 protocol.
Therefore, enabling your app to authenticate in order to access Office 365 data consists of two basic steps:
Register your app with Azure AD
Implement code in your app that handles the appropriate authentication flow
Footer
Date Month 2016

14. Office 365 API: Application Permissions
Highlights:
Operates as an Application Only.
Does not require any interactive action by a user.
Requires tenant administrator consent.
Not supported for use by native client applications.
Once authorised, communication to API is achieved via the use of a certificate.
Note: Application Permissions are granted at the Tenant scope *only*. This means if ”Read” access is requested, the application will be able to read all content, in all site collections in the Tenant.
Footer
Date Month 2016

15. Office 365 API: Delegated Permissions
Highlights:
Operates under the context of a user.
Requires a user to log on interactively in order to perform actions on their behalf.
Requires only user consent, and once given, has access to the permissions requested by the application
Once authorised, communication to API is achieved via the use of a token.
Azure AD Delegated Permissions is recommended if you are building an application that needs to talk to the O365 Graph API, One Note API, and SharePoint sites.
Footer
Date Month 2016

16. Cloud Service Account 3
Footer
Date Month 2016

17. Cloud Service Account Highlights:
Direct equivalent of Service Accounts.
They can be used for third-party applications that cannot authenticate with SharePoint Online by any of the previous methods described in this document.
Password resets every 90 days.
MFA will not work in this scenario.
Standard best practices for storing usernames and passwords apply.
Footer
Date Month 2016

18. Notes 4
Footer
Date Month 2016

19. Applications that use User Context
There is significant overlap between the SharePoint Add-in User + Add-in model and the O365 API Delegated model. Things to consider:
Use of O365 API’s require O365 API Delegated. (eg. Graph, Contacts, etc.)
O365 API gives access to ALL a users resources eg. All Site Collections, SharePoint Add-In model only the scope described in the manifest. Eg. Site Collection, Web, List.
Device based solutions recommended to use O365 API.
Footer
Date Month 2016

20. Other notes ”Single Sign-On” is no longer available:
System.Net.CredentialCache.DefaultCredentials
System.Net.CredentialCache.DefaultNetworkCredentials
WebLogin Method
Client ID re-registration process
Footer
Date Month 2016

21. Questions and Answers
Footer
Date Month 2016