Cognito users have to verify email every time they log in

Describe the bug

When logging into an app using aws-amplify-react, the user is prompted to verify their email address every time they log in. This persists whether or not email verification is enabled in the user pool configuration.

To Reproduce

I’m not sure if there’s an easy way to reproduce this. I stood up one version of the stack and it worked fine, but then when standing up another version with the same configuration I suddenly saw the problem. No amount of messing with the parameters so far has allowed me to fix the issue. It’s possible this is a configuration issue on my end; if so I’d appreciate advice on how to further debug, since I feel like I’m up against a wall.

Here are the relevant user pool parameters (trimmed of any parameters that are just references to resource names):

{
    "allowUnauthenticatedIdentities": false,
    "thirdPartyAuth": false,
    "autoVerifiedAttributes": [
        "email"
    ],
    "mfaConfiguration": "OFF",
    "mfaTypes": [
        "SMS Text Message"
    ],
    "smsAuthenticationMessage": "Your authentication code is {####}",
    "smsVerificationMessage": "Your verification code is {####}",
    "emailVerificationSubject": "Your verification code",
    "emailVerificationMessage": "Your verification code is {####}",
    "defaultPasswordPolicy": true,
    "passwordPolicyMinLength": 8,
    "passwordPolicyCharacters": [],
    "requiredAttributes": [
        "email"
    ],
    "userpoolClientGenerateSecret": true,
    "userpoolClientRefreshTokenValidity": 30,
    "userpoolClientReadAttributes": [
        "email"
    ],
    "userpoolClientSetAttributes": false,
    "useDefault": "manual",
    "authSelections": "identityPoolAndUserPool",
}

Expected behavior

I’d expect that once a user has the attribute email_verified, they wouldn’t have to verify their email again.

Desktop (please complete the following information):

• OS: Ubuntu 18.04 and MacOS Mojave
• Browser: Chrome 72.0.3626.109, Safari 12.0.1

Additional context I don’t know which service this bug might be appearing in. Here are the versions I have installed of all Amplify packages:

• aws-amplify: 1.1.19
• aws-amplify-react: 2.1.7
• @aws-amplify/cli: 0.1.45

I recognize that some of these are now outdated, but I wanted to avoid upgrading them for fear of having to migrate the project.

[jeancochrane]

Finally got to the bottom of this! Turns out it was a configuration error on my end – during the CLI wizard, I neglected to set UserPoolClient.ReadAttributes to include email_verified. In the CLI, this corresponds to the following steps in amplify add auth:

? Do you want to specify the user attributes this app can read and write? Yes
? Specify read attributes: (Press <space> to select, <a> to toggle all, <i> to invert selection)
 ◯ Updated At
 ◯ Website
 ◯ Zone Info
❯◯ Email Verified?
 ◯ Phone Number Verified?
 ◯ Address
 ◯ Birthdate
(Move up and down to reveal more choices)

Thanks for your debugging assistance @haverchuck and @elorzafe, I appreciate it!

[zfarrell]

I just got hit with this. For those that need to fix this:

1. open up amplify/backend/auth/$cognitofolder/parameters.json
2. find userpoolClientReadAttributes array and add email_verified
3. run amplify push

Is there a use case where the *_verified attributes shouldn’t be returned? At the least, it seems like the CLI wizard should try and talk you out of disabling them as read attributes (and describe the consequences).