Aws-sdk-ios: New Identity IDs created for some users unexpectedly

Created on 8 Aug 2020  Â·  9Comments  Â·  Source: aws-amplify/aws-sdk-ios

Describe the bug
When returning from a period of inactivity signed-in users, AWSMobileClient.sharedInstance().identityId does not correctly identify the user that is signed in.

To Reproduce
Intermittent, but using the application then backgrounding it and waiting for 24-48 hours is the most common way to reproduce it.

Observed Behavior

I’ve been struggling with an intermittent issue that seems to affect a small number of our users. We use AWSMobileClient along with a cognito to manage sign-in. We store data files in S3 with the protected status.

The vast majority of the time a user will open the app and AWSMobileClient.sharedInstance().identityId is the correct identityId for the user but sometimes it’s a new identityId with no Linked Logins when viewed in the Identity Browser. This makes me think the user is being assigned a guest identity ID even though they’re still logged in and still have valid session tokens (at least they look valid to me).

Since the identity ID isn’t the correct one for this user, they don’t have permission to upload the file to the given location and uploads fail with Error Domain=com.amazonaws.AWSS3TransferUtilityErrorDomain Code=2 "(null)"

This seems to happen most after a period of inactivity, like a user coming back to the app after a day or two. It’s not a timing issue, the identity ID is incorrect whether I check it immediately upon application launch or just before file upload.

In some cases a force quit of the app resolves the problem but in others the user has to log out and log back in to be assigned the correct identity ID.

I have tried with a handful of AWSMobileClient versions -- the included logs below are from 2.13.4.

The process goes like this:

The user opens the app and AWSMobileClient.sharedInstance().identityId is us-east-1:2340f252-226b-48db-927c-cc8aaecb7274.

The user tries to upload a file to /protected/us-east-1:2340f252-226b-48db-927c-cc8aaecb7274/73BB2F53-3BAF-4B00-8E7E-74834980DE8C.webp

S3 rejects the upload with the following error: error: The operation couldn’t be completed. (com.amazonaws.AWSS3TransferUtilityErrorDomain error 2.) Error Domain=com.amazonaws.AWSS3TransferUtilityErrorDomain Code=2 "(null)" UserInfo={Server=AmazonS3, Transfer-Encoding=Identity, Connection=close, Content-Type=application/xml, Date=Fri, 07 Aug 2020 21:58:27 GMT, x-amz-request-id=AGEV1J1YFV3M9KCP, x-amz-id-2=yryXpLa6lfLXFdXW8fJbZ6qQ6EwRFyCXrYAx17es2Q09jefaLe7e++JVJzL8XFFrciGy7kzUje0=}
Their tokens at this time look like this:

