Amplify Console Build Failure - facebookAppId, amazonAppId, googleClientId, hostedUIProviderCreds] must have values

I added auth to my project with the Facebook, Google, and Amazon Logins. I got Cognito working well, so I decided to add an API using the AppPool for security.
I added the default graphQL API that adds todos with a simple one-to-many relationship, I ran amplify push and everything worked great. AppSync, Dynamo, and Cognito were all looking perfectly in each console.
I committed my code to git and pushed, which kicked off an Amplify Console build that failed with the following error message. Notice how it is complaining that it cannot find values for my facebookAppId, amazonAppId, googleClientId, hostedUIProviderCreds. That is confusing because Cognito is working perfectly with all 3 providers...
UPDATE_FAILED               authdevilsswille50c45c5         AWS::CloudFormation::Stack Tue Oct 22 2019 14:04:31 GMT+0000 (Coordinated Universal Time) Parameters: [facebookAppId, amazonAppId, googleClientId, hostedUIProviderCreds] must have values

I expected the Amplify console to be able to build and deploy this project since amplify push  worked fine from my machine.
If I remove the API, Cognito still works fine, I can commit and push at this point and the Amplify Console will build and deploy my project fine.
Any insight is always appreciated.

@KidSysco are you creating a new backend environment through the Amplify Console or are you reusing one created through the CLI?

That is a really good question, I guess it is unclear what I am supposed to do here.
I use the CLI to push everything and test my code locally.
In the Amplify Console, I noticed there is a setting only available when setting up the app for the first time. It asks me if I want to deploy the backend, or only deploy the front end. I tried to change this setting after the app was created but I was unable to find a way. The only way to change that setting appears to be to delete the app from the Amplify Console and add it again.
Even when I deleted the app, added it again so I could try to only deploy the front end, I ran into permissions problems. I followed the directions to remove the aws-exports.js file from the GitIgnore and I did not need to choose an account to use to deploy the backend resources. But once I hit save, it complained about the role that is needed to deploy backend resources and gave me an error. However, it still added the app, but it would not deploy and just gives me a permissions error about the account needed to deploy the backend resources whenever it tries to build.

@KidSysco Using Amplify console to build and deploy the project, you could try:

Create your own amplifypush.sh like myamplifypush.sh in root folder amplify-auth-app/myamplifypush.sh
Add your authconfigs to the bash script

#!/usr/bin/env bash
set -e
IFS='|'
help_output () {
    echo "usage: amplify-push <--environment|-e <name>> <--simple|-s>"
    echo "  --environment  The name of the Amplify environment to use"
    echo "  --simple  Optional simple flag auto-includes stack info from env cache"
    exit 1
}

init_env () {
    ENV=$1
    AMPLIFY=$2
    PROVIDERS=$3
    CODEGEN=$4
    AWSCONFIG=$5
    CATEGORIES=$6
    echo "# Start initializing Amplify environment: ${ENV}"
    if [[ -z ${STACKINFO} ]];
    then
        echo "# Initializing new Amplify environment: ${ENV} (amplify init)"
        amplify init --amplify ${AMPLIFY} --providers ${PROVIDERS} --codegen ${CODEGEN} --categories ${CATEGORIES} --yes;
        echo "# Environment ${ENV} details:"
        amplify env get --name ${ENV}
    else
        echo "STACKINFO="${STACKINFO}
        echo "# Importing Amplify environment: ${ENV} (amplify env import)"
        amplify env import --name ${ENV} --config "${STACKINFO}" --awsInfo ${AWSCONFIG} --categories ${CATEGORIES} --yes;
        echo "# Initializing existing Amplify environment: ${ENV} (amplify init)"
        amplify init --amplify ${AMPLIFY} --providers ${PROVIDERS} --codegen ${CODEGEN} --yes;
        echo "# Environment ${ENV} details:"
        amplify env get --name ${ENV}
    fi
    echo "# Done initializing Amplify environment: ${ENV}"
}

ENV=""
IS_SIMPLE=false
POSITIONAL=()
while [[ $# -gt 0 ]]
do
    key="$1"
    case ${key} in
        -e|--environment)
            ENV=$2
            shift
            ;;
        -r|--region)
            REGION=$2
            shift
            ;;
        -s|--simple)
            IS_SIMPLE=true
            shift
            ;;
        *)
            POSITIONAL+=("$1")
            shift
            ;;
    esac
done

set -- "${POSITIONAL[@]}"

# if no provided environment name, use default env variable, then user override
if [[ ${ENV} = "" ]];
then
    ENV=${AWS_BRANCH}
fi
if [[ ${USER_BRANCH} != "" ]];
then
    ENV=${USER_BRANCH}
fi

# Check valid environment name
if [[ -z ${ENV} || "${ENV}" =~ [^a-zA-Z0-9\-]+ ]] ; then help_output ; fi

AWSCONFIG="{\
\"configLevel\":\"project\",\
\"useProfile\":true,\
\"profileName\":\"default\"\
}"

AMPLIFY="{\
\"envName\":\"${ENV}\"\
}"

PROVIDERS="{\
\"awscloudformation\":${AWSCONFIG}\
}"

CODEGEN="{\
\"generateCode\":false,\
\"generateDocs\":false\
}"

AUTHCONFIG="{\
\"facebookAppIdUserPool\":\"888888888888888\",\
\"facebookAppSecretUserPool\":\"88888888888888888\"\
}"

CATEGORIES="{\
\"auth\":$AUTHCONFIG\
}"

# Handle old or new config file based on simple flag
if [[ ${IS_SIMPLE} ]];
then
    echo "# Getting Amplify CLI Cloud-Formation stack info from environment cache"
    export STACKINFO="$(envCache --get stackInfo)"
    init_env ${ENV} ${AMPLIFY} ${PROVIDERS} ${CODEGEN} ${AWSCONFIG} ${CATEGORIES}
    echo "# Store Amplify CLI Cloud-Formation stack info in environment cache"
    STACKINFO="$(amplify env get --json --name ${ENV})"
    envCache --set stackInfo ${STACKINFO}
    echo "STACKINFO="${STACKINFO}
else
    # old config file, above steps performed outside of this script
    init_env ${ENV} ${AMPLIFY} ${PROVIDERS} ${CODEGEN} ${AWSCONFIG} ${CATEGORIES}
fi

Edit Build setting in amplify console

version: 0.1
backend:
  phases:
    build:
      commands:
        - '# Execute Amplify CLI with the helper script'
        - chmod u+x ./myamplifypush.sh
        - ./myamplifypush.sh
frontend:
  phases:
    preBuild:
      commands:
        - npm ci
    build:
      commands:
        - npm run build
  artifacts:
    baseDirectory: build
    files:
      - '**/*'
  cache:
    paths:
      - node_modules/**/*

Redeploy the app

This worked on my app. If you could not reproduce it, please let me know.

I'm having similar issues, or at least they appear to be closely related. I posted details here https://github.com/aws-amplify/amplify-cli/issues/2833

Yep, looks exactly the same as my experience.

@KidSysco what are you doing in the meantime? Are you just deploying via amplify push && amplify publish locally in the cli?

Pushing locally worked fine, and all functions worked fine locally. So I could develop locally but I just couldn't get it to production.
I decided to give amplify publish a try by setting up the publishing options in Amplify that would post the website to an S3 bucket, instead of using the Amplify Console.
However, amplify publish to S3 did not work for me either.
Same error.
I think what Joycehao19 said above is correct...
"The amplifyPush script has an issue with new stack creation when using social federation."
Official AWS Support just sent me to GitHub for Amplify support, but I was already here.
So I froze the idea there and moved on to write classic Restify services on an EC2 linux instance.
I think you could try to remove all social media functions and try it. I want to say I tried that and it did not work either, but based on what Joyce said above, it might work. I can't remember from a month ago. I also don't have any more time to sink into testing this for AWS. I already have a job, and a boss, and many deadlines of my own. lol
However, I am keeping on eye on Amplify and this issue. I will still comment and help out the community if I can.
I absolutely love the idea of Amplify, they need to keep pushing... But if you really need to go serverless, the best option right now is Azure. AWS is very new to writing dev tools, MS has been doing this since the dawn of time. The MS tools are very slick, from ORM (Entity Framework), to Web Server, source control, to multiple environments of Cloud resources. All one company. They are light years ahead in that game.
Fortunately for me, I do not NEED to go serverless right now, we are not huge fans of MS either. And we still get lots done on EC2, in record time.
Keep us posted if you make any break throughs!

Thanks for all of the info, the insight / experiences you've had are super helpful as I think through this stuff.
RE: try without social, in my case social sign in is actually the ONLY option that I want to support. My "app" is for a limited set of "internal" users (hint: it's actually my family :)), but I want to build something robust / secure as a way to learn a new set of tools (e.g. Amplify) for evaluation in future professional projects. In my case, I know my family members all have gmail accounts so I want them to just sign in with Google credentials and save worry about / thinking about anything else.
 Most important is AWS IoT, which I've spent a decent chunk of time implementing on physical hardware I'm making, so I'm pretty married to AWS at the moment.
I think for now I'll wait and watch this ticket and see what happens. I don't need to go to "production" at the moment, and truthfully I could live with only a single production environment if that solved my issue.

I understand completely.
As a Node.js programmer, the huge answer for social media SSO is passport.js.
However, I prefer Restify over Express, which has lead a pretty big divide in the Node community I'd say.
Passport.js is express based.
There are other services out there that are like Cognito, and we could use them too. I even have some training here from Udemy.com on getting AWS Developer certified. That class teaches new folks how to use Cognito directly using an older jQuery style of programming. It was not Vue, or React.
However, my instructor clearly indicated to his class that Amplify was not ready for production. I didn't believe him. I ended up here anyway because AWS makes amplify sound so awesome. I couldn't resist, even though I was warned by my instructor who was an Amplify Beta user.
I eventually decided that oAuth and social SSO logins are not really worth it on this platform yet.
Restify seems to have a real problem with JWT, and the AWS answer for something like that is just too much work to justify. There are easier ways to get social media SSO, but honestly, just writing my own login form seems to be much less work than all of this. Once I gave up on this, I started making huge gains in progress just writing it myself.
Now on Azure... OAuth was all super slick. This is why Amplify deserves a chance...
Years ago when I was on Azure, the default new project in Visual Studio for creating a new site, ships with oAuth stuff built in, all you need to do is fill in the keys and secrets into your code. No services needed, no passport.js, no express, OAuth just worked there. And that was back in 2015.
I know how it is supposed to work, because I have seen things like this elsewhere.
So it's just not worth fighting the platform. If it's not ready, then it's just not ready yet.
But DOn't get me wrong, I am still AWS 4 LYFE!!!! WOOT!!!!
So I agree, let's watch and see what happens next!

Confirming @Joycehao19 's workaround. This worked also on my end. Just did a little adjustment on the AUTH_CONFIG for social feds authentication. Created config variables per environment on the Environment variables tab and use it in my custom amplify push script myamplifypush.sh like below.

AUTHCONFIG="{
"googleAppIdUserPool":"${GOOGLE_CLIENT_ID}",
"googleAppSecretUserPool":"${GOOGLE_CLIENT_SECRET}",
"loginwithamazonAppIdUserPool":"${AMAZON_APP_ID}",
"loginwithamazonAppSecretUserPool":"${AMAZON_APP_SECRET}"
}"

Then push and redeploy environment(s). I have 3 environments as of the moment master, local, staging with different auth cognito each. Working fine now. Thanks!

@Joycehao19 's workaround seemed to work for me for the "Backend" phase of the build process which now passes, but now it hangs on the "Frontend" phase (which was working fine before I ended up in this mess) because it seams the file aws-exports.js is no longer generated. Any suggestions?

Facing Error: auth headless init is missing the following inputParams facebookAppIdUserPool, facebookAppSecretUserPool, googleAppIdUserPool, googleAppSecretUserPool as well.
Unfortunately, the workaround did not help us :(

Based on the comment, the following script worked for me
#!/usr/bin/env bash
set -e
IFS='|'
help_output () {
    echo "usage: amplify-push <--environment|-e <name>> <--simple|-s>"
    echo "  --environment  The name of the Amplify environment to use"
    echo "  --simple  Optional simple flag auto-includes stack info from env cache"
    exit 1
}

init_env () {
    ENV=$1
    AMPLIFY=$2
    PROVIDERS=$3
    CODEGEN=$4
    AWSCONFIG=$5
    CATEGORIES=$6
    echo "# Start initializing Amplify environment: ${ENV}"
    if [[ -z ${STACKINFO} ]];
    then
        echo "# Initializing new Amplify environment: ${ENV} (amplify init)"
        amplify init --amplify ${AMPLIFY} --providers ${PROVIDERS} --codegen ${CODEGEN} --categories ${CATEGORIES} --yes;
        echo "# Environment ${ENV} details:"
        amplify env get --name ${ENV}
    else
        echo "STACKINFO="${STACKINFO}
        echo "# Importing Amplify environment: ${ENV} (amplify env import)"
        amplify env import --name ${ENV} --config "${STACKINFO}" --awsInfo ${AWSCONFIG} --categories ${CATEGORIES} --yes;
        echo "# Initializing existing Amplify environment: ${ENV} (amplify init)"
        amplify init --amplify ${AMPLIFY} --providers ${PROVIDERS} --codegen ${CODEGEN} --categories ${CATEGORIES} --yes;
        echo "# Environment ${ENV} details:"
        amplify env get --name ${ENV}
    fi
    echo "# Done initializing Amplify environment: ${ENV}"
}

ENV=""
IS_SIMPLE=false
POSITIONAL=()
while [[ $# -gt 0 ]]
do
    key="$1"
    case ${key} in
        -e|--environment)
            ENV=$2
            shift
            ;;
        -r|--region)
            REGION=$2
            shift
            ;;
        -s|--simple)
            IS_SIMPLE=true
            shift
            ;;
        *)
            POSITIONAL+=("$1")
            shift
            ;;
    esac
