Single Sign On

This allows your uses to have authorized access to Microsoft 365 OneDrive and Microsoft Graph.
Also known as the Identity API or the SSO API.

Manifest Entry

This requires an additional element being added to the manifest file.

</Resources> 
<WebApplicationInfo> 
  <Id>{application GUID} 
  <Resource>api://localhost:8080/{application GUID}</Resource> 
  <Scopes> 

Id - The application (client) ID from your Microsoft identity platform registration.
Resource - The URI of the add-in. This is the same URI that you used when registering the add-in with the Microsoft identity platform and it must end with the application (client) ID.
Scopes - Specifies the permissions needed. The profile and openID permissions are always needed. If your add-in needs access to Microsoft Graph you will need additional elements. For example User.Read and/or Mail.Read.
With SSO you can also enable admin consent via centrally deployed add-ins, for example. In general I would suggest use SSO over MSAL only, there are additional advantages like caching/perf, etc.

getAccessToken

OfficeRuntime.auth.getAccessToken 
Office.context.auth.getAccessToken 
isSetSupported('IdentityAPI', '1.3') 

If the add-in has some functionality that doesn't require a signed in user, then you can call getAccessToken when the user takes an action that requires a signed in user.
There is no significant performance degradation with redundant calls of getAccessToken because Office caches the access token and will reuse it, until it expires, without making another call to the Microsoft identity platform whenever getAccessToken is called.
So you can add calls of getAccessToken to all functions and handlers that initiate an action where the token is needed.
Always call getAccessToken when you need an access token. Office will cache it for you.
Don't cache or store the access token using your own code.

Fallback

When the getAccessToken method works, it lets you get the token without opening any dialogs.
You should implement an alternate authentication system that your add-in can fall back to in certain error situations.
For example, if your add-in is loaded on an older version of Office that does not support SSO, the getAccessToken call will fail.
You should use MSAL for a fallback auth mechanism in case SSO isn't available or has an error.

iFrame

When you are running Office on the web and using a task pane, this task pane uses an iFrame.
A lot of the Identity Authorities (or Secure Token Services STS) do not allow there login page to open in an iFrame.
These include Google, Facebook including Microsoft Identity Platform (msal).
The Office Dialog API, specifically the displayDialogAsync method was created to get around this problem.
The displayDialogAsync method can be launched from a task pane and opens an entirely separate browser instance which allows the login pages to run.

Documentation

link - developer.microsoft.com/en-us/microsoft-365/blogs/announcing-general-availability-of-single-sign-on-sso-for-office-add-ins 
link - developer.okta.com/blog/2019/08/22/okta-authjs-pkce 
link - learn.microsoft.com/en-gb/office/dev/add-ins/outlook/authenticate-a-user-with-an-sso-token 
link - learn.microsoft.com/en-gb/office/dev/add-ins/outlook/implement-sso-in-outlook-add-in 
link - learn.microsoft.com/en-us/office/dev/add-ins/develop/auth-with-office-dialog-api 
link - learn.microsoft.com/en-us/office/dev/add-ins/develop/sso-in-office-add-ins 
link - learn.microsoft.com/en-us/training/paths/m365-office-add-in-associate/