(Instabug Logs - Debug) 07-08 14:58:33.485 Session Expiration Token: Optional(2020-08-07 22:56:01 +0000) 3447.514377951622 seconds since now
(Instabug Logs - Debug) 07-08 14:58:33.485 Session Access Token: Optional(AWSMobileClient.SessionToken(tokenString: Optional("eyJraWQiOiJPbENWZmRNRHVsbWZIQjBxTG9iSkwrQlNqU1haQk5LNXlGN05FYUVFSUtZPSIsImFsZyI6IlJTMjU2In0.eyJzdWIiOiJhOTVkYTE4NS1kYzEzLTQwOTctYjIyNi04MDM5Y2Y5NzM3OTYiLCJjb2duaXRvOmdyb3VwcyI6WyJBZG1pbiIsIlB1YmxpYyIsIkludGVybmFsIl0sImV2ZW50X2lkIjoiNTU1NjQyZTYtOWExOC00MWFmLTgxNDMtNjYyYTE5ODczM2Y0IiwidG9rZW5fdXNlIjoiYWNjZXNzIiwic2NvcGUiOiJhd3MuY29nbml0by5zaWduaW4udXNlci5hZG1pbiIsImF1dGhfdGltZSI6MTU5NjU1NzU3MiwiaXNzIjoiaHR0cHM6XC9cL2NvZ25pdG8taWRwLnVzLWVhc3QtMS5hbWF6b25hd3MuY29tXC91cy1lYXN0LTFfSXE2QTVIT0NZIiwiZXhwIjoxNTk2ODQwOTYxLCJpYXQiOjE1OTY4MzczNjEsImp0aSI6ImZlNTllNDY2LTgzODMtNGFmOC04NGMzLTIzYzI0YzcxNjc4MiIsImNsaWVudF9pZCI6IjFvN2NnYTUza2lhM2wxdjltbjdnc2pmMjNhIiwidXNlcm5hbWUiOiJCMzgzMzM4Ny0xRTFDLTQwQkUtODQxNy05QUZBRUMxNzA3RTgifQ.RbzSlNYDfBZlALnlEaBmEsoS2wT7p1Mz13k1EnYLR_4kE4AwVW_7EihWdce9yZdPkN-m00lppD-xJH6iy4CeZaPbPUBRGTOBJP-YkofN8xWgZ_Va_-y4Lcqc5W2ajJ3mmNAr6AVDVjYDRBOvZSwiwCebw1lerAHzHhW91cO2UqJPpqmTngJXsxhj9gRObKiExqiONLFdGPdOH3G_dJO9kLsPdSFRCswbONeetyhKpqk_Mozd29vN97Phkxqp7peky20SItLz3LZfhear55GDcnu4hskTanIPWDDrR5t-b6CjG4N6VEgItATugw3788PeOsiFbZU3cMTRdU-97yJKeg")))
(Instabug Logs - Debug) 07-08 14:58:33.485 Session Refresh Token: Optional(AWSMobileClient.SessionToken(tokenString: Optional("eyJjdHkiOiJKV1QiLCJlbmMiOiJBMjU2R0NNIiwiYWxnIjoiUlNBLU9BRVAifQ.SlQHnR4ypBFMhUIYgkywBgsno9QNQrOzFeAcYg4ayxhevgbA8FlfNC7Aiz73oLQq55ZzhlOfldNFUT7hlUE3NbdIH6UX2FLeK-HZUvkd4mEHXa_axw3MGtWpU-WQroL4bfUMOmheg0kZtOg_W5YBBh0iRvzeyQtwpS7M30AK4-RgN4bsEVe0R_7qtyWNvkZLm_wCoECCMbKZUfYHnCLRuiArFMhZ1onOpskXnQUH9AHQHHyJoS2KFI_GUGQpi0AZ1n6a6IHyVzi3NtZEi4FDuAV4WOaPofpBqYXuo5dvnobfnLyQcd4PwDqjGxkAJ0sdtJPGAtBA-x43BiJn4U_MXg.ziAhmdhFuEqaVBEx.O2MznE2i7vZGAetxIFuOMTJpCbLxDx_Voqhrcl1PK0QUE1GuEI5W1l22f-seJCNQ9KQhvf2epyEncWso5erz7Y2Zj4AJWfnXJD5gNtWRwfB_s4_AMdWOIXemDUEXYvEpDp0l0_HD3AauQr70VCr4Ir0p9QyIdwWxjbJU16htuqJFLbamAsQMui0AE_zc4hmygy1ccO4XY7TalCItUetWYqocXUfk2WzcmALy3hqJpEvsJzgQ3pdgdEZAmoxdEj4Ea6QX-lLGL_BmiRke9nwqmPu-mkvOXA3Z2aXy4eyYG5Ho_cjO7x60OOt4R44P7j36xBNLQ9u_2lrIQg4O0Pti-yrinuEzxJqYXvwxmqAr3p70WEuTZBhCvcfd-0_bpspS-jPbodg5ph7FWK_C8aDUMQHz-OuxgrGvE__o4DcFgX_2yp9Pda0os7gKBNFBf7ngORIsAKrE3bltkDHnfakwgqnPlmiN0bWraxd5ybapKA4sOSd47CWTlIcWksvA6FzTkFYZdlXAvHXY3fIj_1wDxCn0FlBXoDSVLs0T9ZUOwwRn9S-0erSATxH8QLqeE96nbNTCCG4gX2CUswEFEDJGM1GeVDfT3QFw2_5CBcBZOu3j7zZ6biHEQQjlujUvz4RCZAq6Vs7YuMW8EI4A90iJDa10Ma9ENv9p0_ftfleYd_XYGTgwq2C5EPYVZywV26_UQ9a1-uolb3mBZr1zLTslyoFlbHzX5iEgcOUZ2JkDUQrU8TM4wgNn7os9H57t-R6sfSKoCx8Un6MhH-fIf3iU15v_lP3p29iZ9KvYqZm2m6MOjVeYdPIvud2pEU5HE2is4KgFgcQY43b_b-WF3d_m8I3_EB6Zm4UocJP3dHgXftxQ4k0vEKQEq8Ld94bFvkdEFC8lYJndFHUS5axde5v8seqhDMQkxIBwNPAOxbEgmWSTmnjPzSyPPo4s0vFoysszbZuc0z1ENxb0nAbm8gNcx0rf3peGoJdvhWBgBHIWHIs3gaYUF42W2bQ1-ZZFq4YkRWL1gpy9RG4q8i2jab-zvL5p5hnp4Rg-rICffwrOHoTS6Bwww7ZQaFTazhBfoFUqwcOW_N8hBZWrGb49dTK_ZR4hB6aEgTwm_va0HrZUrvp0KOR1hX_1mu0cZXF8Evah3v6VQ38CQgkydRSVMrV_qFUC1F3xVfrO4n079dCGZ4oJ1UECY2MfX1kTTR3pGBFiOrMT18OT5xR7grtchQ4rQv5DmFcJvloD4IvAz0xsuSuz1BgRqAh_KAWPkiljoWN497VA1Lh4XghooM5fHmoRBUyANKs8kq-QbTHLICz8G6jP8yvi08sWjfN6Ew.85AV3B8IKMXqYUgcmKQ87w")))
(Instabug Logs - Debug) 07-08 14:58:33.485 Session ID Token: Optional(AWSMobileClient.SessionToken(tokenString: Optional("eyJraWQiOiJXMVwvVzlqZU81bjBWVGNaSG5PbTBYTWtONUppczc2UlBoNEdMd2x2WTBNVT0iLCJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJhOTVkYTE4NS1kYzEzLTQwOTctYjIyNi04MDM5Y2Y5NzM3OTYiLCJjb2duaXRvOmdyb3VwcyI6WyJBZG1pbiIsIlB1YmxpYyIsIkludGVybmFsIl0sImlzcyI6Imh0dHBzOlwvXC9jb2duaXRvLWlkcC51cy1lYXN0LTEuYW1hem9uYXdzLmNvbVwvdXMtZWFzdC0xX0lxNkE1SE9DWSIsInBob25lX251bWJlcl92ZXJpZmllZCI6dHJ1ZSwiY29nbml0bzp1c2VybmFtZSI6IkIzODMzMzg3LTFFMUMtNDBCRS04NDE3LTlBRkFFQzE3MDdFOCIsInByZWZlcnJlZF91c2VybmFtZSI6ImhhcnJ5NDJzdW4iLCJhdWQiOiIxbzdjZ2E1M2tpYTNsMXY5bW43Z3NqZjIzYSIsImV2ZW50X2lkIjoiNTU1NjQyZTYtOWExOC00MWFmLTgxNDMtNjYyYTE5ODczM2Y0IiwidG9rZW5fdXNlIjoiaWQiLCJhdXRoX3RpbWUiOjE1OTY1NTc1NzIsInBob25lX251bWJlciI6IisxNDEyNjE2NTY4MCIsImV4cCI6MTU5Njg0MDk2MSwiaWF0IjoxNTk2ODM3MzYxfQ.BCRNkK8MF-IZ4dAjPggh6hsqP9S0v0ScLqlUkfZQMUHBOxdw-XHlAHC5vTKEvV-k5Yy-cbALj1KzzzFVM1b7FytryhRXOxzJPYZpFlinyOINorxPz8m9ibkWPL3hgB1BrLDg38tqrLFbVIHtXqRUx6MwWS-l2qxKq40AcGoC81l0ApoWfHraI6jcBS-eEGpIEpAiTnvRQTn6pGKR_UsvPn1UKDH_gAXhAVRB-x1GePeoUAFBupp2K4ooBtU6Hx9DJ15BFPWF3Ldf1PjrjBolFmSL4CFUd5Hn5Z3ktFmz-x9ffKYcU47j1UpuMU8CdvngB3tlL9xr4Yq0_a78KYb8vw")))