done

set -- "${POSITIONAL[@]}"

# if no provided environment name, use default env variable, then user override
if [[ ${ENV} = "" ]];
then
    ENV=${AWS_BRANCH}
fi
if [[ ${USER_BRANCH} != "" ]];
then
    ENV=${USER_BRANCH}
fi

# Check valid environment name
if [[ -z ${ENV} || "${ENV}" =~ [^a-zA-Z0-9\-]+ ]] ; then help_output ; fi

AWSCONFIG="{\
\"configLevel\":\"project\",\
\"useProfile\":true,\
\"profileName\":\"default\"\
}"

AMPLIFY="{\
\"envName\":\"${ENV}\"\
}"

PROVIDERS="{\
\"awscloudformation\":${AWSCONFIG}\
}"

CODEGEN="{\
\"generateCode\":false,\
\"generateDocs\":false\
}"

AUTHCONFIG="{\
\"facebookAppIdUserPool\":\"XXXXXXXXXXXXXX\",\
\"facebookAppSecretUserPool\":\"XXXXXXXXXXXXXX\"\
}"

CATEGORIES="{\
\"auth\":$AUTHCONFIG\
}"

# Handle old or new config file based on simple flag
if [[ ${IS_SIMPLE} ]];
then
    echo "# Getting Amplify CLI Cloud-Formation stack info from environment cache"
    export STACKINFO="$(envCache --get stackInfo)"
    init_env ${ENV} ${AMPLIFY} ${PROVIDERS} ${CODEGEN} ${AWSCONFIG} ${CATEGORIES}
    echo "# Store Amplify CLI Cloud-Formation stack info in environment cache"
    STACKINFO="$(amplify env get --json --name ${ENV})"
    envCache --set stackInfo ${STACKINFO}
    echo "STACKINFO="${STACKINFO}
else
    # old config file, above steps performed outside of this script
    init_env ${ENV} ${AMPLIFY} ${PROVIDERS} ${CODEGEN} ${AWSCONFIG} ${CATEGORIES}
fi

I face this problem and solve it.
1- Create amplfypush.sh file and add it to the root of project and put the following scripts in it:

#!/usr/bin/env bash
set -e
IFS='|'
help_output () {
    echo "usage: amplify-push <--environment|-e <name>> <--simple|-s>"
    echo "  --environment  The name of the Amplify environment to use"
    echo "  --simple  Optional simple flag auto-includes stack info from env cache"
    exit 1
}

init_env () {
    ENV=$1
    AMPLIFY=$2
    PROVIDERS=$3
    CODEGEN=$4
    AWSCONFIG=$5
    CATEGORIES=$6
    echo "# Start initializing Amplify environment: ${ENV}"
    if [[ -z ${STACKINFO} ]];
    then
        echo "# Initializing new Amplify environment: ${ENV} (amplify init)"
        amplify init --amplify ${AMPLIFY} --providers ${PROVIDERS} --codegen ${CODEGEN} --categories ${CATEGORIES} --yes;
        echo "# Environment ${ENV} details:"
        amplify env get --name ${ENV}
    else
        echo "STACKINFO="${STACKINFO}
        echo "# Importing Amplify environment: ${ENV} (amplify env import)"
        amplify env import --name ${ENV} --config "${STACKINFO}" --awsInfo ${AWSCONFIG} --categories ${CATEGORIES} --yes;
        echo "# Initializing existing Amplify environment: ${ENV} (amplify init)"
        amplify init --amplify ${AMPLIFY} --providers ${PROVIDERS} --codegen ${CODEGEN} --categories ${CATEGORIES} --yes;
        echo "# Environment ${ENV} details:"
        amplify env get --name ${ENV}
    fi
    echo "# Done initializing Amplify environment: ${ENV}"
}

ENV=""
IS_SIMPLE=false
POSITIONAL=()
while [[ $# -gt 0 ]]
do
    key="$1"
    case ${key} in
        -e|--environment)
            ENV=$2
            shift
            ;;
        -r|--region)
            REGION=$2
            shift
            ;;
        -s|--simple)
            IS_SIMPLE=true
            shift
            ;;
        *)
            POSITIONAL+=("$1")
            shift
            ;;
    esac
done

set -- "${POSITIONAL[@]}"

# if no provided environment name, use default env variable, then user override
if [[ ${ENV} = "" ]];
then
    ENV=${AWS_BRANCH}
fi
if [[ ${USER_BRANCH} != "" ]];
then
    ENV=${USER_BRANCH}
fi

# Check valid environment name
if [[ -z ${ENV} || "${ENV}" =~ [^a-zA-Z0-9\-]+ ]] ; then help_output ; fi

AWSCONFIG="{\
\"configLevel\":\"project\",\
\"useProfile\":true,\
\"profileName\":\"default\"\
}"

AMPLIFY="{\
\"envName\":\"${ENV}\"\
}"

PROVIDERS="{\
\"awscloudformation\":${AWSCONFIG}\
}"

CODEGEN="{\
\"generateCode\":false,\
\"generateDocs\":false\
}"

AUTHCONFIG="{\
\"facebookAppId\":\"${FACEBOOK_CLIENT_ID}\",\
\"facebookAppSecret\":\"${FACEBOOK_CLIENT_SECRET}\",\
\"googleAppId\":\"${GOOGLE_CLIENT_ID}\",\
\"googleAppSecret\":\"${GOOGLE_CLIENT_SECRET}\"\
}"

CATEGORIES="{\
\"auth\":$AUTHCONFIG\
}"

# Handle old or new config file based on simple flag
if [[ ${IS_SIMPLE} ]];
then
    echo "# Getting Amplify CLI Cloud-Formation stack info from environment cache"
    export STACKINFO="$(envCache --get stackInfo)"
    init_env ${ENV} ${AMPLIFY} ${PROVIDERS} ${CODEGEN} ${AWSCONFIG} ${CATEGORIES}
    echo "# Store Amplify CLI Cloud-Formation stack info in environment cache"
    STACKINFO="$(amplify env get --json --name ${ENV})"
    envCache --set stackInfo ${STACKINFO}
    echo "STACKINFO="${STACKINFO}
else
    # old config file, above steps performed outside of this script
    init_env ${ENV} ${AMPLIFY} ${PROVIDERS} ${CODEGEN} ${AWSCONFIG} ${CATEGORIES}
fi

2- In amplify console  --> App Settings ----> Environment variables add  FACEBOOK_CLIENT_ID, FACEBOOK_CLIENT_SECRET, GOOGLE_CLIENT_ID, GOOGLE_CLIENT_SECRET to the environment varibale and set values for each environment
3- Change console  --> App Settings ---->Build Setting to
version: 0.1
backend:
  phases:
    build:
      commands:
        - '# Execute Amplify CLI with the helper script'
        - chmod u+x ./vertrun-amplifypush.sh
        - ./amplfypush.sh
frontend:
  phases:
    preBuild:
      commands:
        - yarn install
    build:
      commands:
        - yarn run build
  artifacts:
    baseDirectory: build
    files:
      - '**/*'
  cache:
    paths:
      - node_modules/**/*

I'm getting the following message:
[hostedUIProviderCreds] must have values
I don't have a frontend setup in the amplify console, i don't use the hosted UI at all.
I'm using Auth, Api and Storage services. I just want to add some fields in my schema and i'm stack with this error...
This the only issue that i found related to my error message. can someone help?

I'm getting the following message:
[hostedUIProviderCreds] must have values
I don't have a frontend setup in the amplify console, i don't use the hosted UI at all.
I'm using Auth, Api and Storage services. I just want to add some fields in my schema and i'm stuck with this error...
This is the only issue that i found related to my error message. can someone help?

I have the same issue @ohadts

@zahydo Nobody is answering here 😒
Did you manage to found any workaround?

Hi, I don't know if this is acceptable for you, but I had the same problem, and after failing in applying the workaround I came up with a different one: simply I do not manage social single sign ons with amplify (chose no at don't know which question), and I simply added them manually in the cognito console (I have 2 environments, I did it twice off course). It works and neither amplify push nor a console build removes the configuration.

That was not acceptable to me, why use Amplify at all then? I can go to the console and add Cognito myself too.
The point behind Amplify is that we are finally getting Infrastructure as Code at AWS.
Cognito and all of its configuration should be stored in source control, otherwise things will get missed when trying to replicate it later. This is what Infrastructure as Code does.
Right now, at my company, we cannot rebuild several of our old servers because no one knows how to. There are no docs, and the folks who put it together took years to get it done and none of them work here anymore.
This is what Amplify promises to resolve using all of the standard best practices that Amazon uses on their own websites.

@zahydo Nobody is answering here 😒
Did you manage to found any workaround?

No, I had to recreate my API. It seems to Amplify that don't work well adding or removing fields related to the @key directive. Please contact me if you find another way to solve that problem. Thanks.

@zahydo Nobody is answering here 😒
Did you manage to found any workaround?

@ohadts No, I had to recreate my API. It seems to Amplify that don't work well adding or removing fields related to the @key directive. Please contact me if you find another way to solve that problem. Thanks.

@zahydo @KidSysco we are working on a fix that will allow you to provide an environment variable with your Facebook/Google Client ID, and we will be able to create new environments without the build failure. We should have the fix out in the next few weeks.

We simply did a an amplify pull --appId XXXXXXXX  --envName dev command on another computer . Modified some graphql schema.
On amplify push  it gives the error :  Parameters: [hostedUIProviderCreds] must have values
Please help. We are really struck because of this  .

@KidSysco Totaly agree.
@zahydo Did you lost all of your data? I'm not trying to add or modified fields related to the @key directive, just plain primitive field...
@slatemates It happened to me on a machine that I did "amplify pull..." like you dud, but then I went back to my original machine (the one that I started the amplify project on) and got the same results.

@ohadts On the original machine it  still works fine. Since I had to work on the new machine, I made a tar ball of the original amplify folder , copy /pasted on the new machine. Its a lame workaround, but it works !

Hi! When you create a new back-end environment on Amplify Console, you could add your auth parameters in environment variables area now without creating your own amplifypush.sh.
The way to do it:

When you connect your branch, in Backend deployments, choose Create new environment, and enter your backend name.

In the key and value fields, enter your client id and client secret. Amplify Console supports configuring Facebook, Google and Amazon account.

Variable name
Description
Example

AMPLIFY_AMAZON_CLIENT_ID
The Amazon client Id
123456

AMPLIFY_AMAZON_CLIENT_SECRET
The Amazon client secret
example123456

AMPLIFY_FACEBOOK_CLIENT_ID
The Facebook client Id
123456

AMPLIFY_FACEBOOK_CLIENT_SECRET
The Facebook client secret
example123456

AMPLIFY_GOOGLE_CLIENT_ID
The Google client Id
123456

AMPLIFY_GOOGLE_CLIENT_SECRET
The Google client secret
example123456

@Joycehao19 please advise how to migrate the customer amplifypush.sh solution (existing backend) to the proper solution.
Thank you!

If you created a back-end via cli and deployed on the console, it would not be affected. If it does, please let us know.

@ohadts I lost my data. But, for the moment that is not a problem because I'm working in development. But the same error happens to me with I did push my amplify backend changes in the 'test' environment. I did add some features like lambdas and auth to the 'dev' environment without problems. But when I want to push the same features in the 'test' environment the Amplify Cli raise the same error:
Parameters: [hostedUIProviderCreds] must have values

@KidSysco The amplifyPush script has an issue with new stack creation when using social federation. As a workaround you could try:

Create your own amplifypush.sh like myamplifypush.sh in root folder amplify-auth-app/myamplifypush.sh
Add your authconfigs to the bash script

#!/usr/bin/env bash
set -e
IFS='|'
help_output () {
    echo "usage: amplify-push <--environment|-e <name>> <--simple|-s>"
    echo "  --environment  The name of the Amplify environment to use"
    echo "  --simple  Optional simple flag auto-includes stack info from env cache"
    exit 1
}

init_env () {
    ENV=$1
    AMPLIFY=$2
    PROVIDERS=$3
    CODEGEN=$4
    AWSCONFIG=$5
    CATEGORIES=$6
    echo "# Start initializing Amplify environment: ${ENV}"
    if [[ -z ${STACKINFO} ]];
    then
        echo "# Initializing new Amplify environment: ${ENV} (amplify init)"
        amplify init --amplify ${AMPLIFY} --providers ${PROVIDERS} --codegen ${CODEGEN} --categories ${CATEGORIES} --yes;
        echo "# Environment ${ENV} details:"
        amplify env get --name ${ENV}
    else
        echo "STACKINFO="${STACKINFO}
        echo "# Importing Amplify environment: ${ENV} (amplify env import)"
        amplify env import --name ${ENV} --config "${STACKINFO}" --awsInfo ${AWSCONFIG} --categories ${CATEGORIES} --yes;
        echo "# Initializing existing Amplify environment: ${ENV} (amplify init)"
        amplify init --amplify ${AMPLIFY} --providers ${PROVIDERS} --codegen ${CODEGEN} --yes;
        echo "# Environment ${ENV} details:"
        amplify env get --name ${ENV}
    fi
    echo "# Done initializing Amplify environment: ${ENV}"
}

ENV=""
IS_SIMPLE=false
POSITIONAL=()
while [[ $# -gt 0 ]]
do
    key="$1"
    case ${key} in
        -e|--environment)
            ENV=$2
            shift
            ;;
        -r|--region)
            REGION=$2
            shift
            ;;
        -s|--simple)
            IS_SIMPLE=true
            shift
            ;;
        *)
            POSITIONAL+=("$1")
            shift
            ;;
    esac
done

set -- "${POSITIONAL[@]}"

# if no provided environment name, use default env variable, then user override
if [[ ${ENV} = "" ]];
then
    ENV=${AWS_BRANCH}
fi
if [[ ${USER_BRANCH} != "" ]];
then
    ENV=${USER_BRANCH}
fi

