Microsoft-authentication-library-for-js: Some values are now resulting in InvaildState during login

Created on 4 Aug 2020 · 9Comments · Source: AzureAD/microsoft-authentication-library-for-js

Please follow the issue template below. Failure to do so will result in a delay in answering your question.

Library

[x] [email protected] or @azure/[email protected]
[ ] @azure/[email protected]
[ ] @azure/[email protected]
[ ] @azure/[email protected]
[ ] @azure/[email protected]

Important: Please fill in your exact version number above, e.g. [email protected].

Framework

AngularJS 1.x and React, but those are not at play in this scenario

Description

Updated from 1.2.2 to 1.3.2 yesterday and noticed this immediately in development.

I've found that certain values for the state property are now causing loginRedirect to fail with an Invalid State

I've found that the state validation is also now failing when using it to roundtrip the final url to re-direct the user to when there are certain characters in the query string.

state: "http://localhost:9000/home" works as expected.

However: state: "http://localhost:9000/sessions?t=%257B%2522from%2522%253A%25222020-07-19T08%253A30%253A00-07%253A00%2522%252C%2522to%2522%253A%25222020-07-23T18%253A00%253A00-07%253A00%2522%257D&g=%255B%2522available-rsvp-only%2522%255D" results in:

Error Message

ClientAuthError: Invalid state. eyJpZCI6Ijc5ODdlMTJmLTk2M2YtNDBkMC1hM2QxLTRiOGVjZTNlMmM1NyIsInRzIjoxNTk2MjE4NDA2LCJtZXRob2QiOiJyZWRpcmVjdEludGVyYWN0aW9uIn0=|http://localhost:9000/sessions?t=%7B%22from%22%3A%222020-07-19T08%3A30%3A00-07%3A00%22%2C%22to%22%3A%222020-07-23T18%3A00%3A00-07%3A00%22%7D&g=%5B%22available-rsvp-only%22%5D, state expected : null
at ClientAuthError.AuthError [as constructor] (webpack-internal:///./node_modules/msal/lib-es6/error/AuthError.js:30:24)
at new ClientAuthError (webpack-internal:///./node_modules/msal/lib-es6/error/ClientAuthError.js:114:24)
at Function.ClientAuthError.createInvalidStateError (webpack-internal:///./node_modules/msal/lib-es6/error/ClientAuthError.js:159:12)
at UserAgentApplication.saveTokenFromHash (webpack-internal:///./node_modules/msal/lib-es6/UserAgentApplication.js:1787:93)
at UserAgentApplication.processCallBack (webpack-internal:///./node_modules/msal/lib-es6/UserAgentApplication.js:1172:23)
at UserAgentApplication.handleRedirectAuthenticationResponse (webpack-internal:///./node_modules/msal/lib-es6/UserAgentApplication.js:1269:10)
at new UserAgentApplication (webpack-internal:///./node_modules/msal/lib-es6/UserAgentApplication.js:141:14)
at eval (webpack-internal:///./app/scripts/msal/msal-auth-service.ts:21:15)
at Module../app/scripts/msal/msal-auth-service.ts (http://localhost:9000/app.bundle.ada3.js?ada3971f6bf3f34ab426:5717:1)
at __webpack_require__ (http://localhost:9000/app.bundle.ada3.js?ada3971f6bf3f34ab426:774:30)

Security

[ ] Is this issue security related?
Not to my knowledge

Regression

[ ] Did this behavior work before?
Version: 1.2.2

MSAL Configuration

export const msalConfig: Configuration = {
    auth: {
        clientId: Resources.ApplicationId,
        authority: `https://${Resources.AadTenantName}.b2clogin.com/${Resources.AadTenantName}.onmicrosoft.com/${Resources.Aadb2cPolicy}`,
        redirectUri: `${window.location.origin}${Resources.LoginPage}`,
        postLogoutRedirectUri: window.location.origin,
        validateAuthority: false,
        navigateToLoginRequestUrl: false
    },
    cache: {
        cacheLocation: 'localStorage', 
        storeAuthStateInCookie: false
    }
};

export const loginRequest: AuthenticationParameters = {
    scopes: [Resources.ApplicationId],
    extraQueryParameters: {
        appId: Resources.ApplicationId
    }
};

Reproduction steps

export const signIn = (state?: string): void => {
    const request = { state, ...loginRequest };
    if (!msalApp.getLoginInProgress()) msalApp.loginRedirect(request);
};

Expected behavior

Browsers/Environment

[ ] Chrome
[ ] Firefox
[X] Edge 86.0.587.0 (Official build) dev (64-bit)
[ ] Safari
[ ] IE
[ ] Other (Please add browser name here)

bug [email protected]

Source

gavinbarron

All 9 comments

Hi @gavinbarron , thanks for raising this issue. We'll investigate and follow-up when we have more information.

I've found that the state validation is also now failing when using it to roundtrip the final url to re-direct the user to when there are certain characters in the query string.

Setting navigateToLoginRequestUrl to true is a way to redirect the user back to the page they were on when they performed the redirect. Have you considered enabling that option instead of providing the URL in the state parameter?

hectormmg on 4 Aug 2020

@technical-boy using navigateToLoginRequestUrl: true is not a viable option in our use case.

We're using the id_token to establish identity and have custom authorization logic that we need to run before granting access to our site navigateToLoginRequestUrl: true would prevent us from running our custom logic.

Edit: we have a work-around at present using localStorage to hold the state value instead of using state roundtripped on the request Urls.

gavinbarron on 5 Aug 2020

Hi @gavinbarron . Is the state value your are passing into the request URI encoded by your application? MSAL will perform URI encoding for all query parameters, including state, so it's not necessary to URI encode them before passing them into the configuration object.

Can you try passing in an un-encoded state value and let us know if that works? Thanks!

hectormmg on 5 Aug 2020

We're just reading the exact value of window.location.href, it has encoded values because, well, they were encoded by the browser.

gavinbarron on 5 Aug 2020

This issue has not seen activity in 14 days. It may be closed if it remains stale.