Aws-sdk-ios: non-ascii characters in user claims sometimes unable to be decoded

[bennettk]

Describe the bug
In certain cases- I'm not 100% sure of the sequence, but we've been able to replicate it by creating a user whose first_name or last_name claims end in -oña (this was first reported by a user whose first name was 'Doña')- the claims portion of the JWT idToken we get back from cognito for the user doesn't decode properly on iOS. In tokenClaims on AWSCognitoIdentityUser.m, we get the error 'token is not valid base64'. The user's idToken decodes fine on other platforms, and our apps depend on the claims in the idToken being decoded properly to function.

To Reproduce
Here's a (test) ID token we have that exhibits this bad behavior. Calling tokenClaims on this token will return nil and result in AWSDDLogError(@"Token is not valid base64"); being called.

eyJraWQiOiJaS0s5ZUlZbmo4UEtGQzUrMHdMQUhJMjd0SWcxRkRRZU9ybW82SVwvdFkwbz0iLCJhbGciOiJSUzI1NiJ9.eyJmYy1pZCI6IjE2ZjFkOTM3LTY5YmQtNGI2OS1hMzJmLWYwNjkxNGY0YzIxOCIsInN1YiI6IjE2ZjFkOTM3LTY5YmQtNGI2OS1hMzJmLWYwNjkxNGY0YzIxOCIsImlzcyI6Imh0dHBzOlwvXC9jb2duaXRvLWlkcC51cy1lYXN0LTEuYW1hem9uYXdzLmNvbVwvdXMtZWFzdC0xXzhqRVI4cHY0ViIsImNvZ25pdG86dXNlcm5hbWUiOiIxNmYxZDkzNy02OWJkLTRiNjktYTMyZi1mMDY5MTRmNGMyMTgiLCJnaXZlbl9uYW1lIjoiQm_DsWEiLCJhdWQiOiI2bTZ1dWlocmhzM3BzbGI0amhhdHJzYnBxYyIsImV2ZW50X2lkIjoiYjAzZjQ1YWMtM2FlMS0xMWU5LTlkZDItODcyODBlYTRiMGNhIiwidG9rZW5fdXNlIjoiaWQiLCJhdXRoX3RpbWUiOjE1NTEzMDc2NjEsImV4cCI6MTU1MTMxMTI2MSwiaWF0IjoxNTUxMzA3NjYxLCJmYW1pbHlfbmFtZSI6IkJhcsOnYSIsImVtYWlsIjoiaW5mb0Bkb25hYmFyY2EzLmRlIn0.OGT9siqf_tAYrhVA-EhYabz-L4ZNLe0w0N7fH4rASs0scRGm-34g96qmSZoD1j74bplIRcMqoFaDI0cLejyeeLN-z2ib1MDsuMnyq8cHfuu4x4qBGVcxWGkIOBjAEdsiU5U4xsEuaRpgC1rNiS7X6t0vQsDj3Jw3cV1XmJbeHaZB8D7EUMW6-zk4ZT2jKrpiaeaPTFoJJFOYiYdlJj4zkxXT2nzldS9K57Mwz91YgbjF_VCxPl84b-aiBoj7_ARdu8LDP2HHkpVoNslWYuusatBOOJvTT56Fa2kJzZqoUuAnGiC8AYU_YKpL_iu-wv5xnWHthuDCxhpl85cdROrAbA

Which AWS service(s) are affected?

We're seeing this in the iOS AWSCognitoIdentityUser.m from the AWSCognitoIdentityProvider pod.

Expected behavior
Valid decoded claims are returned when calling tokenClaims, not nil. The website jwt.io can successfully decode this idToken and returns the following for the claims (again, all data is not a real user but the first name is based on one):

{ "fc-id": "16f1d937-69bd-4b69-a32f-f06914f4c218", "sub": "16f1d937-69bd-4b69-a32f-f06914f4c218", "iss": "https://cognito-idp.us-east-1.amazonaws.com/us-east-1_8jER8pv4V", "cognito:username": "16f1d937-69bd-4b69-a32f-f06914f4c218", "given_name": "Boña", "aud": "6m6uuihrhs3pslb4jhatrsbpqc", "event_id": "b03f45ac-3ae1-11e9-9dd2-87280ea4b0ca", "token_use": "id", "auth_time": 1551307661, "exp": 1551311261, "iat": 1551307661, "family_name": "Barça", "email": "[email protected]" }
Screenshots
n/a

Environment(please complete the following information):
This has been verified as still broken in the most recent version of the AWSCognitoIdentityProvider cocoapod, but in our app, this is the setup we're using. This appears to happen across iOS versions and device types.

• AWSCognitoIdentityProvider (2.7.4):
  
  
  
  • AWSCognitoIdentityProviderASF (= 1.0.1)
  
  
  • AWSCore (= 2.7.4)
  
  

[kvasukib]

@bennettk Sorry for the inconvenience caused. We are looking into the issue.

[rohandubal]

Hello @bennettk

I can confirm I can reproduce this issue on our side. I will sync with the service team if there are any specific guidelines on supporting characters like ñ. Once those details are clear, I will work on a fix for the issue.

Note - This issue also impacts AWSMobileClient which would face same issue and needs to be addressed also.

Thanks,
Rohan

[rohandubal]

Update: I have discussed this with the service team and this is a valid and supported use-case and needs to be fixed in the SDK. We will work on a fix and update the thread once we have a fix out.

[bennettk]

hi, any updates on this? we're still seeing users who are affected by this daily.

[wooj2]

We looked into this and the error seems to be emitted from:
https://github.com/aws-amplify/aws-sdk-ios/blob/742f8a134504832fc72be75d8a3b74a8542cd493/AWSCognitoIdentityProvider/AWSCognitoIdentityUser.m#L1610

As described in the original post, this happens when you have a tokenString, and are using AWSCognitoIdentityUserSessionToken to decode it into a NSDictionary<NSString*, id>. To avoid this, we are recommending that developers create their own function to decode the base64 string parse it appropriately.

Given that developers are able to work around this issue, and the age of the bug is quite dated, we are marking this as a 'won't fix', and closing this bug. If any of our assumptions are incorrect or you are unable to work around this bug, please let us know.