# Check valid environment name
if [[ -z ${ENV} || "${ENV}" =~ [^a-zA-Z0-9\-]+ ]] ; then help_output ; fi

AWSCONFIG="{\
\"configLevel\":\"project\",\
\"useProfile\":true,\
\"profileName\":\"default\"\
}"

AMPLIFY="{\
\"envName\":\"${ENV}\"\
}"

PROVIDERS="{\
\"awscloudformation\":${AWSCONFIG}\
}"

CODEGEN="{\
\"generateCode\":false,\
\"generateDocs\":false\
}"

AUTHCONFIG="{\
\"facebookAppIdUserPool\":\"888888888888888\",\
\"facebookAppSecretUserPool\":\"88888888888888888\"\
}"

CATEGORIES="{\
\"auth\":$AUTHCONFIG\
}"

# Handle old or new config file based on simple flag
if [[ ${IS_SIMPLE} ]];
then
    echo "# Getting Amplify CLI Cloud-Formation stack info from environment cache"
    export STACKINFO="$(envCache --get stackInfo)"
    init_env ${ENV} ${AMPLIFY} ${PROVIDERS} ${CODEGEN} ${AWSCONFIG} ${CATEGORIES}
    echo "# Store Amplify CLI Cloud-Formation stack info in environment cache"
    STACKINFO="$(amplify env get --json --name ${ENV})"
    envCache --set stackInfo ${STACKINFO}
    echo "STACKINFO="${STACKINFO}
else
    # old config file, above steps performed outside of this script
    init_env ${ENV} ${AMPLIFY} ${PROVIDERS} ${CODEGEN} ${AWSCONFIG} ${CATEGORIES}
fi

Edit Build setting in amplify console

version: 0.1
backend:
  phases:
    build:
      commands:
        - '# Execute Amplify CLI with the helper script'
        - chmod u+x ./myamplifypush.sh
        - ./myamplifypush.sh
frontend:
  phases:
    preBuild:
      commands:
        - npm ci
    build:
      commands:
        - npm run build
  artifacts:
    baseDirectory: build
    files:
      - '**/*'
  cache:
    paths:
      - node_modules/**/*

Redeploy the app

This worked on my app. If you could not reproduce it, please let me know.

I still receive the same error when using the script

Error: auth headless init is missing the following inputParams facebookAppIdUserPool, facebookAppSecretUserPool, googleAppIdUserPool, googleAppSecretUserPool
at updateConfigOnEnvInit (/root/.nvm/versions/node/v10.16.0/lib/node_modules/@aws-amplify/cli/node_modules/amplify-category-auth/provider-utils/awscloudformation/index.js:369:15)
at /root/.nvm/versions/node/v10.16.0/lib/node_modules/@aws-amplify/cli/node_modules/amplify-category-auth/index.js:234:28
at /root/.nvm/versions/node/v10.16.0/lib/node_modules/@aws-amplify/cli/node_modules/promise-sequential/index.js:16:18
at process._tickCallback (internal/process/next_tick.js:68:7)

Well, actually, it works the first build then fails for all subsequent one for reasons unknown.

@xitanggg I truly apologize for the inconvenience, and our team is actively working on fixes of build failures now. Thanks for being an Amplify Console user and giving the conductive feedback. In order to better assist you, and improve our ongoing feature offering, I hope you could kindly share your appId and region to us (App settings => General => App ARN => arn:aws:amplify:${Region}:xxxxxxx:apps/${appId}).
Thank you.

@Joycehao19 Thanks for getting back promptly.
Here is my App ARN
arn:aws:amplify:us-east-1:xxxxxxx:apps/d2tcc56dy4swxp
Build 4 is the only time it works when I introduce the myamplifypush.sh with
AUTHCONFIG="{\
\"facebookAppId\":\"xxxxx\",\
\"googleClientId\":\"xxxxxx.apps.googleusercontent.com\",\
\"facebookAppIdUserPool\":\"xxxxx\",\
\"facebookAppSecretUserPool\":\"xxxxx\",\
\"googleAppIdUserPool\":\"xxxxx.apps.googleusercontent.com\",\
\"googleAppSecretUserPool\":\"xxxxx\"\
}"

, then it starts failing at Build 5 (which I only changed my front end react code and updated a function) to Build 18 with no luck fixing it.
No rush on this, since I am not using amplify console.

@xitanggg @yuyokk @KidSysco @kevin-mitchell @paulbartocillo We have a solution posted here.
To get it working, revert your backend build settings to use the amplifyPush --simple script, add the env variables, and any new environment created through the Console will work.

Hi.  I'm here, because I setup a project with Amplify CLI, using Auth, which includes federatedSignIn.
I did this with an an initial environment, dev.
In the past, when ready to deploy to production (or staging), I'd (in the Amplify Console) connect a repo, and create a new env, prod, from the master branch.
From what I see happening, is that the build is choking on the fact that there is no OAuth client ID or secret present.  This is mostly likely because, I have intentionally excluded amplify/team-provider-info.json from the repo, because the fact that it contains the secret keys.
This seems to be of a chicken and egg scenario.
At this point, I can't deploy.
I've tried adding the client ID and secret key as environment variables, but that changes the build error to:  missing the following inputParams googleAppIdUserPool, googleAppSecretUserPool
There is also an error in the console, which I believe to be a red herring:
missing the following inputParams googleAppIdUserPool, googleAppSecretUserPool

Yes, you are at the right place. We tend to see that issue a lot...

At this point, I can't deploy.

So I might suggest to AWS...
Come up with some way to manually deploy this stuff. Then when it breaks, we can at least follow some manual steps to deployment, like copying files to S3 or EC2 ourselves.
After seeing this error from so many people now, I think back and wonder if I would have stuck with Amplify for my project, if I could have just deployed.
Amplify doesn't need to work perfect, but where I work, we need to deploy. Anything less is absolutely unacceptable, under any circumstance. So we had to drop Amplify from the tech stack when that is not something we wanted to do at all.

And just to rub salt in the wound, my prod environment shows in the console only.  It does not show, if I look in User Pools.  If I want to delete it in the console, I see this:

When I try to check out prod via the CLI, is says:
Please pass in a valid environment name. Run amplify env list to get a list of valid environments

@kimfucious did you check out this post? https://github.com/aws-amplify/amplify-console/issues/206#issuecomment-611036436

@KidSysco sorry to hear that. Would you be open to getting on a call so we can better understand what you went through? Absolutely agree that not being able to deploy is unacceptable.

@swaminator Sure I would be willing to have a chat with you.I have AWS Support through my company, and I already went through them. They just pointed me here, so I suppose talking to you is the next step. How do I go about doing that?

Has this been resolved yet and documented, or is the current "fix" still
customizing the deployment script? I'm havinga slightly difficult time
keeping track with all of the discussion here. Thank you!
On Mon, Apr 13, 2020, 8:21 PM Ryan Segura<EMAIL_ADDRESS>wrote:

@swaminator https://github.com/swaminator Sure I would be willing to
have a chat with you.I have AWS Support through my company, and I already
went through them. They just pointed me here, so I suppose talking to you
is the next step. How do I go about doing that?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aws-amplify/amplify-console/issues/206#issuecomment-613052669,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFCJCPDSAMBIE7N74EPEJWDRMNQ4NANCNFSM4JDRK43A
.

@kevin-mitchell refer to this post: https://github.com/aws-amplify/amplify-console/issues/206#issuecomment-611036436

@KidSysco send me an email via<EMAIL_ADDRESS>and I'll set up time with you.

@kimfucious did you check out this post? #206 (comment)

Hi @swaminator thanks for the reply.
I did try following those instructions in #206, but to no avail.  I got frustrated after a few flailing attempts.  Again, I was stuck with a bad "prod" backend in the console that I could not deploy to or get rid and that the CLI could not checkout or pull.
This came about by:

amplify init (env "dev")
amplify auth add (with Federation sign in)
'amplify push`
In Amplify Console, add front end by connecting repo

Ultimately, I resorted to the following:

Deleting the app in the Amplify Console
Doing a Connect App from All Apps
Choose repo and branch
I believe this prevents the build from crashing ==> Select Advanced Settings on Step 2 (Configure Build Settings) and populate the environment variables as described here

