Open pdguru81 opened 6 months ago
Hello @pdguru81 - Thanks for taking the time to open the issue and provide the info above.
Can you share reproduction steps so that we can attempt to produce this? See below for an example of reproduction steps:
I see you linked the v1 upgrade guide. Were you previously using Amplify v0.x and are now upgrading to v1?
Yes, the reproduction step is pretty much what you have described. We started out with V0.X, and then migrated to V1? However, the problem persists. In our case, we end up with SessionExpiredException
after the session expires.
We started out with V0.X, and then migrated to V1? However, the problem persists
Okay. It sounds like you are saying that upgrading from v0 to v1 isn't required as part of the reproduction steps. I would like to confirm that. Are you able top reproduce this if you follow these steps:
Yes, I am confirming that we already use V1 and don't need to upgrade. We also just tested again following step 1 to 6. After 5 minutes, what we get is actually SignedOutException
. This is shown in the screenshot below where we signed in using AmplifyV1.6 and then waited 5 minutes. Subsequent calls to Amplify.fetchAuthSession()
returned SignedOutException
Screenshot shows the error we log.
To add, we just checked cloudtrail logs and are seeing an error about the refreshToken being invalid. It's unclear why this happens since we don't modify or manage the refresh tokens directly.
"userAgent": "amplify-flutter/1.6.2 ios/17.0.1 aws-sdk-dart/0.3.1",
"errorCode": "NotAuthorizedException",
"errorMessage": "Invalid Refresh Token."
We've narrowed this issue down to the fact that device tracking prevents valid refresh tokens from being sent. Had to look at Cloudtrail logs for an idea of the problem. Why do token refreshes fail when device tracking is enabled? 🤔
I haven't heard back. I am updating this ticket with the steps to reproduce for amplify-flutter sdk:
Steps to Reproduce
Login to cognito and observe that sessions don't auto-refresh after 5 minutes when device tracking is on - even in cases where refreshToken is set to expire after 30 days.
@pdguru81 Thanks for the detailed reproduction steps. I believe this is related to https://github.com/aws-amplify/amplify-flutter/issues/4501
This is a known issue with USER_PASSWORD_AUTH that we are looking into.
@pdguru81 I wanted to confirm that you are using USER_PASSWORD_AUTH
to migrate users from a legacy user management system as described in the Cognito docs here: https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-authentication-flow.html#amazon-cognito-user-pools-user-migration-authentication-flow
Just seeing this: No, we are not migrating users from a legacy system. We have been using cognito from day 1 and started encountering this problem when we used flutter sdks to build our mobile app and manage user logins. All the users we have so far were created on cognito
@pdguru81 is there another reason that you are using the USER_PASSWORD_AUTH flow? This is typically only used when you are migrating users from another auth provider.
USER_SRP_AUTH, which is the default in Amplify, is the recommended flow by Cognito unless you have a specific use case that requires a different need. This bug seems to only be present when using USER_PASSWORD_AUTH. I believe if you could switch to USER_SRP_AUTH to resolve this.
Interesting, we will test that out and see.
@pdguru81 - Have you had a chance to test switching to the SRP flow?
@pdguru81 - Just following up on this. I wanted to see if you have had a chance to switch to the SRP flow.
I am definitely seeing similar behaviour, and have confirmed that we are not using USER_PASSWORD_AUTH.
We had been using a very old (v0) version of the flutter package, and were forced to upgrade to avoid deprecation. Post migration, we're now receiving reports from production customers that they can not stay logged in.
We see lots of SessionExpiredException (telling us to sign in to fix) (~500 occurrences) and some NotAuthorizedExceptions (~7)
I have not found a reliable way to reproduce this, but it is definitely happening in production and is causing major headaches for our customers. Please let me know what I can do to provide more information - this is extremely critical for us.
@michael-joseph-payne There was a known issue (see: https://github.com/aws-amplify/amplify-flutter/issues/3995) that prevented access/id tokens from being refreshed when device tracking was enabled after upgrading from v0 to v1. End users would be signed out after the access/id expired. After re-authentication tokens would be refreshed as expected. This was resolved in Amplify Flutter v1.7.2.
@Jordan-Nelson Ok, sounds good - the release in question used amplify_flutter 1.6.1 so I believe it should be addressed by upgrading to 1.7.2+
I'll check back in after we canary a bit
As a follow up question - does setting forceRefresh in FetchAuthSessionOptions work around this issue?
@michael-joseph-payne - it would not.
The issue prior to v1.7.2 was that the device meta data was not migrated from v0 to v1. When a user signs in with device tracking enabled, tokens cannot be refreshed unless the device ID is included as part of the refresh request.
Description
We configured amplify flutter with the settings below. However, ID/Access Tokens are still not refreshed after they expire. It's quite strange because the docs say Amplify should do this automatically. What are we missing and how do we fix?
Categories
Steps to Reproduce
No response
Screenshots
Settings
Sample code we use per this doc:
Amplify Flutter
Platforms
Flutter Version
3.3.10
Amplify Flutter Version
1.6.1
Deployment Method
Custom Pipeline
Schema
No response