The user logs out and logs back into the application with the same user account.

AWSMobileClient.sharedInstance().identityId is: us-east-1:d685cba2-c463-4b42-bce1-1302240def7c

The user tries to upload a file to protected/us-east-1:d685cba2-c463-4b42-bce1-1302240def7c/07A3A4AF-D1DC-490A-A161-4ADE8B1F19E4.mp4

The upload succeeds.

========

Code Snippet

On application launch one of the first things I do is call:

AWSMobileClient.default().initialize { [weak self] userState, error in … }
Which returns a userState of “signedIn” and no error in both the working cases and the failure cases.

Areas of the SDK you are using (AWSMobileClient, Cognito, Pinpoint, IoT, etc)?

AWSMobileClient, Cognito, AppSync, and AWSTransferUtility -- also Pinpoint but I'm not sure its relevant here.

Environment(please complete the following information):

  • SDK Version: Here's everything relevant from my podfile.lock

    • AppSyncRealTimeClient (1.2.0):

    • Starscream (~> 3.1.0)

    • AWSAppSync (3.1.2):

    • AppSyncRealTimeClient (~> 1.1)

    • AWSCore (~> 2.13.0)

    • ReachabilitySwift (~> 5.0.0)

    • SQLite.swift (~> 0.12.2)

    • AWSAuthCore (2.13.4):

    • AWSCore (= 2.13.4)

    • AWSCognitoIdentityProvider (2.13.4):

    • AWSCognitoIdentityProviderASF (= 1.0.1)

    • AWSCore (= 2.13.4)

    • AWSCognitoIdentityProviderASF (1.0.1)

    • AWSCore (2.13.4)

    • AWSMobileClient (2.13.4):

    • AWSAuthCore (= 2.13.4)

    • AWSCognitoIdentityProvider (= 2.13.4)

    • AWSPinpoint (2.13.4):

    • AWSCore (= 2.13.4)

    • AWSS3 (2.13.4):

    • AWSCore (= 2.13.4)

    • AWSUserPoolsSignIn (2.13.4):

    • AWSAuthCore (= 2.13.4)

    • AWSCognitoIdentityProvider (= 2.13.4)

  • Dependency Manager: cocoapods
  • Swift Version : latest
  • Xcode Version: 11.6
