Fix double log in issue in Dev environment for ssc-assistant

[harshakakumanu]

Description

Currently the way we are setup is we have an Azure App with an IdP setup to use Microsoft AD, we have authorization rules on there for a specific group of users (All SSC Employees).

On the frontend, where the app reg idp redirect uri leads, we have MSAL libraries where we load the authenticated user (seems to cause another login and request for scope).

We need to look at the code and see if we can modify it to either control all of the access from the IdP or both at the same time or just the frontend application.

On top of that we need to look at the API to possibily create a proper flow from frontend to API requests, following this we need to see if we can apply this concept to make the archibus api calls.

Definition of Done

• [x] Look at the current state of authentication, if the code could be fixed to work better and avoid the "double authentication flow"
• [x] Look at the Frontend -> API request to see if we need to create a scope for the API and have it requested by the user.
• [ ] Same as above for API --> Other APIs (such as archibus) on behalf of the user.

[GuillaumeTurcotte]

https://www.pingidentity.com/en/resources/blog/post/securely-using-oidc-authorization-code-flow-public-client-single-page-apps.html#:~:text=So%2C%20a%20SPA%20with%20the%20OIDC%20Authorization%20Code,%28or%20Implicit%20Flow%29%20would%20be%20the%20best%20approach.

Do not share the ID Token or Refresh Token with other components of your architecture or third parties. If the SPA is acting as an OAuth2 client (OIDC Relying Party), it shouldn’t pass these tokens to a server-side component for any reason. If your architecture implies this should be done, the server-side component can act as the OAuth2 client and can be a Confidential Client that keeps a client secret protected. Then, the SPA should use a cookie to track the security session with the web server. Sharing the refresh token with any other component of the system compromises the security relationship between the OAuth2 Client (SPA) and the IdP. Sharing an id_token doesn't compromise the security between the IdP and client; it compromises the security of other components that are relying on it (since it was an assertion intended only for that client). You don’t want either of these scenarios to occur.

[GuillaumeTurcotte]

https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/samples/msal-react-samples/react-router-sample/src

[GuillaumeTurcotte]

I pushed my changes on dev to test the new cleaned up code and it seems conclusive so far, it seems to prompt users only once for login, it seems to be able to re-use the client auth via silent sso now and avoid a second login redirect. I think the faulty code, aside from all the extra code overhead that was there was simply the callback function for the msalinstance not properly trapping silent login and only trapping for redirect thus always trying to fallback to a login redirect at least once.