So, now I've got the app running in CloudFront, but there's another problem:
Federated signins in "prod" are making auth requests with the redirect_uri that is configured in the "dev" user pool (e.g. https://localhost:3000) and not in the "prod" user pool (e.g. https://mysite.com).
Request URL: https://mysite12345678-12345678-prod.auth.us-west-2.amazoncognito.com/oauth2/authorize?redirect_uri=https%3A%2F%2Flocalhost%3A3000%2Fauth-callback%2F&response_type=code&client_id=[truncated]...

I've checked the cloudformation and can verify the below in the template of the associated prod stack:
"hostedUIProviderMeta": "[{\"ProviderName\":\"Google\",\"authorize_scopes\":\"openid email profile\",\"AttributeMapping\":{\"email\":\"email\",\"username\":\"sub\"}}]",
					"oAuthMetadata": "{\"AllowedOAuthFlows\":[\"code\"],\"AllowedOAuthScopes\":[\"phone\",\"email\",\"openid\",\"profile\",\"aws.cognito.signin.user.admin\"],\"CallbackURLs\":[\"https://localhost:3000/auth-callback/\"],\"LogoutURLs\":[\"https://localhost:3000/\"]}",
					"userPoolGroupList": "",
					"parentStack": {
						"Ref": "AWS::StackId"
					},

This made me go, "Hmm..." So I made a small change to the app code and git pushed to the repo, triggering a new build/deploy.
The build fails with:
2020-04-14T04:43:47.123Z [INFO]: UPDATE_FAILED               mysite12345678        AWS::CloudFormation::Stack Tue Apr 14 2020 04:43:42 GMT+0000 (Coordinated Universal Time) Parameters: [hostedUIProviderCreds] must have values

At this point, I'm at a loss as to how to proceed.  Got milk?  🍼

I decided to come at this from another angle.

Delete the app from the console.
Delete all stacks related to prod
Delete lingering S3 buckets
On my local dev machine run (where I already have a dev env), run `amplify env add:

$ amplify env add
Note: It is recommended to run this command from the root of your app directory
? Do you want to use an existing environment? No
? Enter a name for the environment prod
Using default provider  awscloudformation

For more information on AWS Profiles, see:
https://docs.aws.amazon.com/cli/latest/userguide/cli-multiple-profiles.html

? Do you want to use an AWS profile? Yes
? Please choose the profile you want to use default
Adding backend environment prod to AWS Amplify Console app: d26662v54hhx2s
⠴ Initializing project in the cloud...
... lots of stuff happens.  Good stuff with no errors...
 Enter your Google Web Client ID for your OAuth flow:  [id goes here]
 Enter your Google Web Client Secret for your OAuth flow:  [secret goes here]
Initialized your environment successfully.
Your project has been successfully initialized and connected to the cloud!

amplify push
In amplify console, the app is there with no front end (correct), and it's got "prod" for backend (correct)
Connect a front end web app / connect branch
Select repo/branch
Selected existing backend environment, prod
Nothing else.  Save and deploy

🥁 🥁 🥁
💣 Fail:  Parameters: [hostedUIProviderCreds] must have values

11:  Add env variables and update build settings to use custom myAmplifyPush.sh
12.  Go to failed build.  Click Redeploy this version.
🥁 🥁 🥁
💣 Fail:  Error: auth headless init is missing the following inputParams googleAppIdUserPool, googleAppSecretUserPool

I'm pretty much done with things to try.

@kimfucious did you check out this post? #206 (comment)

Thanks for the follow up, @swaminator
Here's where I'm at:
Started from a clean slate.  Brand new app just to test this:

Ran amplify init on my local, creating "dev"
Ran amplify auth add

$ amplify auth add
Using service: Cognito, provided by: awscloudformation

 The current configured provider is Amazon Cognito.

 Do you want to use the default authentication and security configuration? Default configuration with Social Provider (Federation)
 Warning: you will not be able to edit these selections.
 How do you want users to be able to sign in? Username
 Do you want to configure advanced settings? Yes, I want to make some additional changes.
 Warning: you will not be able to edit these selections.
 What attributes are required for signing up? Email
 Do you want to enable any of the following capabilities?
 What domain name prefix you want us to create for you? authentify7adc49c2-7adc49c2
 Enter your redirect signin URI: https://localhost:3000/auth-callback/
? Do you want to add another redirect signin URI No
 Enter your redirect signout URI: https://localhost:3000/
? Do you want to add another redirect signout URI No
 Select the social providers you want to configure for your user pool: Google

 You've opted to allow users to authenticate via Google.  If you haven't already, you'll need to go to https://developers.google.com/identity and create an App ID.

 Enter your Google Web Client ID for your OAuth flow:  <id goes here>
 Enter your Google Web Client Secret for your OAuth flow:  <key goes here>
Successfully added resource authentify7adc49c2 locally

amplify push
git push to repo
In Amplify console, new app appears with "dev" back-end configured,
Click Connect a frontend web app
Click Connect branch
Enter repo and branch (master)
Create new environment (prod)
Choose existing service role (amplifyconsole-backend-role)

Something odd here.  Maybe I'm going senile, but I remember there being and "advanced" accordion/collapse menu on the Configure build settings page.  This is now gone.  This is where I would put in the environment vars:  AMPLIFY_GOOGLE_CLIENT_ID & AMPLIFY_GOOGLE_CLIENT_SECRET, before the build, but now that's not possible.

Only option, click Next
Click Save and deploy

This fails with (excerpt from build log):
2020-04-14T10:39:31.512Z [WARNING]: ✖ There was an error initializing your environment.
2020-04-14T10:39:31.512Z [INFO]: init failed
2020-04-14T10:39:31.513Z [INFO]: Error: auth headless init is missing the following inputParams googleAppIdUserPool, googleAppSecretUserPool

Click Environment variables in left menu.
Add aforementioned env vars
Navigate to the failed build and click Redeploy this version.

This fails with the same error as above.

Make a change in the app code and git push to the repo, kicking off a new build.

This give the following error in Amplify Console:

I believe this is a red herring because a git status says:
$ git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

So I just waited.  After a while, I came back and refreshed the page, and see this error (same as before):
2020-04-14T10:54:35.721Z [WARNING]: - Initializing your environment: prod
2020-04-14T10:54:35.863Z [WARNING]: ✔ Initialized provider successfully.
2020-04-14T10:54:35.870Z [WARNING]: ✖ There was an error initializing your environment.
2020-04-14T10:54:35.871Z [INFO]: init failed
2020-04-14T10:54:35.871Z [INFO]: Error: auth headless init is missing the following inputParams googleAppIdUserPool, googleAppSecretUserPool

Just to be thorough, I went and reconnected the repository, clearing out the existing hook prior, kicking off another build.
The Cloning repository phase reports:
2020-04-14T11:04:41.195Z [INFO]: Note: checking out '3e9e8fb41abb0d6461672088879fe64966621f68'.
                                 You are in 'detached HEAD' state. You can look around, make experimental
                                 changes and commit them, and you can discard any commits you make in this
                                 state without impacting any branches by performing another checkout.
                                 If you want to create a new branch to retain commits you create, you may
                                 do so (now or later) by using -b with the checkout command again. Example:
                                 git checkout -b <new-branch-name>
                                 HEAD is now at 3e9e8fb docs: revert fake edit

Which is probably why the There was an issue connecting to your repo provider error is showing up, which it did again.
And 🥁 🥁 🥁 💣
The build fails again with the same headless init error as mentioned above.
I hope that's enough info for you.  If not, let me know.
This process has worked flawlessly for me on numerous non-federatedSignIn projects prior.  I'm really surprised that this is "new" issue.

I got it working on my end. I guess it only happens upon pulling auth settings to new project
$ amplify pull --appId yourID --envName yourENV
Just copy the team-provider-info.json from your original setup and paste to other setup. And amplify push
here's my team-provider-info.json
{
  "prod": {
    "awscloudformation": {
      "AuthRoleName": "amplify-bulokTae-prod-69696969-authRole",
      "UnauthRoleArn": "arn:aws:iam::98237982374937:role/amplify-bulokTae-prod-69696969-unauthRole",
      "AuthRoleArn": "arn:aws:iam::98237982374937:role/amplify-bulokTae-prod-69696969-authRole",
      "Region": "ap-southeast-1",
      "DeploymentBucketName": "amplify-bulokTae-prod-69696969-deployment",
      "UnauthRoleName": "amplify-bulokTae-prod-69696969-unauthRole",
      "StackName": "amplify-bulokTae-prod-69696969",
      "StackId": "arn:aws:cloudformation:ap-southeast-1:98237982374937:stack/amplify-bulokTae-prod-69696969/be7691a0-7f0f-11ea-8531-0a58c7c408be",
      "AmplifyAppId": "d3ldsjafaasddd"
    },
    "categories": {
      "auth": {
        "bulokTae77df9dab": {
          "hostedUIProviderCreds": "[{\"ProviderName\":\"Facebook\",\"client_id\":\"6969696969696\",\"client_secret\":\"0169696969669696\"}]"
        }
      }
    }
  }
}

@kimfucious thanks for the detailed post. We're investigating this now.

Thanks, @swaminator
It could very well that I'm doing something dumb, but I feel like I've tried everything you've recommended.  Do let me know if I can try something else and/or provide more detail.

We need the user pool environment variables as well. https://github.com/aws-amplify/amplify-console/issues/206#issuecomment-607499826
That will at least make new auth deployments usable for people on new amplify projects.

@kimfucious thanks for taking the time to post those details, it saved me from trying to start over from scratch. I have one (mainly unrelated if i were honest!) followup if you have time: you mentioned excluding amplify/team-provider-info.json from your project - I'm wondering if this is normal to do or if you had to work around this somehow?
This is likely dumb (or at least lazy?) question, but I'm not entirely clear which files are actually important for me to keep under source control vs which files should be .gitignored. I would have imagined that anything that wasn't needed would be added to gitignore by amplify CLI on project init, but maybe not?
@swaminator FYI in my case I have an existing project with a team-provider-info.json file that looks like this (I scrubbed secrets):
{
    "master": {
        "awscloudformation": {
            "AuthRoleName": "amplify-myproject-master-123456-authRole",
            "UnauthRoleArn": "arn:aws:iam::99999999999:role/amplify-myproject-master-123456-unauthRole",
            "AuthRoleArn": "arn:aws:iam::99999999999:role/amplify-myproject-master-123456-authRole",
            "Region": "us-west-2",
            "DeploymentBucketName": "amplify-myproject-master-123456-deployment",
            "UnauthRoleName": "amplify-myproject-master-123456-unauthRole",
            "StackName": "amplify-myproject-master-123456",
            "StackId": "arn:aws:cloudformation:us-west-2:99999999999:stack/amplify-myproject-master-123456/777777777-4444444-7777-4444-999999999",
            "AmplifyAppId": "scrubbbbbbbb999999"
        },
        "categories": {
            "function": {
                "myproject4545454PreSignup": {
                    "DOMAINWHITELIST": "blah.com",
                    "VALIDEMAILS"<EMAIL_ADDRESS>                },
                "myproject4545454PostAuthentication": {},
                "myproject4545454PreAuthentication": {},
                "configurations": {}
            },
            "auth": {
                "myproject4545454": {
                    "googleClientId": "XXXXX.apps.googleusercontent.com",
                    "hostedUIProviderCreds": "[{\"ProviderName\":\"Google\",\"client_id\":\"XXXX.apps.googleusercontent.com\",\"client_secret\":\"YYYYYYYYY\"}]"
                }
            }
        }
    }
}

but I've also added the configuration keys mentioned above:

But still the build fails (as others are mentioning):
2020-04-19T14:22:49.073Z [WARNING]: - Initializing your environment: master
2020-04-19T14:22:49.443Z [WARNING]: ✔ Initialized provider successfully.
2020-04-19T14:22:49.477Z [WARNING]: ✖ There was an error initializing your environment.
2020-04-19T14:22:49.477Z [INFO]: init failed
2020-04-19T14:22:49.479Z [INFO]: Error: auth headless init is missing the following inputParams googleAppIdUserPool, googleAppSecretUserPool
                                 at updateConfigOnEnvInit (/root/.nvm/versions/node/v10.16.0/lib/node_modules/@aws-amplify/cli/node_modules/amplify-category-auth/provider-utils/awscloudformation/index.js:369:15)

Are there additional steps I need to take?

Hi @kevin-mitchell
The reason, for me at least, to exclude the team-provider-info.json file from my repo is because my repo is public and, since I'm using federated sign in, not excluding it would expose the secret keys for my external auth providers (e.g. Amazon, Facebook, Google).
I believe that the team-provider-info.json is there to make it super easy for teams to work on a project, but, IMHO, it should only be used in a private repo, unless you're dang sure that you're not sharing the family jewels with the world.
At present, this is the only file that I manually exclude, deferring to the modifications that Amplify makes to .gitignore for the rest.
I should mention here again that I've excluded this file on several past Amplify projects where I was not using federated sign in, and the the process has worked well.  So my gut tells me this is something related to federated sign in, and the suggested workarounds thus far seem to indicate this as well.
That said, I don't yet have a working workaround yet, but I'm hopeful that the some fine person will come up with a solution if they get enough tacos 🌮 !

Hi @swaminator
Adding some possibly (un)related detail here.
I have another project (separate than the one that I used to provide detail with above) that has federated identify providers configured in the User Pool of the "dev" environment.  And it's been working.  I have not yet attempted to push the code changes to the repo to see what happens in the console.
Regardless, now a few weeks later, after adding a new backend function in dev (amplify function add) on my local and trying to push that via the CLI, I get the following error:
UPDATE_FAILED      authmyapp01234eb6               AWS::CloudFormation::Stack Mon Apr 20 2020 12:51:25 GMT-0700 (Narnia Time) Parameters:
[hostedUIProviderCreds] must have values

Again , this is trying amplify-push from the dev env on my local (no repo or amplify console involved).  And I'm fairly certain that I upgraded the Amplify CLI from to 4.18.0 between when the last push worked (with federated sign-in enabled) without errors.  I don't know what version of the cli I upgraded from.
I realize that this is a CLI related, but I thought it might help with your investigations.

Thanks for the response to my Q @kimfucious ! I had (wrongly it seems!) assumed it was required for the build pipeline on the Amplify side (for handling the automated backend deployments and such). I might purge it from my repo though, the fact that it contains secrets and is under source control is the reason I currently have my Amplify project private.
FWIW, in my situation I am only use Google sign in. So I believe it's correct to say that I AM using federated sign in (?).

Hi @kevin-mitchell I'm happy to help and trying to provide as much info here as possible toward a solution.
I had my hesitations about adding team-provider-info.json some time back and got an official reply here, that states:

The purpose of this file is basically sharing it within your team-members on the same project and want to update/use the same AWS Infrastructure tied to an environment. If you're open-sourcing your project you can totally get rid of this file (or make it a part of .gitignore).

So I've been running with that advice.
Regarding whether or not you're using federated sign in, I'd say, "yes," though I could be mixing terminology.  In short, when you setup auth with amplify add auth and choose Default configuration with Social Provider (Federation) or a manual equivalent, you're setting up the backend so that you can ultimately use Auth.federatedSignIn({ provider: "Google" }) on the front end.

Hello, I had a preexisting environment with auth. I then added federated signin with the cli amplify auth update. It all worked fine when deploying locally. Then when I went onto the console I ran into the error Parameters: [hostedUIProviderCreds] must have values. I then followed the instructions  in this comment. When trying to create a new test environment I got another error Error: auth headless init is missing the following inputParams facebookAppIdUserPool, facebookAppSecretUserPool, googleAppIdUserPool, googleAppSecretUserPool, loginwithamazonAppIdUserPool, loginwithamazonAppSecretUserPool so it looks as if the environment variables set aren't being mapped to these required inputs ? Any suggestion how to get this working.

@kevin-mitchell @magjack Make sure you add the environment variables before connecting the new branch. If you add it after, it won't currently work.
Just to reiterate the workflow (assuming you're starting from scratch).

Install the Amplify CLI. Setup env dev.
Run amplify add auth and setup social sign-in. Run amplify push
Commit changes to dev branch.
Connect dev branch in the Console and connect existing env dev.
Set environment variables mentioned as shown below

Variable name
Description
Example

AMPLIFY_AMAZON_CLIENT_ID
The Amazon client Id
123456

AMPLIFY_AMAZON_CLIENT_SECRET
The Amazon client secret
example123456

AMPLIFY_FACEBOOK_CLIENT_ID
The Facebook client Id
123456

AMPLIFY_FACEBOOK_CLIENT_SECRET
The Facebook client secret
example123456

AMPLIFY_GOOGLE_CLIENT_ID
The Google client Id
123456

AMPLIFY_GOOGLE_CLIENT_SECRET
The Google client secret
example123456

Connect master branch and pick create new environment. Name it prod.

Expected result: The Amplify Console will deploy a new backend env without the error you are facing in the build. In the Frontend Env tab you should see the master branch and in the backend env tab you should see two envs prod and dev.

Hi @swaminator, I know that the above was addressed to others, it got me thinking, as I usually never actually create a front-end for "dev".
I know I'm probably over-communicating here, but I really would like to find a solution for this soon.
What I usually do is:

create "dev" env on local
run amplify add auth
run amplify push
exclude team-provider-info.json in .gitignore
run git push origin master (having already configured a repo with git)
run git checkout -b develop
run git push origin develop

Note:  at this point, there is no way to add environment variables to the app in Amplify Console prior to actually adding a front-end

In the Amplify console, add front end in console, not using existing "dev" backend, but creating a new "staging" and/or "prod" backend

This has worked in the past for me many times, with non-federated/social sign in.
Here's a full from scratch task list:

run npx create-react-app amplify-issue-206-test
run amplify init

// yes, I'm using PowerShell on this one
PS D:\Users\Kim\Dev\Sites\workspace\amplify-issue-206-test> amplify init
Note: It is recommended to run this command from the root of your app directory
? Enter a name for the project amplifyissue206test
? Enter a name for the environment dev
? Choose your default editor: Visual Studio Code
? Choose the type of app that you're building javascript
Please tell us about your project
? What javascript framework are you using react
? Source Directory Path:  src
? Distribution Directory Path: build
? Build Command:  npm.cmd run-script build
? Start Command: npm.cmd run-script start
Using default provider  awscloudformation

For more information on AWS Profiles, see:
https://docs.aws.amazon.com/cli/latest/userguide/cli-multiple-profiles.html

? Do you want to use an AWS profile? Yes
? Please choose the profile you want to use default
Adding backend environment dev to AWS Amplify Console app: d3ubvyi61tdunc
| Initializing project in the cloud...

// lots of stuff happens without errors.

√ Successfully created initial AWS cloud resources for deployments.
√ Initialized provider successfully.
Initialized your environment successfully.

Your project has been successfully initialized and connected to the cloud!

run amplify auth add

PS D:\Users\Kim\Dev\Sites\workspace\amplify-issue-206-test> amplify auth add
Using service: Cognito, provided by: awscloudformation

 The current configured provider is Amazon Cognito.

 Do you want to use the default authentication and security configuration? Default configuration with Social Provider (Federation)
 Warning: you will not be able to edit these selections.
 How do you want users to be able to sign in? Username
 Do you want to configure advanced settings? Yes, I want to make some additional changes.
 Warning: you will not be able to edit these selections.
 What attributes are required for signing up? Email
 Do you want to enable any of the following capabilities?
 What domain name prefix you want us to create for you? amplifyissue206testd93055db-d93055db
 Enter your redirect signin URI: https://localhost:3000/auth-callback/
? Do you want to add another redirect signin URI No
 Enter your redirect signout URI: https://localhost:3000/
? Do you want to add another redirect signout URI No
 Select the social providers you want to configure for your user pool: Google

 You've opted to allow users to authenticate via Google.  If you haven't already, you'll need to go to https://developers.google.com/identity and create an App ID.

 Enter your Google Web Client ID for your OAuth flow:  <id goes here>
 Enter your Google Web Client Secret for your OAuth flow:  <key goes here>
Successfully added resource amplifyissue206testd93055db locally

run amplify push

PS D:\Users\Kim\Dev\Sites\workspace\amplify-issue-206-test> amplify push
√ Successfully pulled backend environment dev from the cloud.

Current Environment: dev

| Category | Resource name               | Operation | Provider plugin   |
| -------- | --------------------------- | --------- | ----------------- |
| Auth     | amplifyissue206testd93055db | Create    | awscloudformation |
? Are you sure you want to continue? Yes
/ Updating resources in the cloud. This may take a few minutes...
// lots of stuff happens without errors
√ All resources are updated in the cloud

run git push origin master
run git checkout -b develop
run git push origin develop
In the Amplify Console, click Connect a frontend web app, selecting Github

Note:  at this point, there is no way to add environment variables to the app in Amplify Console prior to actually adding a front-end

Click Connect branch
Select repo and branch "develop"
Click Next

I swear there used to be a way to add add environment variables here, below build and test settings, but it's gone now

In App build and test settings select "dev" as the backend env (this is different from what I normally do)
Select an existing service role (amplifyconsole-backend-role)
Click Next, then Save and deploy

This fails with:
2020-04-23T07:33:09.826Z [INFO]: UPDATE_FAILED authamplifyissue206testd93055db AWS::CloudFormation::Stack Thu Apr 23 2020 07:33:09 GMT+0000 (Coordinated Universal Time) Parameters: [hostedUIProviderCreds] must have values

Now I can add environment variables!  Add both AMPLIFY_GOOGLE_CLIENT_ID & AMPLIFY_GOOGLE_CLIENT_SECRET

Click General under App Settings

Select "develop" branch

Choose action "disable auto build" (if you don't do this, I don't think you can disconnect the branch)

Select "develop" branch again.

Chose action "disconnect branch"

Click Disconnect (confirmation message appears at top out of view and disappears after 3 secs)

Repeat from step 8 to 14 above (no changes), with environment variables now configured

This fails with:
2020-04-23T07:48:26.015Z [INFO]: UPDATE_FAILED               authamplifyissue206testd93055db        AWS::CloudFormation::Stack Thu Apr 23 2020 07:48:21 GMT+0000 (Coordinated Universal Time) Parameters: [hostedUIProviderCreds] must have values

Start entire process again, except this time do not exclude team-provider-info.json from the (private) repo.  And it works (which we already know)!

Again, no way to add env variables near step 8, but there is not need to if you have team-provider-info.json in the repo.  And, not to sound like a broken record, you don't want to put team-provider-info.json in a public repo when it has the secret keys of your auth providers.
So it appears that the lack of team-provider-info.json is what breaks this, and that the current proposed solution of adding environment values in the Amplify Console when connecting to repos without that file doesn't quite work yet.
I could very well just work from private repos, but the irony is that I discovered this issue when creating a project, Authentify, to document Federated sign-in, using Amplify.  It wouldn't be of much help to anyone in a private repo.
Hope this helps... 🌮 !

@kimfucious thank you for the detailed post. I'll work on investigation, and keep updating here.

I tried the instructions decribed  again with a new amplify console config but still see the same error. Will continue with using CLI to setup backend.

Thanks @Joycehao19.  While you're at it, here's more info for you.

I've got an existing app on Amplify that has a dev and prod backend.
It has a front end for prod (only), created by connecting the master branch of a public repo.
This project, to date, has had auth configured w/o federated sign-in.
I've added federated sign-in to the dev backend, and it works testing locally
Ultimately I want to get this working in prod
Until I'm comfortable with all this working swimmingly, I'm working in a staging branch, trying to get it successfully deployed by Amplify Console.
Once successful there, I plan to merge the changes to master and have that update prod.
To hopefully make things "easier," I've elected to make the repo private and add the team-provider-info.json file to the repo.

Here's my efforts with that:

Make public repo on existing project private.  This app already exists on Amplify
Remove exclusion for team-provider-info.json from .gitignore
Run git checkout -b staging
Run git push origin staging
Add env vars for auth providers for the app. This is possible, because this is an existing repo with an existing front end.
In Amplify Console / Front End, click Connect Branch
Select staging for branch / Create new environment
Click next
Click Save and deploy

The back-end gets created without errors.
The front-end fails (in the build log, the Amplify console shows the build still in progress) with cannot find ./aws-exports in ./src.
New bug?  Amplify CLI auto excludes this in .gitignore.  I've never included this file in a repo.
I let this hang for 10 minutes before cancelling the build.

Remove exclusion for aws-export.js from gitignore
Run git push origin staging
This triggers a new build

Back end fails with error:
2020-04-25T16:23:12.048Z [INFO]: Error: auth headless init is missing the following inputParams googleAppIdUserPool, googleAppSecretUserPool

Disconnect staging branch from Amplify Console
Delete the back-end:
a. Run amplify pull --appId xxxxxxxxxxxxx --envName staging on local

A lovely experience while doing this you get to watch almost everything in the amplify directory get deleted, because the staging back-end is in a failed/incomplete state.  This can give a person heart palpitations.
b. Run amplify env checkout dev
c. Run amplify env remove staging
d. Run  amplify pull --appId xxxxxxxxxxxxx --envName dev
And this is scary too:
Pre-pull status:

Current Environment: dev

| Category | Resource name                | Operation | Provider plugin   |
| -------- | ---------------------------- | --------- | ----------------- |
| Auth     | xxxxxxxxxx12345678           | Delete    | awscloudformation |
| Storage  | xxxxxxxxxxxxxxxxxx           | Delete    | awscloudformation |
| Storage  | xxxxxxxxxxxxxxx              | Delete    | awscloudformation |
| Storage  | xxxxxxxxxxxxxxxxxxx          | Delete    | awscloudformation |
| Storage  | xxxxxxxx                     | Delete    | awscloudformation |
| Function | xxxxxxxxxxxxxxxxxx           | Delete    | awscloudformation |
| Function | xxxxxxx                      | Delete    | awscloudformation |
| Function | xxxxxxxxxxxxxxx              | Delete    | awscloudformation |
| Function | xxxxxx                       | Delete    | awscloudformation |
| Function | xxxxxxxxxxx                  | Delete    | awscloudformation |
| Function | xxxxxxxx                     | Delete    | awscloudformation |
| Function | xxxxxxxxxxxxxxxxxx           | Delete    | awscloudformation |
| Function | xxxxxxxxxxxxxxxxxxxxxxxxxxxx | Delete    | awscloudformation |
| Function | xxxxxxxxxxxxxxxxxxx          | Delete    | awscloudformation |
| Api      | xxxxxxxxxxxxx                | Delete    | awscloudformation |

Local changes detected.
Pulling changes from the cloud will override your local changes.
? Are you sure you would like to continue? (y/N)

Though it seems scary, when you say enter Y, your back-end is restored from dev.
At this point, back to square one.  Except Amplify CLI has re-added aws-exports.js as an exclusion in .gitignore
There is also a new amplify folder in ./src, which I don't quite understand.  I didn't run amplify anything while in ./src, so???  I'll ignore for now, leaving it in the repo.

Remove exclusion for aws-exports.js form .gitignore
Commit all changes, including those made by amplify when performing the actions in step 15 above.
In Amplify Console, refresh the browser and make sure that the staging back-end is gone.
Start over at step 4 above (skipping step five, as it's done already)

The build works and the app gets deployed to CloudFront.  It's broken because it's lambda functions are missing env vars and other stuff, which is sad but expected.

Copy env vars from all dev lambdas to staging lambdas (not in the app, in lambda functions themselves)

Configure new user pool
a.  Configure policies
b.  Add Sign in with Apple manually, if you're using that
b.  Adjust callback URLs in App Client Settings to match the URL for new staging front-end.
c.  Add the correct URLs matching new User Pool domain name at each auth provider.
c.  Add custom attributes, if you're using them
d.  Add Attribute mapping for each provider, if you're using more than the default.
e.  Select Triggers, if you're using them.

Open staging at https://staging.xxxxxxxxxxxxxx.amplifyapp.com

Sign up new user with password.

A "User already exists" error is thrown by Cognito.

It turns out that adding aws-exports.js in the way that I did above, has the staging front-end looking at the dev back end.

Run amplify pull --appId xxxxxxxxxxxxxx --envName staging

This updates the values in aws-export.js to match the staging backend, except for the redirect URLs related to the User Pool App client settings.

Manually update redirectSignIn and redirectSignOut to prevent redirect_mismatch errors when doing federatedSignIn().
Remove aws-exports.js from .gitignore.  I've got a feeling I'm doing something wrong here!  Again, I've never included aws-exports.js.  Why is this different?
Commit all changes and push to staging branch in repo
This kicks off a new build of staging in the Amplify Console

Back-end build fails with:
UPDATE_FAILED      authmyapp02605eb4               AWS::CloudFormation::Stack Sat Apr 25 2020 17:58:53 GMT+0000 (Coordinated Universal Time) Parameters: [hostedUIProviderCreds] must have values

Hmm... 🤔

Check repo for team-provider-info.json file

It's there, but it's missing everything but the dev block.  My local copy has everything there.  Check .gitignore.  It's not excluded.  Hmm...

Make a minor change.  Push it to repo.  Kicks of another build.

It fails with:
UPDATE_FAILED   authmyapp02605eb4     AWS::CloudFormation::Stack Sat Apr 25 2020 18:13:20 GMT+0000 (Coordinated Universal Time) Parameters: [hostedUIProviderCreds] must have values

That's it!  I'm going back to COBOL...

FYI @swaminator I believe i followed the steps you outlined here exactly but am seeing what seems to be inconsistent behavior. Following the steps you outlined, I have had both prod and dev environments build, but also both fail with
Parameters: [hostedUIProviderCreds] must have values
One thing I noticed (possibly related to @kimfucious 's comment) is that initially dev failed but prod succeeded. At this point I was .gitignoreing my team-provider-info.json file. I then added it back, and dev builds but not prod. This is very likely a red herring, and I can't 100% be sure of this, but it does seem to have SOME effect (maybe?).
One thing I'm fairly certain of those is that this ideally shouldn't be so easy to break, especially with a branch new / clean "from scratch" project. Some better debug / diagnostic details / logging could be useful perhaps to make it easier for people to give better error reports?

Hi @Joycehao19 & @swaminator
Trying something new here, for the sake of simplicity, as I know my posts on this have been long and probably have some mistakes in them.

Use this article Feature branch deployments and team workflows from the AWS Amplify Console User Guide as a starting point.

Follow the steps in the Feature branch workflow section

Side note:  I do not know why it suggests to push in steps 2 and 3, as nothing has changed, but I did it anyway.

Do step 9, but change amplify api add to amplify auth add and go with Default configuration with Social Provider (Federation)

Another side note:  after step 9, the steps start at 1 again.  So, when I say step 9.3 below, I mean step 3 after step 9.  I've submitted feedback on the docs page to let the docs folks know.

Step 9.3 kicks off a build in the console and the build fails on the test back-end, with our old friend:

2020-04-26T13:07:53.470Z [INFO]: Error: auth headless init is missing the following inputParams googleAppIdUserPool, googleAppSecretUserPool

Notes:

All branches in the repo contain the team-provider-info.json file with clauses for dev, prod, and test, and these clauses contain the hostedUIProviderCreds property under categories/auth/...
I did not add env variables to any front ends in the Amplify Console.
On the weird issue I mentioned after step 9 here, I do have the app configured to import aws-exports.js as awsconfig and use it with Amplify.confgure(configure).  It is excluded by default in .gitignore,  but no error is thrown, so I must have something messed up in my other repo, where that (unrelated) error is occurring.

Hope this helps 🙏

よー @kevin-mitchell,
I know I've written some long posts, and some things might not have been clear, despite my best intentions.
To clarify this from here:

One thing I noticed (possibly related to @kimfucious 's comment) is that initially dev failed but prod succeeded.

My mention of prod in this post is for a pre-existing Amplify app that was initially created with dev and prod using auth without federated sign-in.  So both succeeded initially.
At present, I've got federated sign-in working on the dev back-end, because my front-end is my local dev machine.
However, because things are not working as expected, I've created a "staging" front-end (connected to a staging branch in the repo) and a "staging" back-end.  Or at least I've been trying to.
This is to keep a separation from production, letting the failures happen in staging while working toward a solution.  Ultimately, and hopefully soon, there will be a fix/workaround that works, and staging will get merged to master, kicking of a prod build that does not fail, and the world will be a better place.
I hope that's clear.  If not, please ask.

@magjack  Hi, sorry that you are still having this issue. Would you mind provide your appId, region and buildId? I can check from the logs to find out why it failed.

@kimfucious thank you for the detailed post. I'll work on investigation, and keep updating here.

Hi, @Joycehao19 @swaminator, got any thing for me yet?  I'm still dead in the water.

@swaminator @Joycehao19 Any progress on this.  @steinybot 's post gave me some hope, but it was fleeting, as I faced the same issue when creating a new backend via the console from a connected (private) repo branch (team-provider-info.js included, env vars added in the console) with this:
2020-05-07T14:53:20.109Z [INFO]: Error: auth headless init is missing the following inputParams googleAppIdUserPool, googleAppSecretUserPool

same thing giving errors whatever of the tricks i do mentioned here.

Hi @swaminator @Joycehao19,
I had a thought about this after having looked at the stack trace of the error, which points to<EMAIL_ADDRESS>I could be completely off-base, but here it goes anyhow:
There's a line item (492 in v 4.18.1) in that file that looks for the inclusion of the text accounts.google.com.
It's looking for this in previousValues.authProviders.
Though I'm not sure if I'm tracing everything correctly, I believe that ultimately the values in authProviders is coming from team-provider-info.json, specifically hostedUIProviderCreds.
And what I see in my entry for that on my local is:
"hostedUIProviderCreds": "[{\"ProviderName\":\"Google\",\"client_id\":\"123456789098-xxxxxxx12x0xxx64x3xx1x2x7xxxx0xx.apps.googleusercontent.com\",\"client_secret\":\"xxxXXXX9x0xXxXXxxxXxxxxx\"}]"

Note that there is no accounts.google.com, only apps.googleusercontent.com
If my guess is indeed true, then this entry will not be pushed into the array, and perhaps this is the cause of the errors that I'm getting.
Like I said, I could be way off base, but I thought I'd point it out, as I think I've tried all options possible to get things working and have come up short.

I am seeing this error again.
2020-05-10T17:15:37.026Z [INFO]:  2020-05-10T17:15:37.028Z [INFO]: For more information on AWS Profiles, see:                                  https://docs.aws.amazon.com/cli/latest/userguide/cli-multiple-profiles.html 2020-05-10T17:15:37.380Z [INFO]: Amplify AppID found: d2avikkcqe0wq. Amplify App name is: roundin-customer 2020-05-10T17:15:37.440Z [INFO]: Backend environment devf found in Amplify Console app: roundin-customer 2020-05-10T17:15:37.986Z [INFO]:  2020-05-10T17:15:38.977Z [INFO]: Note: It is recommended to run this command from the root of your app directory 2020-05-10T17:15:43.185Z [WARNING]: - Initializing your environment: devf 2020-05-10T17:15:43.844Z [WARNING]: ✔ Initialized provider successfully. 2020-05-10T17:15:43.872Z [WARNING]: ✖ There was an error initializing your environment. 2020-05-10T17:15:43.873Z [INFO]: init failed 2020-05-10T17:15:43.876Z [INFO]: Error: auth headless init is missing the following inputParams facebookAppIdUserPool, facebookAppSecretUserPool, googleAppIdUserPool, googleAppSecretUserPool, loginwithamazonAppIdUserPool, loginwithamazonAppSecretUserPool                                  at updateConfigOnEnvInit (/root/.nvm/versions/node/v10.16.0/lib/node_modules/@aws-amplify/cli/node_modules/amplify-category-auth/provider-utils/awscloudformation/index.js:369:15)                                  at /root/.nvm/versions/node/v10.16.0/lib/node_modules/@aws-amplify/cli/node_modules/amplify-category-auth/index.js:234:28                                  at /root/.nvm/versions/node/v10.16.0/lib/node_modules/@aws-amplify/cli/node_modules/promise-sequential/index.js:16:18                                  at process._tickCallback (internal/process/next_tick.js:68:7) 2020-05-10T17:15:43.891Z [ERROR]: !!! Build failed 2020-05-10T17:15:43.892Z [ERROR]: !!! Non-Zero Exit Code detected 2020-05-10T17:15:43.892Z [INFO]: # Starting environment caching... 2020-05-10T17:15:43.892Z [INFO]: # Environment caching completed
This time with both existing environments and new environments. I am on eu-west-1

Hi @magjack
For what it's worth, the only way that I've got this to semi-work again, is to follow @Joycehao19 's recommendation here.
In short, create custom push script and hard-code the AUTHCONFIG section with your ids and secrets.  Then, manually edit the amplify.yml file under build settings as shown in @Joycehao19 's instructions.
So far it's inconsistent, as I believe changes to auth anything will cause it to break again.  And multi-environments adds additional complexity, and I've yet to nail down a workflow combining amplify-cli and amplify console that works consistently.
Deleting the front-end and reconnecting a branch to build from sometimes works after that.
Again, for what it's worth 😉

@kimfucious こんにちは ：）
I feel like this shouldn't be that complicated to fix, and I keep downloading the amplify-cli source to try to figure it out, but so far I've lost motivation every time I start looking into this (it's for a "fun" project so nights and weekends).
One thing I recently did is switch my AWS account to an "organization" structure and created a brand new account specifically for hosting my project that I'm creating with Amplify. During that I had to redeploy everything from scratch and this has lead me to the understanding that (and I think I'm stating something obvious and well established, but it was a sanity check for myself) at least the first environment that is deployed with Amplify (the AWS service, not directly using the CLI) relies on the team-provider-info.json to get the google client id / secret. What I did is create try to deploy my backedn through the AWS Console -> Amplify BEFORE I pushed the google client id and secret in the team provider json and it failed with the familiar "missing..." console message. I then made a new commit with these values in the team provider info json and deployment happened without issue.
I also downloaded the source for amplify-cli and did a quick search for AMPLIFY_GOOGLE_CLIENT_ID but didn't find it... so my assumption was that this is probably a dynamic key, so I did find packages/amplify-category-auth/provider-utils/awscloudformation/index.js - the updateConfigOnEnvInit funciton seems like it might be worth looking into more to understand how this is actually working?

Hi @kevin-mitchell,
I agree it shouldn't be complicated, but we're dealing with a bug-workaround, so it is what it is, until that bug is fixed.
The workaround suggested by @Joycehao19 here does work, but not consistently, as far as I can tell.  It appears that any changes to auth will cause the error to occur again.  For example, changing call back URLs, like @steinybot mentioned, will cause the error to re-appear, even after prior builds have succeeded.  And the only fix (for me, at least) is to disconnect the front-end and re-connect it, which results in a successful build.
On team-provider-info.json, Amplify console (when running amplify init) needs the creds when auth is using federated/social logins.  And that info is stored in team-provider-info.json.  I've also seen that this info is stored in amplify/dev/.temp/#current-cloud-backend/amplify-meta.json (sometimes in temp dirs after deleting an env named "dev"), but it's my assumption/guess that team-provider-info.json is the source from which other entities try to pull the creds.
The bug involves not being able to get those creds.  I've found that the only way to get the console to see those creds is by hard coding them into a custom push script, as described in @Joycehao19 's link mentioned above.
I've yet tried removing team-provider-info.json from the repo with the hard-coded values in place, but my guess is that the build will work without it, if the custom script is being used in the build settings in Amplify console.  I believe you should also be able to reference these creds, if they are setup as env vars in the amplify console, as mentioned by @paulbartocillo here, so that you aren't putting secrets into the custom push script, that is getting checked into a repo.

I should also mention that I really do want this to work because Amplify saves so much time doing things that I really don't enjoy doing, like writing cloud formation templates, and let's me focus on creating product.  I'm hopeful that this is a bump in the road, that will get patched soon.
がんばって!

@kimfucious I agree with all your observations in that these work arounds can get a successful build and but fail soon after any changes in auth.
I have now opted for a different workaround in that I removed the backend build command - amplifyPush --simple  from amplify.yml so it now just acts as a front-end CI/CD pipeline and I will deploy the backends manually with the cli. This also involved removing aws-exports.js from the .gitingore file.  I hope this issue get resolved soon as the benefits of the amplify console are significant, however, when it goes wrong it can be a pain to fix.

I am also getting these errors now on an existing environment.
On the commits yesterday it was working fine. I've tried to redeploy yesterdays working build from build history, but this also fails.
Parameters: [hostedUIProviderCreds] must have values
Error: auth headless init is missing the following inputParams facebookAppIdUserPool, facebookAppSecretUserPool, googleAppIdUserPool, googleAppSecretUserPool
arn:aws:amplify:eu-central-1:526170664677:apps/d19opi8vv8vc20
eu-central-1
@Joycehao19 @swaminator  are there any updates?

Hi @Joycehao19 @swaminator,
I just did a build off a connected repo in Amplify Console that included auth changes, and it didn't fail!
Is this a fluke, or did something get fixed?
PS:  I still have the custom myAmplifyPush.sh script in place.

I was getting this error and then I noticed in my amplify/team-provider-info.json file somehow under the categories section my auth had been taken out, I would look at changes to this file and find one where auth->{your-auth-group}->hostedUIProviderCreds is present.

I got distracted by a plague, some riots, and a few other projects, but now I'm back looking at this and it's been since April 28 that @Joycehao19  or @swaminator  has commented here.
I wonder if this is considered working, being ignored, or what by the Amplify Console team?

I have tried the stuff on this page and I am still getting the same error. If a workaround exists why is this not fixed in the Amplify CLI? I send the values from the parameters to the console. Here is what I have
Categories: {"auth":{"googleAppIdUserPool":"878889996620-xxxxxxxxxxxx.apps.googleusercontent.com","googleAppSecretUserPool":"xxxxxxxxx",}} Providers: {"awscloudformation":{"configLevel":"project","useProfile":true,"profileName":"default"}} Amplify: {"envName":"dev"}
This is the error I get
UPDATE_FAILED               authtenjin844c8f14        AWS::CloudFormation::Stack Mon Jun 15 2020 19:18:51 GMT+0000 (Coordinated Universal Time) Parameters: [hostedUIProviderCreds] must have values
I am wondering why I have an extra comma after the value in the googleAppSecretUserPool? Is that the cause of the issue?

I removed the comma but still the same issue. What am I missing? I am only using Google Federation for now. I have created the myamplifypush.sh, updated the build setting and also created environment variables as mentioned in @vajafari 's thread.

Been using amplify heavily to build my startup since May 2019. I rely on auth, lambdas, storage, GraphQL. I also use  the amplify console, and replaced my CI with it when it introduced tests. I have 15+ years of experience as a full stack dev.
Regarding the present issue, after an afternoon trying to fix it, I simply disabled backend build from the console. I can't just rebuild auth from scratch, as I would lose my hundreds of users from cognito. The only safe way to proceed for me is to use the console just for the frontend. So I went back to deploying backend environments manually.
That's how I "solved" most of amplify problems I've had for the past 14 months: disable the feature. Most fixes provided usually involve rebuilding auth from scratch, which is not suitable for production websites. After trying hard to play by the amplify rules, I stopped believing I could rely on it.
When I could interact with aws team members, like @swaminator, it's always been a good experience. I can see that they are skilled and professional, but the problem seem to be elsewhere. A lot of times, a team member will start work on an issue, make good progress, and then suddenly stop working on it. It is then left hanging for months or years like this one.
I'm grateful for amplify as it made it easier for me to start in the AWS ecosystem, which would have been too overwhelming otherwise. But now, I just can't wait to replace it with something that is actually production ready. Like serverless or something like that.
The sad thing is, I'm not just dabbling around, I'm running a business. And amplify is a liability. Too bad amazon is treating this as something for people to play with, instead of the critical business infrastructure that it is for me.

I think these are great points. It's been really interesting to watch this issue, because I can't really tell if

there is just a small set of people who are really using Amplify past doing short lived sample projects?
The few of us active in this thread are just somehow doing something "wrong" (it doesn't seem that way)

I suspect that there may be larger customers who are using Amplify, but I wouldn't be surprised if they have more 1:1 support from AWS because of larger accounts for example, and I wouldn't be surprised if larger customers using Amplify have their own specific requirements around deployments that end up precluding the use of Amplify for deployments anyway.
Honestly I suspect there is a "goldilock zone" where smaller projects who don't have the resources for a full / part time infrastructure resource working on deployments that instead are using Amplify for this purpose. To be fair, from AWS account perspective these are probably really small and inconsequential accounts, so I can see why maybe this is perhaps not a huge priority. I've been using Amplify as a tool for a smaller hobby project, my "day job" we'd have a few people who would be working on this type of problem and we'd very quickly outgrow Amplify from a CI / deployment perspective I suspect.
What I think I'd like to see (maybe?) is the Amplify libraries (JS SDK, iOS, etc) documentation totally separated out from Amplify the deployment / CI / provisioning tooling. Perhaps offer a set of CDK templates as well as cloud formation templates to get started (or even have their generated an option via the Amplify CLI), but something really solid that isn't going to be dependent on an obviously not super actively supported build pipeline / AWS Amplify Console.
I feel like the Amplify "stack" is still really great, likely even for larger "production" projects as a way of helping to figure out auth and gate AWS resources. It just doesn't seem to scale super well if you are reliant on the SDK and build pipeline.
Anyway, <3 AWS and hopefully this is resolved or some sort of news comes out about why perhaps these types of tickets aren't super actively being addressed.

I'm grateful for amplify as it made it easier for me to start in the AWS ecosystem, which would have been too overwhelming otherwise. But now, I just can't wait to replace it with something that is actually production ready. Like serverless or something like that.

second this!
I'm genuinely afraid of doing anything with amplify cli as most of the time there are errors.
Been using serverless for different projects and my experience so far has been super smooth comparing to amplify :|

@thedgbrt Thanks for that feedback. We are working on a product launch and amplify sounded great because we have limited resources and amplify promises to take care of most of the details. But having listened to the comments here and grappling with many such issues I am rethinking this :-(

We are facing the same issue. Can we get a rough estimate of when this will be looked at?

@zetsnotdead I went down @thedgbrt 's route and pulled the backend out of the build and building it manually for now. Was able to move forward that way. The sad part is that unless you keep track of this thread we will not know if the issue has been fixed when it is fixed.
@swaminator Is there a single place for me to check what bugs have been fixed in each release?

@sudeep-quantelai @thedgbrt @zetsnotdead @xitanggg @yuyokk @KidSysco @kevin-mitchell @paulbartocillo @kimfucious @DavidBrear @kaipi apologies for the silence on this issue. While it was tough for us to read some of the comments in this thread, I completely understand and empathize with what you are going through. Just for the record, all developer feedback is important to us (not just the folks that pay for support). In fact that's why we took a unique approach (at least within AWS) to manage our issues on a public forum like GitHub vs the AWS Forums or relying only on paid support. Having said that, we completely dropped the ball on this issue - partly because we incorrectly thought we fixed it and then there were other competing priorities.
Resolving this issue is now our top priority along with #115.  The current 'fix' provided here does work but only for the first build. All subsequent builds fail with the hostedUI creds missing error.  We are working on fixing this ASAP and will keep you posted.
W.r.t @kimfucious situation where he needs to remove the teamprovider from a public repo: We do not have an immediate fix for that but are working on a redesign where the teamprovider file is stored in the service instead of the repository. That will ensure there is no scenario where the repository and the service are out of sync. That might take a little longer for us to solve but we are working on it. We would like to track that completely separately from this issue so we aren't mixing numerous problems so I created a new issue here #790.
Our dev team, @litwicki, and I will ensure to track this issue to resolution.

Solid response, @swaminator!
I realize the whole excluding teamprovider is a bug-bear, so I understand the delay on the fix.
I'll track that issue in the new location and provide info that you might find relevant if/when I come across it.
As for the first build-only issue, I've been working around it by simply trashing the front-end on each subsequent build, but it will be great to not have to do that when you fine folks have worked this all out.
Thanks for your dedication and continued awesome work in making Amplify great.

Thank you very much for the update. This is really nice to here, and much appreciated!

Thanks a lot for the update. It's great to hear it will be looked at. 👍
In general, any response about an issue from the amplify team is appreciated 🙏. Even if you let us know the issue will not be fixed soon it can give us a chance to react to it on our end by figuring out some workarounds.

I tried all the suggestion, but none of them worked. I am using latest amplify cli.
Finally following changes worked for me.
Added following env variables in Amplify Console > Environment  variables

You can get the value of AUTH_RESOURCE_NAME from your project folder amplify > backend > auth > <Folder name>
Then use the custom amplifyPush script with slight modification
#!/usr/bin/env bash
set -e
IFS='|'
help_output () {
    echo "usage: amplify-push <--environment|-e <name>> <--simple|-s>"
    echo "  --environment  The name of the Amplify environment to use"
    echo "  --simple  Optional simple flag auto-includes stack info from env cache"
    exit 1
}

init_env () {
    ENV=$1
    AMPLIFY=$2
    PROVIDERS=$3
    CODEGEN=$4
    AWSCONFIG=$5
    CATEGORIES=$6
    echo "# Start initializing Amplify environment: ${ENV}"
    if [[ -z ${STACKINFO} ]];
    then
        echo "# Initializing new Amplify environment: ${ENV} (amplify init)"
        amplify init --amplify ${AMPLIFY} --providers ${PROVIDERS} --codegen ${CODEGEN} --categories ${CATEGORIES} --yes;
        echo "# Environment ${ENV} details:"
        amplify env get --name ${ENV}
    else
        echo "STACKINFO="${STACKINFO}
        echo "# Importing Amplify environment: ${ENV} (amplify env import)"
        amplify env import --name ${ENV} --config "${STACKINFO}" --awsInfo ${AWSCONFIG} --categories ${CATEGORIES} --yes;
        echo "# Initializing existing Amplify environment: ${ENV} (amplify init)"
        amplify init --amplify ${AMPLIFY} --providers ${PROVIDERS} --codegen ${CODEGEN} --yes;
        echo "# Environment ${ENV} details:"
        amplify env get --name ${ENV}
    fi
    echo "# Done initializing Amplify environment: ${ENV}"
}

ENV=""
IS_SIMPLE=false
POSITIONAL=()
while [[ $# -gt 0 ]]
do
    key="$1"
    case ${key} in
        -e|--environment)
            ENV=$2
            shift
            ;;
        -r|--region)
            REGION=$2
            shift
            ;;
        -s|--simple)
            IS_SIMPLE=true
            shift
            ;;
        *)
            POSITIONAL+=("$1")
            shift
            ;;
    esac
done

set -- "${POSITIONAL[@]}"

# if no provided environment name, use default env variable, then user override
if [[ ${ENV} = "" ]];
then
    ENV=${AWS_BRANCH}
fi
if [[ ${USER_BRANCH} != "" ]];
then
    ENV=${USER_BRANCH}
fi

# Check valid environment name
if [[ -z ${ENV} || "${ENV}" =~ [^a-zA-Z0-9\-]+ ]] ; then help_output ; fi

AWSCONFIG="{\
\"configLevel\":\"project\",\
\"useProfile\":true,\
\"profileName\":\"default\"\
}"

AMPLIFY="{\
\"envName\":\"${ENV}\"\
}"

PROVIDERS="{\
\"awscloudformation\":${AWSCONFIG}\
}"

CODEGEN="{\
\"generateCode\":false,\
\"generateDocs\":false\
}"

AUTHCONFIG="{\
\"${AUTH_RESOURCE_NAME}\":\"{\
\"googleAppIdUserPool\":\"${GOOGLE_APP_ID}\",\
\"googleAppSecretUserPool\":\"${GOOGLE_APP_SECRET}\",\
\"facebookAppIdUserPool\":\"${FB_APP_ID}\",\
\"facebookAppSecretUserPool\":\"${FB_APP_SECRET}\"\
}}"

CATEGORIES="{\
\"auth\":$AUTHCONFIG\
}"

# Handle old or new config file based on simple flag
if [[ ${IS_SIMPLE} ]];
then
    echo "# Getting Amplify CLI Cloud-Formation stack info from environment cache"
    export STACKINFO="$(envCache --get stackInfo)"
    init_env ${ENV} ${AMPLIFY} ${PROVIDERS} ${CODEGEN} ${AWSCONFIG} ${CATEGORIES}
    echo "# Store Amplify CLI Cloud-Formation stack info in environment cache"
    STACKINFO="$(amplify env get --json --name ${ENV})"
    envCache --set stackInfo ${STACKINFO}
    echo "STACKINFO="${STACKINFO}
else
    # old config file, above steps performed outside of this script
    init_env ${ENV} ${AMPLIFY} ${PROVIDERS} ${CODEGEN} ${AWSCONFIG} ${CATEGORIES}
fi

The modified part
AUTHCONFIG="{\
\"${AUTH_RESOURCE_NAME}\":\"{\
\"googleAppIdUserPool\":\"${GOOGLE_APP_ID}\",\
\"googleAppSecretUserPool\":\"${GOOGLE_APP_SECRET}\",\
\"facebookAppIdUserPool\":\"${FB_APP_ID}\",\
\"facebookAppSecretUserPool\":\"${FB_APP_SECRET}\"\
}}"

Then update your build settings, Amplify Console > Build Settings
version: 1
backend:
  phases:
    build:
      commands:
        - '# Execute Amplify CLI with the helper script'
        - chmod u+x ./amplifyPush
        - ./amplifyPush --simple
frontend:
  phases:
    build:
      commands:
        - yarn install
        - yarn run build
  artifacts:
    baseDirectory: build
    files:
      - '**/*'
  cache:
    paths:
      - node_modules/**/*

So what is the latest on this issue?  I literally got it from one build to the next with nothing on the Auth or backend changing at all.  I am loathe to put in any partial hacks to try and work around it, so when can we expect an actual fix?

I'm getting this out of nowhere too

@jasonergle-powerschool @cespin @arnabk @kimfucious @zetsnotdead We have started releasing a fix this week that should be available to all regions before end of week. Both us-west-2 and us-east-* have been updated so please let me or the team know if you still experience any issues.

@jasonergle-powerschool @cespin @arnabk @kimfucious @zetsnotdead We have started releasing a fix this week that should be available to all regions before end of week. Both us-west-2 and us-east-* have been updated so please let me or the team know if you still experience any issues.
This fix includes the ability to add Environment Variables when connecting the front end to an existing backend the very first time. The builds which were previously failing from second time onward should succeed always when the social creds are passed/present in the environment variables. This applies only to backends configured with Social sign in credentials.

Thanks for the response.  I am in US-East-1 and still see the issue.  Are you saying that I should define the social creds as environment variables now?

Hi @jasonergle-powerschool,
Yes, that is correct. Once the social sign in creds are added as environment variables, they would default to be used in all branches, and the builds would pick it up. You can override them per branch if you have different social creds  across branches.

@litwicki is there a ticket or issue on github we can watch to see changes / make sure we are following along in the right place? I think it would be more useful to just follow along with the progress in that issue / PR / release directly rather than the "is it done yet?!" type questions we might ask here?
Also, thank you! :)

@kevin-mitchell We can use this issue to track progress/updates. As of this message we are rolled out to all regions with the fix. As @abhi7cr mentioned above if you add the social sign in creds as env variables you will be all good to go for all branches. If you notice anything abnormal please let us know here.

Just got here (started getting this issue today). Thank you @litwicki and @abhi7cr for fix and replies here, but it is not working for me—your instructions are a bit vague though, so I may not be doing the right thing. Can one of you please explain specifically how to fix the original issue stated in this bug? To clarify my confusion:

Does the "fix" actually mitigate the underlying issue (of amplify console build failing) providing I add the right environment variables? If so, specifically what are the env variable names?
Or does the fix just fix the env variables getting to amplify scripts, i.e. it fixes custom amplifyPush script workaround that's been bandied about here by various commenters?

Thanks in advance.

Hi @benkrejci,
The fix would enable the following 2 things:

ability to add environment variables during the first time you connect a frontend to an existing backend.
This would enable the following workflow:
Once you create a backend in Amplify CLI, with auth configured via Social credentials (Facebook, google, Amazon), when you connect your frontend for the first time,  you would have the option to add environment variables corresponding to the social credentials configured during the backend creation. The list of their names can be referred from  https://github.com/aws-amplify/amplify-console/issues/206#issuecomment-607499826

Once the env variables are configured, all the builds would use them for pulling/updating the backend.

Previously 1) was not possible and 2) failed from the second  build onwards. You wouldn’t need to use the custom amplify push script anymore if you are just configuring the social credentials. Adding the creds https://github.com/aws-amplify/amplify-console/issues/206#issuecomment-607499826 to Environment variables should suffice.
Let me know if you see any issues.

Adding only the env vars fixed it for me.

@abhi7cr perfect explanation, thank you so much! I changed the environment variable names to the following and subsequent builds have succeeded:
AMPLIFY_AMAZON_CLIENT_ID
AMPLIFY_AMAZON_CLIENT_SECRET
AMPLIFY_FACEBOOK_CLIENT_ID
AMPLIFY_FACEBOOK_CLIENT_SECRET
AMPLIFY_GOOGLE_CLIENT_ID
AMPLIFY_GOOGLE_CLIENT_SECRET

I'll add my experience here. This issue started occurring recently where it had been working fine before. Adding the environment variables mentioned by @benkrejci (although I just use google and facebook) made the amplify build work again. I made my test google and facebook app credentials the main env var version, and then did an override for the production specific credentials on my master branch. Not sure if there are any best practices regarding which branches to override, but I think this will work for me in my early stage development.

@arnabk thank you. I resolved my issue related to this.
here is my codes below and PR log
amplfypush.sh
#!/usr/bin/env bash
set -e
IFS='|'
help_output () {
    echo "usage: amplify-push <--environment|-e <name>> <--simple|-s>"
    echo "  --environment  The name of the Amplify environment to use"
    echo "  --simple  Optional simple flag auto-includes stack info from env cache"
    exit 1
}

init_env () {
    ENV=$1
    AMPLIFY=$2
    PROVIDERS=$3
    CODEGEN=$4
    AWSCONFIG=$5
    CATEGORIES=$6
    echo "# Start initializing Amplify environment: ${ENV}"
    if [[ -z ${STACKINFO} ]];
    then
        echo "# Initializing new Amplify environment: ${ENV} (amplify init)"
        amplify init --amplify ${AMPLIFY} --providers ${PROVIDERS} --codegen ${CODEGEN} --categories ${CATEGORIES} --yes;
        echo "# Environment ${ENV} details:"
        amplify env get --name ${ENV}
    else
        echo "STACKINFO="${STACKINFO}
        echo "# Importing Amplify environment: ${ENV} (amplify env import)"
        amplify env import --name ${ENV} --config "${STACKINFO}" --awsInfo ${AWSCONFIG} --categories ${CATEGORIES} --yes;
        echo "# Initializing existing Amplify environment: ${ENV} (amplify init)"
        amplify init --amplify ${AMPLIFY} --providers ${PROVIDERS} --codegen ${CODEGEN} --categories ${CATEGORIES} --yes;
        echo "# Environment ${ENV} details:"
        amplify env get --name ${ENV}
    fi
    echo "# Done initializing Amplify environment: ${ENV}"
}

ENV=""
IS_SIMPLE=false
POSITIONAL=()
while [[ $# -gt 0 ]]
do
    key="$1"
    case ${key} in
        -e|--environment)
            ENV=$2
            shift
            ;;
        -r|--region)
            REGION=$2
            shift
            ;;
        -s|--simple)
            IS_SIMPLE=true
            shift
            ;;
        *)
            POSITIONAL+=("$1")
            shift
            ;;
    esac
done

set -- "${POSITIONAL[@]}"

# if no provided environment name, use default env variable, then user override
if [[ ${ENV} = "" ]];
then
    ENV=${AWS_BRANCH}
fi
if [[ ${USER_BRANCH} != "" ]];
then
    ENV=${USER_BRANCH}
fi

# Check valid environment name
if [[ -z ${ENV} || "${ENV}" =~ [^a-zA-Z0-9\-]+ ]] ; then help_output ; fi

AWSCONFIG="{\
\"configLevel\":\"project\",\
\"useProfile\":true,\
\"profileName\":\"default\"\
}"

AMPLIFY="{\
\"envName\":\"${ENV}\"\
}"

PROVIDERS="{\
\"awscloudformation\":${AWSCONFIG}\
}"

CODEGEN="{\
\"generateCode\":false,\
\"generateDocs\":false\
}"

AUTHCONFIG="{\
\"facebookAppIdUserPool\":\"${FACEBOOK_APP_ID}\",\
\"facebookAppSecretUserPool\":\"${FACEBOOK_APP_SECRET}\"\
\"googleAppIdUserPool\":\"${GOOGLE_CLIENT_ID}\",\
\"googleAppSecretUserPool\":\"${GOOGLE_CLIENT_SECRET}\"\
}"

CATEGORIES="{\
\"auth\":$AUTHCONFIG\
}"

# Handle old or new config file based on simple flag
if [[ ${IS_SIMPLE} ]];
then
    echo "# Getting Amplify CLI Cloud-Formation stack info from environment cache"
    export STACKINFO="$(envCache --get stackInfo)"
    init_env ${ENV} ${AMPLIFY} ${PROVIDERS} ${CODEGEN} ${AWSCONFIG} ${CATEGORIES}
    echo "# Store Amplify CLI Cloud-Formation stack info in environment cache"
    STACKINFO="$(amplify env get --json --name ${ENV})"
    envCache --set stackInfo ${STACKINFO}
    echo "STACKINFO="${STACKINFO}
else
    # old config file, above steps performed outside of this script
    init_env ${ENV} ${AMPLIFY} ${PROVIDERS} ${CODEGEN} ${AWSCONFIG} ${CATEGORIES}
fi

amplify.yml
version: 1
backend:
  phases:
    build:
      commands:
        - cd frontend/kendra-button-front
        - chmod +x amplfypush.sh
        - ./amplfypush.sh -e dev
frontend:
  phases:
    preBuild:
      commands:
        - yarn
    build:
      commands:
        - find . -name "aws-exports.js"
        - yarn build
  artifacts:
    baseDirectory: frontend/kendra-button-front/src/out
    files:
      - '**/*'
  cache:
    paths:
      - node_modules/**/*

I think this is a temporary solution, but I hope that a public solution will come out later.

I resolve a similar issue on a project just by adding to team-provider-info.json:
"auth": {
   "docduoweb8a2a1700": {
       "hostedUIProviderCreds": "[{\"ProviderName\":\"Google\",\"client_id\":\"xxx\",\"client_secret\":\"xxx\"}]"
   }
},

This was missing after amplify pull

Hi, This AWS bug has caused us weeks of delay for redeploying (with a minor change) something that was already working before. AWS guys, could you pls send a detailed step by step procedure to fix this?. This is VERY URGENT and we are considering to moving to Azzure ASAP!

@serviolimareina  it sounds like this is now resolved I believe. By adding the credentials to the appropriate environment variables builds should now proceed.

Hello @serviolimareina, you can follow the below steps:
Connecting a front-end app in Amplify Console with an amplify backend configured using Social sign-in (OAuth):
Prerequisite: You must have an amplify backend environment setup using CLI, with auth category configured using social sign-on.

Go to the backend app in Amplify Console using the amplify console CLI command or by directly logging into your AWS Console
Click the Frontend environments tab
Select a repository provider
Add repository branch
Configure build settings: Expand the Environment variables section to add the following environment variables (You would need to add only the variables corresponding to the social platforms you have configured during the Auth CLI setup):
AMPLIFY_FACEBOOK_CLIENT_ID
AMPLIFY_FACEBOOK_CLIENT_SECRET
AMPLIFY_GOOGLE_CLIENT_ID
AMPLIFY_GOOGLE_CLIENT_SECRET
AMPLIFY_AMAZON_CLIENT_ID
AMPLIFY_AMAZON_CLIENT_SECRET
Review. Make sure the environment variables are correct. Click Save and deploy

Note: If you have different values for your social credentials based on the branch, you can configure them individually in the Environment variables section found under App settings
Let me know if you have further questions/clarifications.
PS: We are also in the process of updating our official docs, and will update here as soon as its done.

It's still not working for me, even worse, as using newest version 4.25.0 breaks workaround from this comment https://github.com/aws-amplify/amplify-console/issues/206#issuecomment-650689777.
I've tried both A and B approaches.
PS. I will ask the same question from different issues. Are you sure that Amplify is production ready?
There are so many regressions and weird bugs like with expiring API Key and unable to generate new one that in our team we are thinking that it is absolutely not.

Hi,
If anyone is struggling with this issue still after trying all of the suggestions in this thread. I have come up with a pretty hacky but useful workaround. It was blocking me from developing in my staging environment so I needed to solve it quickly.
For context, I am deploying a next.js application on vercel. I have a build command which is 'build:vercel' in package.json which runs during deployment.
The command I initially ran was "build:vercel": "./vercel-build.sh && next build",. This called a build script that had the CATEGORIES flag and the AUTHCONFIG in it. This did not work for me, I tried so many variations.
I decided to run the script without the --yes flag at the end. When I went through the steps I noticed it would only ask for facebookAppId, amazonAppId, googleClientId when I select 'Yes' to Do you plan on modifying this backend?
I didnt have a requirement to modify the backend during my build, I only need 'aws-exports.js' generated so that I can use it in my react application. So I decided to remove the --y and modify the build command to enter no when the script becomes interactive. So my command became:
./vercel-build.sh <<< $'no\n' && next build
I just ran the build and it works great! I hope this helps someone with a similar use case, at least until there is a proper fix.

Setting the environment variables like explained in https://github.com/aws-amplify/amplify-console/issues/206#issuecomment-660498668 worked for me. However, I don't think this should be necessary as the values are already set in team-provider-info.json.

I have added the environment variable as specified (double checked it), and my build is still failing. I have loved using AWS for the past 4 years, so I was excited to discover Amplify. However, its current state is not production ready when a simple Google Sign In needs all these hacky solution, especially when this problem has existed for over 6 months. Again, love AWS and would love to use Amplify when it's ready, but frankly, I can't recommend (if not discourage) people from using Amplify.

@AlbertPun in my personal experience the process of manually creating Cognito Pool and only use amplifyjs to connect to existing resource is so much smoother than using amplify cli and face different weird issues with cli/console integration.

@yuyokk Thanks for the suggestion. I will try that going forward. I'm seeing a lot of problems with the cli, such as every time I'm deleting and then adding an auth or sometimes I make updates I get cloudformation reference errors.

Finally closign this issue as it has been resolved. For those landing here now, check out this post

Shouldn't the amplify-cli add these variables automatically, or at the very least the documentation be updated? As a new Amplify user following the official docs, the first build will fail with a cryptic error and they'll have to Google the error to find this thread and then read the entire thing to find the correct answer. Not the best solution IMHO.

For those who still have problems verify if you don't have whitespaces in front or at the end.  We are updating the docs with the relevant info: https://github.com/awsdocs/aws-amplify-console-user-guide/pull/36

@abhi7cr @swaminator as by 01/11/2020 this issue still appears when I turn on PR Previews that create a new backend environment for every PR.
I have done as suggested in your comment, the required env variables are set for all branches:

The dev branch works as expected but the backend build for the PR environments fails in the same way ("Error: auth headless is missing the following inputParams googleClientId, facebookAppId").
Is this a known bug?

Same goes here @jackscotti thanks for posting!

I followed the instructions for setting up the environment variables in the web console for my automatic github deploys and that worked well for me. Afterward I ran into issues where amplify push would fail after adding user pools to my auth. I was able to fix it by amplify pulling which prompted me for my identity provider keys, and the next push worked. For anyone that runs into the same issue.

I just created a new amplify environment so i do not interfere with a team member. After successfully creating the new backend I made some changes to a function. Pushing those changes with amplify push failes with
UPDATE_FAILED      authcognito                     AWS::CloudFormation::Stack Wed Feb 03 2021 23:40:18 GMT-0500 (Eastern Standard Time) Parameters: [hostedUIProviderCreds] must have values"

@swaminator This issue needs to be reopened. I'm seeing the same thing @jackscotti sees.

Hey Everyone!
We are also stuck with the same problem today.
When doing amplify pull in headless mode we are facing the same error.
Why is this behavior different for headless mode ? Why isn't the configuration as simple as it is for non headless mode ? Why is app secrets even required for this process ? Everything is so bleak...
What exactly is the solution/workaround for this?
The issue seems to be open for almost 2 year and we still don't have clarity

I ran into this as well once I tried "Previews". For a user-generated environment the default amplifyPush worked just fine. Really odd and unpredictable.

@adi518 did you follow https://docs.aws.amazon.com/amplify/latest/userguide/environment-variables.html#creating-a-new-backend-environment-with-authentication-parameters @DeerajTheepshi could you also share your appid?

I only showed up here to get off of this list. I submitted this issue nearly 2 years ago. I have since changed jobs, and I work on the Google Cloud Platform now which has no issues like this. Let's face it folks, Amplify is a mess and it is not at all what AWS has claimed it should be. IMO, Amplify still needs a few more years before it is ready for production use.
Mainly, I just want this issue to stop hitting my inbox. 2 years of watching this problem unfold over and over again is quite enough. I remember the pain of Amplify, hopefully I never need to go through any of those failed, and broken promises from AWS ever again!

you can unsubscribe
On Sep 4, 2021, at 3:31 PM, Ryan Segura @.***> wrote:

I only showed up here to get off of this list. I submitted this issue nearly 2 years ago. I have since changed jobs, and I work on the Google Cloud Platform now which has no issues like this. Let's face it folks, Amplify is a mess and it is not at all what AWS has claimed it should be. IMO, Amplify still needs a few more years before it is ready for production use.
Mainly, I just want this issue to stop hitting my inbox. 2 years of watching this problem unfold over and over again is quite enough. I remember the pain of Amplify, hopefully I never need to go through any of those failed, and broken promises from AWS ever again!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/aws-amplify/amplify-console/issues/206#issuecomment-912974973, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACQF3YW3RUGXO7DQQZVUDQLUAINT5ANCNFSM4JDRK43A.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

@adi518 did you follow docs.aws.amazon.com/amplify/latest/userguide/environment-variables.html#creating-a-new-backend-environment-with-authentication-parameters @DeerajTheepshi could you also share your appid?

Yeah, our user-generated environments work just fine. It's these preview builds that have issues. However, at this point in the time, I already found the bug, it's the envCache service! it lower-cases whatever key you give it and also seems to override stackInfo, so even when you fix it to be stackinfo, you still don't get the environment metadata for the subsequent builds, hence an "already exists" exception. I wrote about it in my issue: https://github.com/aws-amplify/amplify-console/issues/2096#issuecomment-900499684.

Also getting headaches' worth of issues with this...
What exactly is amplifyPush? And when/what/how are environment variables treated by the backend phase of the amplify build server?
We added a few commands to the backend phase of our amplify.yml file:
commands:
   - set -x
   - cat $(whereis amplifyPush | cut -d ' ' -f 2)
   - AMPLIFY_GOOGLE_CLIENT_ID=...
   - AMPLIFY_GOOGLE_CLIENT_SECRET=...
   - echo $AMPLIFY_GOOGLE_CLIENT_ID
   - AMPLIFY_GOOGLE_CLIENT_ID=$AMPLIFY_GOOGLE_CLIENT_ID AMPLIFY_GOOGLE_CLIENT_SECRET=$AMPLIFY_GOOGLE_CLIENT_SECRET amplifyPush --simple

which still resulted in the same error
2021-10-01T03:15:13.586Z [INFO]: Amplify AppID found: d2nvp1g11xxgci. Amplify App name is: web-app
2021-10-01T03:15:13.633Z [INFO]: Backend environment staging found in Amplify Console app: web-app
2021-10-01T03:15:15.146Z [WARNING]: - Fetching updates to backend environment: staging from the cloud.
2021-10-01T03:15:16.371Z [WARNING]: ✔ Successfully pulled backend environment staging from the cloud.
2021-10-01T03:15:16.421Z [WARNING]: ✖ There was an error initializing your environment.
2021-10-01T03:15:16.439Z [INFO]: Failed to pull the backend.
2021-10-01T03:15:16.441Z [INFO]: auth headless is missing the following inputParams googleAppIdUserPool, googleAppSecretUserPool
2021-10-01T03:15:16.478Z [INFO]: Error: auth headless is missing the following inputParams googleAppIdUserPool, googleAppSecretUserPool
                                     at updateConfigOnEnvInit (/root/.nvm/versions/node/v14.18.0/lib/node_modules/@aws-amplify/cli/node_modules/amplify-category-auth/src/provider-utils/awscloudformation/index.js:134:15)
                                     at /root/.nvm/versions/node/v14.18.0/lib/node_modules/@aws-amplify/cli/node_modules/amplify-category-auth/src/index.js:304:28
                                     at /root/.nvm/versions/node/v14.18.0/lib/node_modules/@aws-amplify/cli/node_modules/promise-sequential/index.js:16:18
                                     at runMicrotasks (<anonymous>)
                                     at processTicksAndRejections (internal/process/task_queues.js:95:5)

but we also observed a few 'interesting things...

amplifyPush is located in /usr/bin/amplifyPush and is the same as https://github.com/aws-amplify/amplify-console/blob/master/scripts/amplifyPush.sh, except for the --forcePush on line 20: [[ -z ${CATEGORIES} ]] && amplify init --amplify ${AMPLIFY} --providers ${PROVIDERS} --codegen ${CODEGEN} --yes --forcePush || amplify init --amplify ${AMPLIFY} --providers ${PROVIDERS} --codegen ${CODEGEN} --categories ${CATEGORIES} --yes --forcePush
each command is logged on the console. For example, the echo $AMPLIFY_GOOGLE_CLIENT_ID command is logged as (notice that the variable is evaluated before being logged... not sure why)

2021-10-01T03:14:51.284Z [INFO]: # Executing command: echo XXXXXXXX.apps.googleusercontent.com
                                 XXXXXXXXXX.apps.googleusercontent.com

Most importantly, there is no such # Executing command logged for the amplifyPush command!! Notice the first error log above... it's as if the amplifyPush command is treated differently from other commands... what exactly is happening with this Amplify?!

Furthermore, the script doesn't read from the environment variables that were set in the previous commands... it only reads from the env variables set in the console. This is awful behavior... as these env variables are not checked into git, and it becomes very hard to redeploy the project in another account without forgetting about all of these ad-hoc console settings that have to be entered manually.
Please Amplify, can this issue be reopened and fixed once and for all?

I can't believe this is still an issue. This project is a complete joke.