bug cognito wontfix

Most helpful comment

I'm not sure if ours is the same scenario, but our company has seen almost this exact same issue, and root-caused it.

Repro

  • Open our app while unauthenticated (guest user)
  • Use one of the features that calls AppSync under the guest user (now guest user has an identity ID)
  • Sign in

Result: mobileClient.getIdentityId() returns the identity ID for the guest user, not the signed in user. This causes upload failures when trying to use the identity ID to upload to S3

Solution
We found that the guest identity was being returned because AWSIdentityProvider caches identity IDs unless told otherwise. You must call AWSIdentityProvider.clear() to remove the cached identity ID. This can be accomplished through AWSMobileClient by calling AWSMobileClient.clearKeychain() before signing in.

All 9 comments

Is there any further diagnostic information I could provide to help debug this issue?

Hi @austinfitzpatrick

This looks like a bug with the SDK, but I was not able to reproduce this error. Could you please verify that instead of calling AWSMobileClient.sharedInstance().identityId what happens if you call AWSMobileClient.sharedInstance().getIdentityId(). Do you see the same behavior?

yes I do get the same issue. One thing that I realized recently that might be contributing (interested in your opinion) --

We create two appsync clients -- one which makes normal authenticated requests and another which we use for a single endpoint that has IAM authentication (it determines whether a phone number has been invited to our app - so it happens before we can authenticate a user). I was wondering if maybe this IAM app sync client's initialization could, under some circumstances, set a guest identity id on my AWSMobileClient?

As part of my continuing debugging of this issue I've changed our startup flow to delay the creation of the IAM authentication until we actually need it - so that logged-in users will never create this second appsync client. I haven't seen the issue first-hand since making this change, but it is intermittent and hard to reproduce on demand, so I'm not convinced I've solved it yet.

Reproduced again, delaying creation of the IAM client did not help. In this session an IAM client was never created, but it just happened again. The brand new identity ID was created: us-east-1:d743f034-1347-4717-8ab0-1c11023b9b25

Session ID tokens look like this:

