Clarification on how to use msal libraries in order to authentication against own api

[Robstei]

Core Library

No response

Wrapper Library

Not Applicable

Public or Confidential Client?

Confidential

Documentation Location

https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/samples/msal-browser-samples/HybridSample

Description

So I asked about SSR here and got recommended to look at the hybrid spa flow for a full stack app.

I also found this issue where the question is about how do use the msla libraries in a system with frontend and backend where the recommendation was to look at the hybrid spa flow aswell.

However, It is my understanding that the hybrid spa flow as described in the sample does not answer that question. It is my understanding that at the end of the SPA flow in the documented example both frontend and backend have a valid access token and refresh token each. However the access token in the frontend has the audience graph as the scope is "user.read".

I also found this longer issue that touches this topic.

One quoute from there is:

Access tokens should only be handled by the Identity Provider, the application that requested them and the resource they are intended for. Passing them back and forth between frontend and backend is not recommended despite what others have decided to do.

To me that means I am not supposed to send the access token from the hybrid spa flow sample to the backend.

To get a valid token for the backend my assumtion is that I have to expose the web API as described here. As statet here this would be possible with one app regestration but it might make sense to use two.

But is that compatible with the hybrid spa flow. My assumption is that is is not because of this quote in the longer issue from above:

If both the backend and frontend share an appId you can use the "Hybrid SPA flow" to show a single interactive prompt on the backend to acquire your backend tokens then redeem the "spa code" on your frontend to acquire your frontend tokens.

Since the backend already has a valid token for the user with graph claims I suspect that this is not a use case for the obo flow?

What is the recommended way to make a request to the backend that might use the graph API or specific user data from the application database?

[tnorling]

It's not clear to me what you are trying to build. Can you tell me more about your scenario and architecture?

Hybrid SPA flow is a performance/UX optimization for scenarios where you have a web app with a frontend and backend component where both need to be authorized to make API calls on their own. e.g. You want to be able to call an API directly from your SPA app without needing to call down into your backend first.

OBO is for scenarios where you're calling a protected web API which in turn needs to call another protected web API. In other words, your web app is authorizing a web API to call another API on your behalf.

You might also consider the BFF pattern where auth is completely handled by your backend and your frontend only routes calls to your backend.

[Robstei]

Thanks a lot for the fast answer. I really appreciate it.

That looks indeed more like what I need.

It's not clear to me what you are trying to build. Can you tell me more about your scenario and architecture?

I am planing an internal tool that:

1. needs to support microsoft login
2. uses the graph api
3. combines graph data with app specific data in the backend
   (there will probably be no graph api calls directly from the frontend)

Therefore the backend needs to be able to authenticate a user and request graph information.

I think the other issuers ment that aswell and that was one reason for the confusion in those issues.

I struggle to see the use case for the hybrid spa flow as described in the sample compared to just doing authentication in the spa.
Do you have any use case in mind where backend could use the token?
How would the backend know which token to use for a subsequent request? My current understanding is that one would need to add session management in order to authenticate the user on the backend. Once there is session management one could use the session management + msal-node (as described by your recommendation).

In my mind the hybrid spa workflow as it is in the sample would (only) be usefull if the frontend would end up with an access token for the backend. At that point the backend could use the access token of that user for the graph api instead of starting the obo flow.

[tnorling]

Like I said above, the hybrid SPA flow is a performance/UX optimization for scenarios where your frontend and backend need to independently request and use their own tokens, if you don't have a really strong reason why these need to act independently this flow is likely not relevant to you. In apps designed this way, without the hybrid SPA flow each component would need to independently authenticate which would result in users being prompted for credentials twice.

[Robstei]

I do understand that being prompted twice for the credentials would be bad. What I don't get is how the hybrid spa flow sample has any advantages over just using msal-react or msal-browser.

I am concerned that my understanding is wrong because the hybrid spa flow was recommended in the other issues that also needed to make requests against their own api.

I understand that the ConfidentialClientApplication in the backend holds valid access and refresh tokens. However I don't understand the benefits of that. Is this ever ment to be used in a system where frontend and backend interact with each other after the hybrid spa flow?
I also found this but it has also no information about the real world use cases of the spa flow.

I first thought about the option to use the access token without user interaction - like in a cron job - but the tokens are not persisted right? So this would only work if the server did not stop in the meantime.