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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cloud Service Account 3 Footer Date Month 2016

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

Notes 4 Footer Date Month 2016

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

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

Questions and Answers Footer Date Month 2016