Support query response mode for login redirect flow

[japem]

Core Library

MSAL.js v2 (@azure/msal-browser)

Wrapper Library

MSAL React (@azure/msal-react)

Public or Confidential Client?

Public

Description

This is a rehash of #2228, but that issue is locked and I can't comment.

I have a specific use case for wanting this feature - I have a single public client used for many different hosts, and rather than configuring each one to be an allowed redirect URL for my client I would like to be able to set up a single host as a proxy and have that itself perform a redirect to the site that initiated the flow. This is not possible with the response mode set to fragment, since it is stripped from the request before being sent to the server.

Source

External (Customer)

[hectormmg]

@japem thanks for the request. There are currently no plans to support other response modes as the documentation update referenced in the issue states. I'll still bring your use case to the team and I'll update this issue with the results of the discussion. Thanks again!

[peterzenz]

@EmLauber might be worth understanding the use case here.

[jasonnutter]

and rather than configuring each one to be an allowed redirect URL for my client I would like to be able to set up a single host as a proxy and have that itself perform a redirect to the site that initiated the flow

Would the auth requests start on one domain and end on another?

[japem]

and rather than configuring each one to be an allowed redirect URL for my client I would like to be able to set up a single host as a proxy and have that itself perform a redirect to the site that initiated the flow

Would the auth requests start on one domain and end on another?

Yes, as far as AD FS is concerned it is receiving a request from one domain and then redirecting to another. However ultimately the flow would end on the domain that started it after being proxied through the server hosted at the redirect URL.

[jasonnutter]

@japem Okay, thanks. I don't think that is something our library can support, as the SDK needs to be able to validate the request, which is does by storing temporary pieces of state in browser storage (session storage, usually) on the origin which initiated the request (and due to the same-origin policy, those pieces of state will not be accessible on another origin).

[japem]

I don't think that is something our library can support, as the SDK needs to be able to validate the request

I’m not looking to use MSAL on this other host, though, so I don’t need it to validate anything for me. I’m looking to implement the remainder of the authorization code flow myself.

[japem]

Or, alternatively I could have my server redirect to the same host as I initiated the flow from with a 3xx status code. In this case I would use MSAL to perform the rest of the authorization code flow, but from the same origin it initiated from, and I believe all session storage should be available depending on the cache type I use. (This seems like it should just work but I’m not sure.)

[ghost]

This issue requires attention from the MSAL.js team and has not seen activity in 5 days. @EmLauber please follow up.

[peterzenz]

This isn't a scenario we'd support in our library where we'd only handle part of the auth code flow with you implementing the other part. The code we have is here and you're welcome to use it, but it's not a scenario we'd build or support.