AWS Cognito; unauthorized_client error when hitting /oauth2/token

Question

Steps taken so far:

• Set up new user pool in cognito
• Generate an app client with no secret; let's call its id user_pool_client_id
• Under the user pool client settings for user_pool_client_id check the "Cognito User Pool" box, add https://localhost as a callback and sign out url, check "Authorization Code Grant", "Implicit Grant" and everything under "Allowed OAuth Scopes"
• Create a domain name; let's call it user_pool_domain

Create a new user with a username/password

Now, I can successfully go to:

https://{{user_pool_domain}}.auth.us-east-2.amazoncognito.com/oauth2/authorize?response_type=code&client_id={{user_pool_client_id}}&redirect_uri=https%3A%2F%2Flocalhost

This presents me with a login page and I am able to login as my user which returns me to https://localhost/?code={{code_uuid}}

I then try the following: curl -X POST https://{{user_pool_domain}}.auth.us-east-2.amazoncognito.com/oauth2/token -H 'Content-Type: application/x-www-form-urlencoded' -d 'grant_type=authorization_code&redirect_uri=https%3A%2F%2Flocalhost&code={{code_uuid}}&client_id={{user_pool_client_id}}'

However, this just returns back the following: {"error":"unauthorized_client"}

The token endpoint docs say that unauthorized_client is because "Client is not allowed for code grant flow or for refreshing tokens." which is confusing because I checked the boxes allowing the client to use the code grant flow.

Solution 1

So, it turns out that the user pool has to have a trailing slash (https://localhost/) and then that trailing slash has to be used in all of the callback URLs. Then it decides to work!

Solution 2

Everything looks OK to me. I think it may be complaining about the Authorization header missing but not sure. You could try a few things:

1) According to this page (https://docs.aws.amazon.com/cognito/latest/developerguide/token-endpoint.html), you shouldn't need to send the Authorization header in the token request, but maybe it is still needed. You could try either passing just the client ID in it (Authorization [client ID]) or configure a secret and try passing Authorization [client ID:client secret] like it says). It usually makes sense to use a client secret for authorization code flow anyway since in this flow, there is a server side component that can securely handle the token exchange.

2) Try using Implicit Flow instead to see if that works. Implicit Flow makes sense for single page apps with no server side component. For that, no client secret is needed.

Solution 3

If you are using amplify and have it configured outside of the CLI and the other answers aren't working for you, one last fix you can try is to ensure you have responseType: 'token' if you are using implicit flow. Fixed things for me.

Auth: {
  oauth: {
    domain : 'your-app.auth.your-region.amazoncognito.com',
    redirectSignIn: environment.cognito.oauthCallbackLogin,
    redirectSignOut: environment.cognito.oauthCallbackLogout,
    responseType: 'token',
    scope : ['email', 'openid', 'profile'],
  }
}

Comments

[Mike Patrick]

As Andrew noted, you can get this error when there is a problem with the redirect_uri. Using localhost has never been a problem for me, but I do get this (rather misleading) error message whenever I omit the trailing slash on the redirect_uri when calling the token endpoint. Can you try adding %2F to the end of the redirect_uri?

[TranquilMarmot]

@MikePatrick WOW thank you so much! It was the missing trailing slash. That's a frustratingly bad error message that I lost a day on but it actually works now!!!

[Per Christian Henden]

I found that this also holds if I have a list of redirect uris defined in the app client at the AWS side - when I replaced the list with a single item, and had the client refer to the single item, it worked. Otherwise, I got the redirect_uri error mentioned.

[TranquilMarmot]

I've tried it with the clientID:clientSecret base64 encoded as the Authorization header with no luck. How would I go about using the Implicit Flow? What's the difference?

[Andrew]

I noticed that AWS API Gateway will throw an "unauthorized" error if the redirect URI is not accessible. Now that I think about it, trying to use localhost may be a problem. Think about it ... AWS would need to redirect to that page but it can't because localhost is on your local machine. I would try a non-localhost URL to see if that is causing the problem.

[Andrew]

Here is info about the differences between authorization code flow and implicit flow: stackoverflow.com/questions/16321455/…

[Andrew]

If you want to use Implicit Flow, then it is similar to what you just did except the last step is not needed. Instead, you would receive the token from the first request. It is provided in what is known as a URL fragment. The URL fragment can only be read by browsers. This fragment contains the token(s).

[rioastamal]

You saved my day. The redirect_uri should be exactly the same as we define in Cognito console

[kiran01bm]

concur to what @rioastamal says. Trailing slash isnt needed but the redirect_uri should be exactly the same as defined in the User Pool for "Callback URL(s)" ex: https://**DOMAINPREFIX**.auth.**REGION**.amazoncognito.com/o‌​auth2/token?grant_ty‌​pe=authorization_cod‌​e&client_id=**CLIENT‌​ID**&code=**AUTHORIZ‌​ATION_CODE_OBTAINED_‌​FROM_oauth2/authoriz‌​e_ENDPOINT**&redirec‌​t_uri=**CALLBACK_URL‌​_CONFIGURED_IN_USERP‌​OOL**

[hwkd]

@kiran01bm lol this was the issue with my configuration. Thanks for pointing it out. I can finally go to sleep...

[abumalick]

or make sure responseType is code when using Authorization code grant

[Timo Huovinen]

This is so random and not documented in amazon cognito, thank you a lot! This is true for custom domains and urls too: https://example.test/login/