Amplify-js: Invalid state in OAuth flow

[demsey2]

When I log in through the hosted UI, I am redirected to my domain with a code. All was working fine with version 1.1.23, when I upgraded to 1.1.25 I got an exception "Invalid state in OAuth flow"

The exception is thrown from

OAuth.prototype._validateState = function (urlParams) {
        if (!urlParams) {
            return;
        }
        var savedState = oAuthStorage.getState();
        var returnedState = urlParams.state;
        if (savedState !== returnedState) {
           throw new Error('Invalid state in OAuth flow');
        }
    };

When I check savedState and returnedState, savedState is null and returnedState is undefined

• Device: MacBook Pro
• OS: 10.13.6
• Browser Chrome
• Version 73

[DEBUG] 36:20.15 AuthClass - getting current authenticted user
ConsoleLogger.js:78 [DEBUG] 36:20.77 AuthClass - cannot load federated user from auth storage
ConsoleLogger.js:78 [DEBUG] 36:20.78 AuthClass - get current authenticated userpool user
ConsoleLogger.js:78 [DEBUG] 36:20.78 AuthClass - Failed to get user from user pool
ConsoleLogger.js:88 [DEBUG] 36:20.79 AuthClass - The user is not authenticated by the error

[manueliglesias]

Hi @demsey2

Are you using Auth.federatedSignIn() or manually building a url to cognito hosted ui?

With the recent changes to federation, crafting your own url to cognito hosted ui won't work, since it won't have the expected state and or PKCE params for extra security

[demsey2]

I create my own url

[manueliglesias]

can you try with Auth.federatedSignIn()? let me know if it doesn't cover your use case

[CaryLandholt]

Yes, this was a break for us too.
Signing in via https://<your_domain>/login?response_type=code&client_id=<your_app_client_id>&redirect_uri=<your_callback_url>
results in an Invalid state in OAuth flow exception.

We have users that SSO into our site using the following scheme.
https://<your_domain_prefix>.auth.us-east-1.amazoncognito.com/oauth2/authorize?response_type=code&client_id=<your_app_client_id>&redirect_uri=<your_callback_url>&identity_provider=<your_identity_provider>, which broke with the recent change.

Since our users aren't trigger the federated sign in action on our site, but instead launching from their own portal and SSOing into our site, any recommendations on how to address this?

We also use this approach to SSO into a React Native app.

[tamdilip]

Even we manually build the url to cognito hosted ui, but that approach breaks with the latest version expecting "state" in the callback url along with "code".

New approach to redirect to cognito hosted ui -

Auth.federatedSignIn({ provider: 'your_identity_provider' });

This seems working with the latest version, which internally handles the URL construction automatically and also the other required params for federatedSignIn -"provider, tokens, expires_at ..." are optional now it seems ( #2716 ), so just mentioning the provider alone should directly takes to your IDP sign in page.

[CaryLandholt]

@tamdilip thanks - that does seem to work if signing in is initiated via Auth.federatedSignIn({ provider: 'your_identity_provider' });, but our users initiate outside of our app, from their employer's portal, where they don't have access to the Auth.federateSignIn action.

[Goues]

Hi, we have the same problem with @aws-amplify/auth version 1.2.21. Our setup is basically this:

    .currentAuthenticatedUser()
    .then(doSomething)
    .catch(redirectToHostedUI)

We use Congito's UI where users can login using Google account. After logging in, they are redirected to

https://our.domain/login.php?code={code}

At this point, amplify fails with said error. This happenned after upgrading from 1.2.18.

[Goues]

p.s.: this is a duplicate of #3054

[danludwig]

Hi, I am the author of #3054. Does ‘Auth.federatedSignIn’ allow the passing of a custom ‘state’ argument now or not? We were constructing a manual URL because at the time the code was written, amplify offered no way to pass a value for that querystring parameter.

[manueliglesias]

Hi,

I am working on a fix for this, thanks for the patience.

[manueliglesias]

Hi, can you try?

[email protected]
[email protected]

[ChristineMLew]

I am also encountering this issue and just tried those new versions. Unfortunately the error still occurs exception "Invalid state in OAuth flow

[manueliglesias]

@ChristineMLew please make sure session storage is cleared before you try it (you might have state from a previous run)

Also, can you paste the output of:

yarn list --depth 0 | grep amplify
# or 
npm list --depth 0 | grep amplify

[JiboStore]

Hi, I am using
Auth.federatedSignIn({Provider: "Facebook"}); and get the same error, any idea?

[tamdilip]

Hi, I am using
Auth.federatedSignIn({Provider: "Facebook"}); and get the same error, any idea?

@JiboStore Not sure, just a weird workaround solution without debugging with latest version. Have u tried mentioning "identityProvider" along with the auth config attributes and just call with "Auth.federatedSignIn()" without passing over here as a param.

[sagun786]

Hi I am using the browser to hit the manually created url to test it before using Postman/Insomnia to test whether facebook login has been correctly integrated or not and to generate a token. I am getting the same error of invalid state when I use insomnia but when I use the browser it works fine. What optional parameters can I include like STATE AND PKCE params that will solve this

BROWSER URL
https://mydomain.auth.ap-southeast-1.amazoncognito.com/login?response_type=code&client_id=56n1ij8fich189q4e5inkjb8nc&redirect_uri=https://REDIRECT-URL

INSOMNIA/POSTMAN URL
Grant Type: Authorization Code
Authorization Url: https://mydomain.ap-southeast-1.amazoncognito.com/oauth2/authorize
Token Url: https://mydomain.auth.ap-southeast-1.amazoncognito.com/oauth2/token
Client ID:
Client Secret:
Scope: email
State: STATE

[AlexWang-16]

II'm also getting this issue with my react application while using amplify. I have version 3.0.23.

EDIT:

I discovered the issue was due to my app client being configured with a client secret, which should not have been for the case of a react web application. I resolved this by creating a new app client and specifically unchecking "generate client secret" option and reconfigured my react app's Cognito configurations with the new client_id.