AWS Cognito OAuth2 401 Unauthorized

[babus]

Describe the bug AWS Cognito's OAuth2 is adding temporary header Authorization with "Bearer" prefix in the header value. This results in 401 Unauthorized as AWS doesn't expect the "Bearer" infront of the token.

To Reproduce Adding screenshot.

Expected behavior The Authorization token should be customizable using the pre-request script or so.

Screenshots

App information:

• Native App
• Postman v7.3.4
• OS: Both Windows and Mac

[vikiCoder]

Hi @babu-upcomer we are exploring some ways to improve OAuth2 flow in Postman app, we will consider this for the same. No ETA as of now but will update soon as and when we are ready.

[babus]

@vikiCoder OK. Isn't this so primary? Simply letting the users to customize the temporary headers(at-least the Authorization) inside the pre-script would solve the problem for now.

[babus]

Because right now, our team is using graphQL against AppSync endpoint. This particular issue is blocking us and leaving the Postman useless to our team. I hope that I stressed this enough to convey that this could be the app killer and let the developers to look for alternates. I'll leave the rest to your internal priorities.

[azarboon]

Also I have this issue. If I authenticate using postman, automatically it adds "Authorization" (caps lock) and value has "Bearer" prefix. And requests become unauthorized. I need to manually add "authorization" header (no caps lock) and rove bearer from token.

This makes postman useless for our case. Can you please fix this?

[slehman1803]

Please fix this problem in the OAuth 2 functionality. Cognito returns 2 tokens. One is called "Access Token" and the other is called "id_token". The "id_token" can be used as a normal Bearer Authorization token. Postman grabs the "Access Token" which I guess wants to be in a header called "authorization" with no "Bearer" prefix. Postman needs to offer a better OAuth2 experience anyway like storing multiple OAuth2 endpoint configurations. And how and which token to use and whether to use "Bearer" are good configuration options.

Please fix it.

[marcelloromani]

which I guess wants to be in a header called "authorization" with no "Bearer" prefix.

I did some tests setting the header manually. At the time of writing I can successfully call the API GW endpoint with the following headers:

• Name: authorization Value: <id_token>
• Name: Authorization Value: <id_token>
• Name: authorization Value: Bearer <id_token>
• Name: Authorization Value: Bearer <id_token>

None of those configuration work if I use the <access_token>

Regarding the behaviour of Postman, what happens is that when I select Authorization ==> OAuth 2.0 ==> Get New Access Token I can successfully login and Postman detects both access and id tokens, but when clicking Use Token the access_token is used, which as reported above isn't recognised thus giving 401 unauthorized when trying to access the Cognito-protected API GW endpoint.

I have two questions at this point:

• is there some Cognito / API GW configuration that I need to change in order to make access_token work as well as the id_token?
• Should Postman behaviour change, e.g. pick the id_token instead, or at least offer an option to select which token to select when the "Use token" button is clicked?

Solution (answer to my own question)

The key detail is scopes

id_token doens't have a scopes entry, therefore works only if in the API GW methdo the OAuth Scopes field is left at NONE.

access_token has a scopes entry, which is set during the token generation request and can contain one or more values. Those values are checked against the values set in the OAuth Scopes field in API GW. If the intersection is not empty, then access is granted.

Conclusion

I think Postman does the right thing in using the access_token. The API GW endpoint must be correctly configured with the appropriate scopes in order for the access_token to work, which is by design (as far as I can tell).

An example that would work pretty much out-of-the-box would be to include the openid scope in the API GW OAuth Scopes settings. The reason is this is one of the scopes that all the Cognito / API GW tutorials recommend checking.

Update

The key bit in the documentation is:

https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-enable-cognito-user-pool.html

With the COGNITO_USER_POOLS authorizer, if the OAuth Scopes option isn't specified, API Gateway treats the supplied token as an identity token and verifies the claimed identity against the one from the user pool

[giridharvc7]

We've fixed this, can you check and let us know if this solution works for you?

[wentutu-pass]

We've fixed this, can you check and let us know if this solution works for you?

Can I use id_token/refresh_token as a variable in Pre-request script? Actually, I found how to use Access Token as a variable. pm.request.auth.oauth2.get('accessToken') but I can’t find way to use id_token/refresh_token as an variable in Pre-request script. Is there no way?