Authentication Patterns 3

SPSAhmedabad 2018
A Community Event to Learn About Azure, Office 365 & SharePoint
Brought to you by:
@spsahmedabad #SPSAhmedabad
Company name appears here Footer Date Month 2016 1
Modes of Authentication and Authorisation with
SharePoint Online
Authentication and Authorisation options for connecting to SharePoint Online
Purvin Desai
Architect
Footer Date
5th April
Month2017
2016 2
Authentication and Authorisation 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
Company name appears here Footer Footer Date Month 2016 3
Terminology
1
Types of SharePoint Online applications
SharePoint Add-ins
SharePoint Framework
SharePoint-Hosted Provider-Hosted
•Centered around SharePoint •Centered around a

components including lists, •Can be used in
remote web application alternative scenarios
pages, WebParts, or data source.
workflows, libraries, are where only client-side
•Business logic mainly scripting is required.
more.
remote server-side •Runs in context of the
•Business logic is JavaScript code.
on custom SharePoint pages page with full power of
•Can include SharePoint the user viewing the part
•No server-side code components •Full trust client-side
solutions
• Add-ins are limited to the permissions that the add-in
was granted at install time.
• App parts, instead of running in the context of the page,
they run in their own domain within an iFrame.
Types of SharePoint applications
JavaScript Embedded Applications Connected Applications
Embed or Inject Script-Editor SharePoint Add-ins Office 365 API
•Arbitrary JavaScript •Script editor web •Using SharePoint •Azure Active

inserted to sites and parts ACS method Directory
pages, by using •Arbitrary HTML, Applications
Custom Actions, JavaScript, or CSS
mater pages, or customizations
page layouts
• Allows the script code to run in the full • Server-side applications

context of the users • Background applications like windows
• These solutions built by using JavaScript service applications or Azure WebJobs
embeddings could potentially break • Mobile applications
whenever SharePoint Online is updated
SharePoint Add-In Models
2
Add-In Only
User + Add-In Only
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.
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.
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.
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;
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.
SharePoint Add-in Model: Add-In Only
 /_layouts/appregnew.aspx  /_layouts/appinv.aspx
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;
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.
O365 API Models (Azure AD
3
Authentication)
Application Model (Certificate)
Delegate Model
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
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.
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.
Office 365 API
Cloud Service Account
4
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.
Notes
5
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.
Decision Chart
Questions and Answers
References
Add-in authorization policy types in SharePoint

Permissions and consent in the Azure Active Directory v1.0 endpoint
THANK YOU !
Please give us your feedback 
Rate each session with

SPS Events Portal from
https://bit.ly/2DvoGMS

Authentication Patterns 3

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Authentication Patterns 3

Загружено:

Авторское право:

Доступные форматы

SPSAhmedabad 2018

A Community Event to Learn About Azure, Office 365 & SharePoint

Brought to you by:

Authentication and Authorisation options for connecting to SharePoint Online

SharePoint Add-In Models:

O365 API Models (or Azure AD Authentication):

Cloud Service Account (Legacy):

•Centered around SharePoint •Centered around a

JavaScript Embedded Applications Connected Applications

Embed or Inject Script-Editor SharePoint Add-ins Office 365 API

•Arbitrary JavaScript •Script editor web •Using SharePoint •Azure Active

• Allows the script code to run in the full • Server-side applications

User + Add-In Only

• Implements what is called the “Low Trust” Model.

A provider-hosted SharePoint Add-in registers with the Microsoft

Note: There is a “High Trust” model, however this is generally

Client Secret and Client ID

Scope and Rights that can be requested by Applications:

Examples of appropriate applications:

Examples of inappropriate applications:

Examples of appropriate applications:

Examples of inappropriate applications:

Add-in authorization policy types in SharePoint

Please give us your feedback 

Rate each session with

Вам также может понравиться