(Instabug Logs - Error) 25-08 9:29:36.225 run task error: The operation couldn’t be completed. (com.amazonaws.AWSS3TransferUtilityErrorDomain error 2.)
(Instabug Logs - Info) 25-08 9:29:36.224 Error on task, 0 tries left
(Instabug Logs - Debug) 25-08 9:29:36.224 upload video failed
(Instabug Logs - Debug) 25-08 9:29:36.224 Session Expiration Token: Optional(2020-08-25 17:25:50 +0000) 3373.775573015213 seconds since now
(Instabug Logs - Debug) 25-08 9:29:36.224 Session Access Token: Optional(AWSMobileClient.SessionToken(tokenString: Optional("eyJraWQiOiJPbENWZmRNRHVsbWZIQjBxTG9iSkwrQlNqU1haQk5LNXlGN05FYUVFSUtZPSIsImFsZyI6IlJTMjU2In0.eyJzdWIiOiJiMzQ5NDcwMi1kOWU5LTQ1NjYtOWRmYi03NTY3NDM4YjVhY2EiLCJjb2duaXRvOmdyb3VwcyI6WyJGYXJtZXIiLCJBZG1pbiIsIlB1YmxpYyIsIkludGVybmFsIl0sImV2ZW50X2lkIjoiYTg2Mjc4ZDQtODRhYi00NjUwLThlN2UtNTFmZmNjZDliM2M3IiwidG9rZW5fdXNlIjoiYWNjZXNzIiwic2NvcGUiOiJhd3MuY29nbml0by5zaWduaW4udXNlci5hZG1pbiIsImF1dGhfdGltZSI6MTU5NzA2MTA3MCwiaXNzIjoiaHR0cHM6XC9cL2NvZ25pdG8taWRwLnVzLWVhc3QtMS5hbWF6b25hd3MuY29tXC91cy1lYXN0LTFfSXE2QTVIT0NZIiwiZXhwIjoxNTk4Mzc2MzUwLCJpYXQiOjE1OTgzNzI3NTAsImp0aSI6ImIwMjI1ODk0LTc3NzMtNDM1Ny1iYzA0LTJjZGFiMjUzMWY4MyIsImNsaWVudF9pZCI6IjFvN2NnYTUza2lhM2wxdjltbjdnc2pmMjNhIiwidXNlcm5hbWUiOiJDMjNFNTlFMS00MEJGLTQ3NjEtQUU5Ny01OUMzMTBFMEI5OEEifQ.ZhT0cJI5JBM2LjhYOMQSmpZtTUXdXZkdmJ3mIApDyOswKqMbMpQ04odY4H89_2yg91YjTU9itu5Q1GsPv2e7UQzY8B5gKYJ1ugXHFNZgKybQow7fkZXzRs118c0e8_2Ul44IRl-ydcxhuqFSMuN42aT8jHfSK_-Ay6GXr6PTk8T2a-IcrXb4xj0U2u3VzZ0VKhXY7GHqUZz4P29iLydHw88fwPtcQ8xLrGF9aZpT2BVFdNMHUPD4k5k-DRDseUasKoIGpUfJ2mNhIOOk5612DpCepr26-G4_tHS7_ZggFx7nzfI_UxHMFvEB7KIGW4i5g-bwzZmAlMZJZsTwqsamaw")))
(Instabug Logs - Debug) 25-08 9:29:36.223 Session Refresh Token: Optional(AWSMobileClient.SessionToken(tokenString: Optional("eyJjdHkiOiJKV1QiLCJlbmMiOiJBMjU2R0NNIiwiYWxnIjoiUlNBLU9BRVAifQ.Ze8GgiTxbbgWrJGSveWCIclAwFV2aMPqXtPTrUei5GADgyDfDH1Pw85NdKYrXFU0ww_Dcwwe-LMhvPBxY1pnooBDZzq3AeISTlo_IRSIhXpVUnQXJ3mHKqL_xl-hfJb6Ak2BM77n0sovAH3XTLd_uo3gOTVnSUqKUwR72JYwcfxzVXN5UeVCIa5BoTp1ZN3qmmNmbc9URcYWPI6KC8dX2pkvq7hoXyvuxNPpARM0XFcyuGlR40bPgtGPj-nEJFi964XzyabtWyQT5YxNatd8jkfmY8Eoz3-AOjoK1HP8qF_5so0EEH5zq1LGFWEj1WCqrgDtB9aH_FbPuoxFIuAUSw.u63XCEwUHmmWxXo7.0G8wGpqwkJJeW4RKHnymL0cCcKngQ15JCAfOcpA5TklyEgQTtj1I4cbeTtMWEGlk-THsYr4Vg9dhdMgykT7_LsAL_IcD3WU-MYs_sQA25mOJyTUFLUApddOfi4vn3rKZgIB8nXBCJFH9ZoLdjet7YqNIfE09X7NG7b7BsZL1cZTFTxZCV1JwjHY4i7ax9jnVAy9VfHWStixB145C4Nau-GelfKQ9uBOrbwsVfyG6P09aDwCtcQQbS28EWtzuPxM45kKSnyYV7-GdMP7RiSAXtgEPF4DrFRy6xHX2l70Dfr6AQ8SoZEy5IgyAsCnNHmMQYE948xOGOykEFOvuCqGmk8v8ltrtHFV7oZijcdU5Pwnl0u6V-CWL31KGN8tPQPbrBbIouQBnuRIX6g68eqExsYf0r5HN7kLDSWm1wGBIGHlNHqEsLrxDwS2tS-nrX48CrOaLx3MgyF3_XWDMzC6puuNoMfW_ZdOHZTfmWKiOEl9Ds0A2XIuEJvbKXVRJAI21q86Zd2o_Ov4X1rq0saUIpGaSPFGIVSGlTJlgcgw6oIu8b_7G18Yr5nnsxv34wry-j1IeyGt3IEC4VZ-zojw_2SXcHfFPua0M45-TEvFOAp85eot7GvfLcyGA5d1uMh5-lIGjfm7mAMox3DJX5g18keRNveZByBrtgL0Ay7K98AshjR6LirgnrQn706MoBh9aCTc5CaFzXFQtPKk_44GXaPprkwrzxcBL-LXdNrV6Mrhq4CIyN6SevIo8cAYIxGdM_SlV-8bAbxB6ZZBPTuvg28xZoJAYchAqfuu0K0752YfrJF2XMNqiUimE3GuYLejRCyJFMAPBKg2aPucpf-vFigN9sP-R0Wo-hPLN2W66XJpe9Dhzk3cQOPjQ8F_dI_VyrQj5WqQ_oIudxZ_G-OGajDJTkzJrC9QBfEF1_tDaAB2_pfOLTApbluy8pptNU3iTBjF1FofzDP3e64Ji1aezGXUFVBpp_37ihP4DjMmb_92uI4880f0Z1JrvPF4psfLgdap3gbA2TMhp6lP1NYJWegrgASmBaX18enDR0qTHerEM88nbin_eU0Lo-bBqJiZwwpUc_K4y1yJcGfuSKYs5qs7gNIlTN8emD3kbq3k3sMzCstMnYfzyfpLNwBkeTTHfYzjhxntq1IH7lm0-rTz6JjEAOpNF3sp6Z6gjg7j42M8uZZcBA2q3BHUEUWaEftaKSM6NjHm44XnHt6sLJy8p0rFfDUEL-NFOqLM7UhhNZ8hN8jZ9qttZgv3rBWOrB35_VCwxPUZhcvL5bHzDrRXkZSOvAYIlKQfhx6CtE0Wl3Pgc5_lj8OuocLqo1A.ATI-Nw3Z0WjIoLbNeGe9XQ")))
(Instabug Logs - Debug) 25-08 9:29:36.223 Session ID Token: Optional(AWSMobileClient.SessionToken(tokenString: Optional("eyJraWQiOiJXMVwvVzlqZU81bjBWVGNaSG5PbTBYTWtONUppczc2UlBoNEdMd2x2WTBNVT0iLCJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJiMzQ5NDcwMi1kOWU5LTQ1NjYtOWRmYi03NTY3NDM4YjVhY2EiLCJjb2duaXRvOmdyb3VwcyI6WyJGYXJtZXIiLCJBZG1pbiIsIlB1YmxpYyIsIkludGVybmFsIl0sImlzcyI6Imh0dHBzOlwvXC9jb2duaXRvLWlkcC51cy1lYXN0LTEuYW1hem9uYXdzLmNvbVwvdXMtZWFzdC0xX0lxNkE1SE9DWSIsInBob25lX251bWJlcl92ZXJpZmllZCI6dHJ1ZSwiY29nbml0bzp1c2VybmFtZSI6IkMyM0U1OUUxLTQwQkYtNDc2MS1BRTk3LTU5QzMxMEUwQjk4QSIsInByZWZlcnJlZF91c2VybmFtZSI6Im9rdXB5biIsImF1ZCI6IjFvN2NnYTUza2lhM2wxdjltbjdnc2pmMjNhIiwiZXZlbnRfaWQiOiJhODYyNzhkNC04NGFiLTQ2NTAtOGU3ZS01MWZmY2NkOWIzYzciLCJ0b2tlbl91c2UiOiJpZCIsImF1dGhfdGltZSI6MTU5NzA2MTA3MCwicGhvbmVfbnVtYmVyIjoiKzM4MDkzNjIwNDc3NyIsImV4cCI6MTU5ODM3NjM1MCwiaWF0IjoxNTk4MzcyNzUwfQ.EK2TKT36P-tzWretuPwA6Kw9LhayBoK_zHdSTt41LeLpiDTgr7Jh-E5Km_NzZz8X8bglC6mDM1VROdJftFD0-VwoDBhyKa3xgjUUKhPUWAiyzWmIt_wbgIBi7yQAPr5N2mPSm0rccGmXOQEilaRxmg97aX5u0l2zUk6aKvV-hzxxd_uWwqaGAUkq_S1u5LdPe5bNzYdAVsE_x45Bx5pSSmOl52Zn1lGaU5YrdtoRqtCIq728vzbeeDIPiXyUpjLxyjbdUANpcBVAAT65pFl-1jKH-vOjjFvGipRpmJ0zVCoftsWYZvg1LrRwU3COvQinoacJVgdZPrK9GSY_66kmvA")))

