Explanation
You can persist add-in state and settings with the JavaScript API for Office.
The JavaScript API for Office provides the Settings, RoamingSettings, and CustomProperties objects for saving add-in state across sessions Reference: https://docs.microsoft.com/en-us/office/dev/add-ins/develop/persisting-add-in-state-and-settings

Overview
This is a case study. Case studies are not timed separately. You can use as much exam time as you would like to complete each case. However, there may be additional case studies and sections on this exam. You must manage your time to ensure that you are able to complete all questions included on this exam in the time provided.
To answer the questions included in a case study, you will need to reference information that is provided in the case study. Case studies might contain exhibits and other resources that provide more information about the scenario that is described in the case study. Each question is independent of the other questions in this case study.
At the end of this case study, a review screen will appear. This screen allows you to review your answers and to make changes before you move to the next section of the exam. After you begin a new section, you cannot return to this section.
Topic 2, ADatum Corporation
To start the case study
To display the first question in this case study, click the Next button. Use the buttons in the left pane to explore the content of the case study before you answer the questions. Clicking these buttons displays information such as business requirements, existing environment, and problem statements. If the case study has an All Information tab, note that the information displayed is identical to the information displayed on the subsequent tabs. When you are ready to answer a question, click the Question button to return to the question.
Overview
ADatum Corporation develops a software as a service (SaaS) application named E-invoicing.
Existing Environment
Application Architecture
E-invoicing consists of a single-page application (SPA) and a backend web service that provides invoice management and processing functionality.
E-invoicing stores all the details of each invoicing operation in a backend cloud database. E-invoicing generates invoices in PDF format and provides users with the ability to download the PDF after it is generated. Each invoice has a unique identifier named invoiceid.
The users have a common workflow where they sign in to E-invoicing, and then open E-invoicing in multiple tabs of a web browser so they can use different parts of the application simultaneously.
Security Architecture
ADatum uses the principle of least privilege whenever possible. ADatum always uses the latest libraries and integration endpoints.
Requirements
Business Goals
ADatum wants to integrate E-invoicing, Azure Active Directory (Azure AD), and Microsoft Graph so that their customers can leverage Microsoft Office 365 services directly from within E-invoicing.
Planned Changes
ADatum plans to add the following capabilities to E-invoicing:
Email the generated invoices to customers on behalf of the current signed-in user. Any emails generated by the system will contain the invoiced.
Perform as many operations as possible in the browser without having to leave the E-invoicing application.
Use Azure AD to manage identities, authentication, and authorization.
Display all emails that contain a specific invoiced.
Technical Requirements
ADatum identifies the following technical requirements for the planned E-invoicing capabilities:
Ensure that all operations performed by E-invoicing against Office 365 are initiated by a user. Require that the user authorize E-invoicing to access the Office 365 data the first time the application attempts to access Office 365 data on the user's behalf.
Send scheduled reminders to customers before a payment due date. Create an administration user interface to enable the scheduled reminders.
Implement Microsoft Graph change notifications to detect emails from vendors that arrive in a designated mailbox.
Implement single sign-on (SSO) and minimize login prompts across browser tabs.
Secure access to the backend web service by using Azure AD.
Ensure that all solutions use secure coding practices.
Backend Security Planned Changes
ADatum wants to use custom application roles to map user functionality to permissions granted to users.
E-invoicing will have internal logic that will dynamically identify whether the user should be allowed to call the backend API.
SSO JavaScript Script
You plan to implement SSO with Microsoft Authentication Library (MSAL) by using the following code:

Access Token JavaScript Script
You have the following JavaScript code to obtain an access token.

Change Notification JSON
You have the following JSON message that will be sent by the Microsoft Graph service to detect the vendor emails.

Scenario: ADatum identifies the following technical requirements for the planned E-invoicing capabilities:
Ensure that all operations performed by E-invoicing against Office 365 are initiated by a user. Require that the user authorize E-invoicing to access the Office 365 data the first time the application attempts to access Office 365 data on the user's behalf.
Existing Environment
Application Architecture
E-invoicing consists of a single-page application (SPA) and a backend web service that provides invoice management and processing functionality.
E-invoicing stores all the details of each invoicing operation in a backend cloud database. E-invoicing generates invoices in PDF format and provides users with the ability to download the PDF after it is generated. Each invoice has a unique identifier named invoiceid.
The users have a common workflow where they sign in to E-invoicing, and then open E-invoicing in multiple tabs of a web browser so they can use different parts of the application simultaneously.
Security Architecture
ADatum uses the principle of least privilege whenever possible. ADatum always uses the latest libraries and integration endpoints.
Requirements
Business Goals
ADatum wants to integrate E-invoicing, Azure Active Directory (Azure AD), and Microsoft Graph so that their customers can leverage Microsoft Office 365 services directly from within E-invoicing.
Planned Changes
ADatum plans to add the following capabilities to E-invoicing:
Email the generated invoices to customers on behalf of the current signed-in user. Any emails generated by the system will contain the invoiced.
Perform as many operations as possible in the browser without having to leave the E-invoicing application.
Use Azure AD to manage identities, authentication, and authorization.
Display all emails that contain a specific invoiced.
Technical Requirements
ADatum identifies the following technical requirements for the planned E-invoicing capabilities:
Ensure that all operations performed by E-invoicing against Office 365 are initiated by a user. Require that the user authorize E-invoicing to access the Office 365 data the first time the application attempts to access Office 365 data on the user's behalf.
Send scheduled reminders to customers before a payment due date. Create an administration user interface to enable the scheduled reminders.
Implement Microsoft Graph change notifications to detect emails from vendors that arrive in a designated mailbox.
Implement single sign-on (SSO) and minimize login prompts across browser tabs.
Secure access to the backend web service by using Azure AD.
Ensure that all solutions use secure coding practices.
Backend Security Planned Changes
ADatum wants to use custom application roles to map user functionality to permissions granted to users.
E-invoicing will have internal logic that will dynamically identify whether the user should be allowed to call the backend API.
SSO JavaScript Script
You plan to implement SSO with Microsoft Authentication Library (MSAL) by using the following code:

Access Token JavaScript Script
You have the following JavaScript code to obtain an access token.

Change Notification JSON
You have the following JSON message that will be sent by the Microsoft Graph service to detect the vendor emails.

C: The required client_id is the Application (client) ID that the Azure portal - App registrations experience assigned to your app.
E: The authorization code flow begins with the client directing the user to the /authorize endpoint.

Reference: https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow

Explanation
Graphical user interface, text, application, email Description automatically generated

Reference:
https://docs.microsoft.com/en-us/java/api/com.microsoft.identity.client.publicclientapplication.acquiretokensilen
https://docs.microsoft.com/en-us/azure/active-directory/develop/msal-error-handling-js