State parameter in login request

[AnnaShk]

Hi,

Could you please help me to find you how can I use the state parameter with msal?
How can I send state value in the request(loginRedirect), so it will be returned in the token response?

Here is my current UserAgentApplication:

clientApplication =
            new Msal.UserAgentApplication(
                clientID,
                authority,
                authCallback,
                {
                    redirectUri: window.location.origin
                }
            );
    }

and login:
clientApplication.loginRedirect(b2cScopes);

I see some state parameter exists in POST SelfAsserted request Referer.

Here is a link to state parameter explanation.

Thanks.

[nehaagrawal]

Hi @AnnaShk, Currently msal library is generating the state parameter in the constructor of AuthenticationRequestParameters.
this.state = Utils.createNewGuid();
Can you please tell me your use case where you want to pass the state parameter yourself instead of using the one generated by the library.

[AnnaShk]

Hi @nehaagrawal,

Thanks for that. Yes, the state parameter is, as you say, passing a new GUID to the Azure login page, but according to this page, there are two potential uses for the state parameter:

"A value included in the request that is returned in the token response. It can be a string of any content that you want to use. Usually, a randomly generated unique value is used, [this is the new GUID currently provided by the MSAL library] to prevent cross-site request forgery attacks. The state also is used to encode information about the user's state in the app before the authentication request occurred. For example, the page the user was on, or the policy that was being executed."

So our understanding is that, critically, the state parameter is preserved through the authentication process. We need to use the state parameter for the second scenario (perhaps in addition to the first), where we want to add our own value to be preserved and appended to the redirect_uri when the user is authenticated.

As a simple example (ignoring the CSRF GUID for a moment), we might send a unique link to a potential new user, identifying them in an existing customer database:

https://mysite.example.com/signup?customer_id=12345

We want the ID to be preserved through the authentication process so we can link the new B2C user to our existing customer record, and our understanding is that we should use the state parameter for this: so we should be able to grab the customer_id parameter in the original URL and stuff it into state:

GET https://login.microsoftonline.com/mysite.onmicrosoft.com/oauth2/v2.0/authorize?client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6&response_type=code&redirect_uri=https%3A%2F%2Fmysite.example.com%2Fwelcome&response_mode=query&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6%20offline_access&state=12345&p=b2c_1_sign_up

Then the user on successful signup and authentication would be redirected to:

https://mysite.example.com/welcome?state=12345

We can then associate the newly created oid with their internal customer_id (note we won't be using the actual customer ID, rather a known unique GUID representing them). Another scenario might be that the user clicks on a link to a specific page, we URL encode that page in the state parameter and redirect the user back to that page after they are authenticated.

Are we thinking about this the wrong way? It seems like this is a fairly fundamental use case for the state parameter, but unless we can either modify the state parameter or use some other parameter that is preserved through the authentication process, we can't achieve what I've outlined above.

Thanks.

[nehaagrawal]

@AnnaShk we have acknowledged this issue as an enhancement.

[AnnaShk]

Hi @nehaagrawal,

Thank you for the update. I've tried to make this change on my side, and added state parameter as part of UserAgentApplication options, so the new client object will look like:

this.clientApplication =
            new Msal.UserAgentApplication(
                clientID,
                authority,
                authCallback,
                {
                    redirectUri: window.location.origin,
                    state: "my-state-value",
                }
            );

Changes:
I've just made a commit to dev branch: "Issue #262: State parameter in login request"

Is this a good/safe solution?
If so, could you please incorporate it into an upcoming release?

Thanks

[nehaagrawal]

@AnnaShk Thanks for Pull Request. We are currently reviewing your change. There are some enhancements that needs to be done. I will add comment in your Pull Request.

[SujitGodavarti]

Hello @nehaagrawal. I made the code changes you mentioned above and added state parameter as part of UserAgentApplication options. The new client object now is

this.clientApplication =
        new Msal.UserAgentApplication(
            clientID,
            authority,
            authCallback,
            {
                redirectUri: window.location.origin,
                state: "my-state-value",
            }
        );

The state parameter which I pass is not preserved through the authentication process. If I don't pass my own state parameter, everything works fine. I need that state parameter to be preserved for the similar reason mentioned by @AnnaShk. Could you please help me with this?

[rendmath]

Is there currently any way to pass additional state when we trigger a loginRedirect ?

If not, what is the recommended approach to handle a return URL ? Since the Open ID redirect URI is fixed, we have to put that information somewhere.

[simonneedham]

I’ve been storing the ‘original uri that initiated the login request’ in session storage. When I get returned from B2C authentication, I’m logged in, everything’s been successful, I finally return to the url that initiated the request that has been saved in session storage.

[rendmath]

This method seems to have a minor drawback though. If the login is initiated from 2 different tabs, the last tab overwrites the redirect URL of the first one.

Also, couldn't it be an attack vector for a malicious script hijacking your redirection URL (e.g. launching an 1px <iframe> pointing to your site from a malicious web page, thereby forcing all your redirections to a URI of their choosing (inside your website) ?

[qbodart]

Hi @AnnaShk , What is the status of your PR? The use case you described also apply to us and it seems to me it should be an expected behaviour.

Thanks!

[nehaagrawal]

@AnnaShk @rendmath @qbodart @simonneedham @SujitGodavarti This is fixed and released in msal-core 0.2.1. I am closing this issue.