Are there any updates here or anything else I can provide? Seeing production users getting hit with this, would love at least advice on a workaround.

We were still not able to reproduce the behavior. I am interested in knowing the usage of your two AppSync client and wondering whether that is causing the issue. How does your Appsync client gets the necessary credentials ? Are you using AWSMobileClient for both of them, ie one with authenticated and the other with unauthenticated access (which could be an issue)?
Also, what is your authentication provider? Is it Cognito User Pools, Other Social providers, Hosted UI?

Make sure that you are listening to auth events and check if the user is signout or not - https://docs.amplify.aws/sdk/auth/how-it-works/q/platform/ios#state-tracking

I'm not sure if ours is the same scenario, but our company has seen almost this exact same issue, and root-caused it.

Repro

  • Open our app while unauthenticated (guest user)
  • Use one of the features that calls AppSync under the guest user (now guest user has an identity ID)
  • Sign in

Result: mobileClient.getIdentityId() returns the identity ID for the guest user, not the signed in user. This causes upload failures when trying to use the identity ID to upload to S3

Solution
We found that the guest identity was being returned because AWSIdentityProvider caches identity IDs unless told otherwise. You must call AWSIdentityProvider.clear() to remove the cached identity ID. This can be accomplished through AWSMobileClient by calling AWSMobileClient.clearKeychain() before signing in.

