Cognito - Client is not enabled for OAuth2.0 flows

Question

I've successfully set up an AWS Cognito environment that runs on Localhost following this tutorial.

For the next step, I published the app to my external web server. I confirmed that the Cognito configuration (i.e. Client ID, Metadata Address, Region, etc) is correct. However, when I access and try to sign into the newly published public site I receive the follow error: " Client is not enabled for OAuth2.0 flows."

EDIT:

Here are my App Client Settings

I would like help with what I should look into in the AWS Cognito config or the Server config settings. The server is NOT using a load balancer. I believe the issue may lie somewhere in the Reverse Proxy or HTTPS settings.

Seignior

Could you provide your AWS Cognito App Client Settings? – Primulaceous

it is done @JonE – Seignior

I had the same issue and it was due to the upper-case which I used on the callback url. I simply used all lower case to fix it. – Connotative

Answer 1

This issue was not a cognito problem but rather an IIS and HTTPs issue. Make sure your servers are completely HTTPS if you plan to use this AWS service. Leave comments with any questions.

Seignior

Answer 2

I have seen this issue before. When making the request to Cognito, please take a close look at the redirect URL/ Call back URL you are specifying. If I remember correctly, I have seen this issue if you have a trailing '/' or a missing '/' in the redirect URL depending on what you have specified in the App Client Settings.

Tried

That was the case for me, an additional "/"... Thanks! – Instalment

I had to add a trailing "/" in my App Client settings, in the callback / signout URLs! – Byplay

I had to add a trailing "/" in my callback URLs too. That was all it needed. – Evanevander

Answer 3

This also occurs when you set up Cognito using Cloudformation or AWS SAM, and forgot to enable AllowedOAuthFlowsUserPoolClient property to true.

Resources:
  FooBarUserPoolClient:
    Type: AWS::Cognito::UserPoolClient
    Properties:
      AllowedOAuthFlowsUserPoolClient: True # Set here

Thermocouple

It was my case and it worked for me. – Ledet

Same, life saver! – Nieves

For terraform users, the equivalent setting is allowed_oauth_flows_user_pool_client in the aws_cognito_user_pool_client resource. – Carnarvon

Answer 4

I understand OP has not asked to use terraform for this issue, but it might help someone in the future who is using terraform to create cognito user pool client. If you are getting this issue, like me, while using terraform make sure to set allowed_oauth_flows_user_pool_client to true. For example, like this:

resource "aws_cognito_user_pool_client" "client" {
  name = "<your user pool client name>"
...
  allowed_oauth_flows_user_pool_client = true
}

Here is the link to terraform doc for creating user pool client.

And here is the link to the AWS doc where it says you have to set the attribute AllowedOAuthFlowsUserPoolClient to true. This attribute maps to the same allowed_oauth_flows_user_pool_client = true in terraform.

Sashenka

This comment just saved me, thank you! You would figure terraform/hashicorp would document these things – Saltatorial

Answer 5

TLDR: In addition to previous answers, make sure your callback URL is in lower case.

Long Answer: I encountered the same error. In my case, I had copied the DNS name of my Application Load Balancer from the description window of the Load Balancer page where there was varied casing

So I put the below into the callback URL and encountered the error in question:

https://*AppLBTest*-123456123456.ap-southeast-1.elb.amazonaws.com/oauth2/idpresponse

After changing the callback URL to the below, auth worked as expected:

https://*applbtest*-123456123456.ap-southeast-1.elb.amazonaws.com/oauth2/idpresponse

Blown

This is ridiculous. Yet it fixed my issue. Thanks! – Pearman

also fixed my issue. if you are using an ALB, make sure you put the DNS name in lowercase for the callback url! – Kufic

Answer 6

For those of you coming here, and seeing the CloudFormation answer above, this is also true if you update the UserPoolClient via the cli as follows:

aws cognito-idp update-user-pool-client --user-pool-id "USER_POOL_ID" --client-id "CLIENT_ID"
  --callback-urls "https://URL_1/" "http://URL_2/" --supported-identity-providers "IDP_NAME"
  --allowed-o-auth-flows "code" --allowed-o-auth-scopes "SCOPE"

The issue is that (and it all looks ok from the console) the client is not enabled for OAuth2 flows if not explicitly specified. From the doc:

Warning If you don't provide a value for an attribute, it will be set to the default value.

.. for:

--allowed-o-auth-flows-user-pool-client

the default is not present, so you need to ensure that you add the param, so the correct call is:

aws cognito-idp update-user-pool-client --user-pool-id "USER_POOL_ID" --client-id "CLIENT_ID"
  --callback-urls "https://URL_1/" "http://URL_2/" --supported-identity-providers "IDP_NAME"
  --allowed-o-auth-flows "code" --allowed-o-auth-scopes "SCOPE" --allowed-o-auth-flows-user-pool-client

Hope this helps someone else landing here ...

Audiology

Answer 7

For me it was a different issue. It worked fine on Authorization Code Grant but was causing issues for Implicit Grant and was giving me that error. To fix it I had to have Profile selected in OpenID Connect Scopes.

Panther