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
Both these versions require the add-in to be registered on Azure Active Directory.
Both these versions require an additional manifest entry.
Both these versions use MSAL v1.0 - @msal
Both these versions use OAuth 2.0 Implicit Grant Flow.

</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.
You should still use MSAL for a fallback auth mechanism (assuming you utilize the Microsoft Identity platform) in case SSO isn't available or has an error, but SSO lets you get the token without opening dialogs, etc.
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.

Identity API 1.3

First Released in August 2020.
The first preview version was released in November 2019.
This implementation uses Promises.
This is supported for Word, Excel, Outlook, and PowerPoint.

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

This implementation is the one used by the Yeoman Generator when you select "Office Add-in Task Pane project supporting single sign-on".

You should call getAccessToken from inside Office.initialize. You should also pass allowSignInPrompt: true in the options parameter of getAccessToken. For example; OfficeRuntime.auth.getAccessToken( { allowSignInPrompt: true }); This will ensure that if the user is not yet signed in, that Office prompts the user through the UI to sign in now.
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.
As a best security practice, 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.

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 - docs.microsoft.com/en-us/office/dev/add-ins/develop/sso-in-office-add-ins
link - docs.microsoft.com/en-us/office/dev/add-ins/develop/auth-with-office-dialog-api
link - docs.microsoft.com/en-us/office/dev/store/add-in-submission-guide
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