Thank you for the report. I did some testing around identity ID and this is what I observed. There is an issue that I could reproduced as well in one of the test case. We are trying to fix that now:

Case 1:

I start the app as a Guest, SignUp a new user and then SignIn using that user.

  1. Guest Identity Id - us-east-1:ded0718e-1aa5-4513-9a13-5e0732798b68
  2. Sign up a user
  3. SignIn the new user Identity Id - us-east-1:ded0718e-1aa5-4513-9a13-5e0732798b68

Conclusion: Guest user identity id is migrated to a authenticated identity id.

Case 2:

I start the app with signed in user and then signed out and move to Guest

  1. Signed In user Identity Id - us-east-1:ded0718e-1aa5-4513-9a13-5e0732798b68
  2. Guest Identity Id - us-east-1:ff8a9f50-b3e8-4fa2-bd2a-de49846a1ce3

Conclusion: The identity id of the app changes to a different one when the user sign out.

Case 3:

I start the app as a Guest, I sign in using an existing user.

  1. Guest Identity Id - *us-east-1:ff8a9f50-b3e8-4fa2-bd2a-de49846a1ce3 *
  2. Signed In user Identity Id - *us-east-1:ded0718e-1aa5-4513-9a13-5e0732798b68 *

Guest Identity Id *us-east-1:ff8a9f50-b3e8-4fa2-bd2a-de49846a1ce3 *is disabled.

