Auth refresh token not working

[AlexGianq]

Before opening, please confirm:

• I have searched for duplicate or closed issues and discussions.

Language and Async Model

Kotlin

Amplify Categories

Authentication

Gradle script dependencies

// Put output below this line
    def amplifyVersion = '2.29.1'
    implementation "com.amplifyframework:aws-auth-cognito:$amplifyVersion"
    implementation "com.amplifyframework:rxbindings:$amplifyVersion"

Environment information

# Put output below this line
(not relevant)

Please include any relevant guides or documentation you're referencing

No response

Describe the bug

When proceeding to RxAmplify.Auth.fetchAuthSession(), the session that is obtained after a refreshToken always fails, with a specific error:

SessionExpiredException{message=Your session has expired., cause=NotAuthorizedException(message=SecretHash does not match for the client: <redacted>), recoverySuggestion=Please sign in and reattempt the operation.}

I put a debug breakpoint at FetchAuthSessionCognitoActions.refreshUserPoolTokensAction, and it appears that the hashed username is signedInData.username. I was surprised that we hash this piece of data instead of signedInData.userId, so at debug runtime I switched the value to signedInData.userId and suddenly, refreshToken flow started working.

I have no understanding of cognito's internal mechanisms and expectations, so I might not help understand why things does not work as expected. So if you have an explanation, please provide it to me because I've been struggling for hours trying to figure out why this flow does not work.

Reproduction steps (if applicable)

1. Configure a Identity pool with USER_SRP_AUTH (email login + password flow), and a 1-hour ID token expiration, and a 1-day refresh token expiration
2. sign in or sign up
3. wait for 1 hour

Current behaviour: when RxAmplify.Auth.fetchAuthSession() is called, the resulting AWSCognitoAuthSession contains a session with an error (SecretHash does not match for the client: ...), and the id token is absent from the session.

Expected behaviour: when RxAmplify.Auth.fetchAuthSession() is called, the resulting AWSCognitoAuthSession should be active and refreshed with a new idToken

Code Snippet

// Put your code below this line.

Log output

// Put your logs below this line

Configuration File

No response

GraphQL Schema

// Put your schema below this line

Additional information and screenshots

No response

[tyllark]

Hello @AlexGianq, thanks for taking the time to open up this issue. Did you enable refresh token rotation in your AWS Console? If so Amplify Android does not support GetTokensFromRefreshToken yet so it will break the REFRESH_TOKEN_AUTH flow used to refresh access tokens.

Refresh token rotation isn't compatible with the authentication flow REFRESH_TOKEN_AUTH. To implement refresh token rotation, you must disable this authentication flow in your app client and design your application to submit token-refresh requests with the GetTokensFromRefreshToken API operation or the equivalent SDK method.

You can find this setting here:
AWS Console -> Amazon Cognito -> User pools -> [YOUR_USER_POOL] -> App clients -> [YOUR_APP_CLIENT] -> edit

[AlexGianq]

Hi!
No, refresh token rotation is not enabled in my pool.

As I told you, refresh flow seems to work and I fixed it (for my use only) on a fork.
The problem happens inside FetchAuthSessionCognitoActions class:

 override fun refreshUserPoolTokensAction(signedInData: SignedInData) =
        Action<AuthEnvironment>("RefreshUserPoolTokens") { id, dispatcher ->
            logger.verbose("$id Starting execution")
            val evt = try {
                val username = signedInData.username // if we put "signedInData.userId" here, the flow works correctly for SRP
                val tokens = signedInData.cognitoUserPoolTokens

                val authParameters = mutableMapOf<String, String>()
                val secretHash = AuthHelper.getSecretHash(
                    username,
                    configuration.userPool?.appClient,
                    configuration.userPool?.appClientSecret
                )
                tokens.refreshToken?.let { authParameters[KEY_REFRESH_TOKEN] = it }
                secretHash?.let { authParameters[KEY_SECRET_HASH] = it }

So as shown above, what is hashed inside the SecretHash does not work in my case, but it does work if I hash the userId instead of the username. I suppose that this flow would work for other users (and that's why I did a fork and not a direct PR) but I'm not qualified to understand the internal Cognito hashing rules. Maybe it only works in my configuration case and does not with other auth flows.

[tylerjroach]

@AlexGianq Could you share your amplifyconfiguration so we can make sure that we are testing the same setup you have. We've been testing this a little and haven't been able to replicate needing to switch to userId yet. We understand that you have app secrets enabled or this flow wouldn't be triggered. Are your usernames email, or username?

[AlexGianq]

Usernames are emails and I do use app secrets.
Regarding my amplifyconfiguration, there is not much that I can share, but here's an obfuscated version if this helps:

{
  "UserAgent": "aws-amplify-cli/2.0",
  "Version": "1.0",
  "auth": {
    "plugins": {
      "awsCognitoAuthPlugin": {
        "UserAgent": "aws-amplify/cli",
        "Version": "0.1.0",
        "IdentityManager": {
          "Default": {}
        },
        "CognitoUserPool": {
          "Default": {
            "PoolId": "**********",
            "AppClientId": "**********",
            "Region": "**********",
            "MigrationEnabled": true,
            "AppClientSecret": "**********"
          }
        },
        "Auth": {
          "Default": {
            "OAuth": {
              "WebDomain": "**********",
              "AppClientId": "**********",
              "AppClientSecret": "**********",
              "SignInRedirectURI": "**********",
              "SignOutRedirectURI": "**********",
              "Scopes": [
                "email",
                "openid"
              ]
            },
            "authenticationFlowType": "USER_PASSWORD_AUTH"
          }
        }
      }
    }
  }
}