Conclusion: When signIn using an existing user, the identity Id is converted to the users identity Id they had. Also the guest identity id was disabled when checked in the Cognito Identity Pool.

Case 4:

I start two devices in Guest, In Device-A I signUp a new user, then I sign in same user to Device-B. Then I sign in to device-A

_Device A_

  1. Guest Identity Id - *us-east-1:1f73b4bf-a98e-49af-a3d6-2e9f4da92626 *
  2. Guest Identity Id after sign Up - *us-east-1:1f73b4bf-a98e-49af-a3d6-2e9f4da92626 * (remains same, because I did not signIn)
  3. Now I go to Device B

  4. After signed I in Device B, I then signed in to Device A

  5. Signed In user Identity Id - *us-east-1:8fd1d7e8-5d97-4af8-85d3-75804e4aa9d9 *
  6. Guest Identity Id us-east-1:1f73b4bf-a98e-49af-a3d6-2e9f4da92626 is disabled

_Device B_

  1. Guest Identity Id - *us-east-1:8fd1d7e8-5d97-4af8-85d3-75804e4aa9d9 *
  2. Signed In user Identity Id - *us-east-1:8fd1d7e8-5d97-4af8-85d3-75804e4aa9d9 *

Conclusion: When user sign up in a device and then sign in in another device, the guest identity id of the second device is migrated to an authenticated identity id. The first device guest identity Id remains the same. If we then sign in to the first device, the guest identity id is disabled in Cognito Identity Pool and the device’s takes the signed in user identity id.

Case 5 :

I sign in using a user-A then signout then sign in using user-B

  1. Guest Identity Id - *us-east-1:5110a3ee-88da-48b4-a86f-fe4d43d284c7 *
  2. User 1 sign in - us-east-1:ded0718e-1aa5-4513-9a13-5e0732798b68 (Previous Guest identity id got disabled)
  3. Guest Identity Id - us-east-1:e4dbfba5-efc2-43c8-aacb-49d95c42dfeb (New guest id after signout)
  4. User 2 sign in - us-east-1:8fd1d7e8-5d97-4af8-85d3-75804e4aa9d9 (Previous Guest identity id got disabled)

*Conclusion: When sign in from guest to an existing user, the identity id of device changes from guest identity id to the already existing identity id of the user. The guest identity Id will get disabled in the Cognito Identity Pool after sign in. Then when you sign out, the app gets a new guest identity id. *

Case 6:

Identity Id after each sign out.

After each signout the app moves to a guest status. The identity Id changes to a new identity id after each sign out.

Case 7: FAILED!!!

Fetch identity Id immediately after sign in.

AWSMobileClient.default().getIdentityId().continueWith { (task) -> Any? in
    print("Guest id = \(task.result)")
    AWSMobileClient.default().signIn(username: "<email>", password: "<password>") { (result, error) in

        AWSMobileClient.default().getIdentityId().continueWith { (task) -> Any? in
            print("signed in id = \(task.result)")
        }

    }
    return nil
}

Output


Guest id = Optional(us-east-1:3c304a1b-4711-40a1-aaa7-479572d75cc7)
signed in id = Optional(us-east-1:3c304a1b-4711-40a1-aaa7-479572d75cc7)

We investigated a couple of approaches to change AWSMobileClient to refresh the id token immediately after signIn. However, each of the approaches presented significant risk, and so we have elected not to change this behavior.
In the meantime, you can manually update the id token by calling getAWSCredentials, which internally fixes the id token for the signed in user.

     AWSMobileClient.default().signIn(username: “”,
                      password: “”) { (result, error) in
       AWSMobileClient.default().getAWSCredentials { (_, _) in
         let identityId = AWSMobileClient.default().identityId
       }
    }

(AWSMobileClient does this internally, but does it asynchronously, which is why there is a potential gap between sign in and seeing the updated identity token.)

Was this page helpful?
0 / 5 - 0 ratings