0
votes

I'm attempting to use Postman (Version 7.20.0 - linux 5.5.8-200.fc31.x86_64 / x64)to authenticate using the OAuth2.0 "Authorization Code" flow against a Keycloak 9.0.0 server, backed by Google as an IdP.

Postman is sending the following to the .../token endpoint when trying to exchange the code for the access/refresh tokens:

grant_type:    authorization_code
code:          4/xgFPM8rkZXA1pWguPMHPKg8GS3BrI7whtmSq2U2K4_4Cy62m10y2l3IQp3KuiLRyaLaZWKCUiGJGEWVJ9K4zcTc
redirect_uri:  http://localhost:3002
client_id:     mission-control
client_secret: 3cc09c80-••••-••••-••••-••••••••

This fails in Keycloak with the following error, confirmed in the Postman console:

POST /auth/realms/test-realm/protocol/openid-connect/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
User-Agent: PostmanRuntime/7.23.0
Accept: */*
Cache-Control: no-cache
Postman-Token: f2cfc8be-a911-4bc6-b5be-dbfab46d3a56
Host: localhost:8080
Accept-Encoding: gzip, deflate, br
Content-Length: 246
Connection: keep-alive
grant_type=authorization_code&code=4%2FxgFPM8rkZXA1pWguPMHPKg8GS3BrI7whtmSq2U2K4_4Cy62m10y2l3IQp3KuiLRyaLaZWKCUiGJGEWVJ9K4zcTc&redirect_uri=http%3A%2F%2Flocalhost%3A3002&client_id=mission-control&client_secret=3cc09c80-••••-••••-••••-••••••••
HTTP/1.1 400
Connection: keep-alive
Cache-Control: no-store
Pragma: no-cache
Content-Type: application/json
Content-Length: 62
Date: Fri, 13 Mar 2020 08:36:02 GMT
{"error":"invalid_grant","error_description":"Code not valid"}

Keycloak logs show that this token has the wrong format:

keycloak_1  | 09:53:23,219 WARN  [org.keycloak.protocol.oidc.utils.OAuth2CodeParser] (default task-35) Invalid format of the code
keycloak_1  | 09:53:23,219 WARN  [org.keycloak.events] (default task-35) type=CODE_TO_TOKEN_ERROR, realmId=Test Realm, clientId=mission-control, userId=null, ipAddress=172.20.0.1, error=invalid_code, grant_type=authorization_code, client_auth_method=client-secret

To check whether Keycloak, or Postman was at fault I walked through the same steps on the CLI with the help of Netcat:

On the CLI, with help of netcat I can walk through the flow successfully, and I see a different token format:

  1. Start a netcat server to catch the callback from the browser window: $ nc -lk localhost 3002

  2. Open this in my browser http://localhost:8080/auth/realms/test-realm/protocol/openid-connect/auth?client_id=mission-control&redirect_uri=http%3A%2F%2Flocalhost%3A3002&response_type=code&scope=openid

  3. Click through the login flow with Google as the provider.
  4. The netcat server will receive something like this GET /?code=3b9ac786-f9d1-40f9-b884-35e17b2fa756.70a3be09-8edf-47ed-9803-d08550a07faa.8794bba2-6f2b-4512-8bd7-6d5073852d1c (and more)
  5. I can exchange this code for tokens successfully: curl -XPOST -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=authorization_code&code=3b9ac786-f9d1-40f9-b884-35e17b2fa756.70a3be09-8edf-47ed-9803-d08550a07faa.8794bba2-6f2b-4512-8bd7-6d5073852d1c&redirect_uri=http%3A%2F%2Flocalhost%3A3002&client_id=mission-control&client_secret=3cc09c80-48bc-46fd-bc91-232e6bbb681a" http://localhost:8080/auth/realms/test-realm/protocol/openid-connect/token

I don't know where the Postman OAuth flow is getting the "code" out of the response body, which it uses to send to the token exchange endpoint The difference in the tokens is clear, when walking through it by hand (same client, same token, same oauth2 server) then the code loosk like:

3b9ac786-f9d1-40f9-b884-35e17b2fa756.70a3be09-8edf-47ed-9803-d08550a07faa.8794bba2-6f2b-4512-8bd7-6d5073852d1c

When using Postman, it's sending this as the code:

4/xgFPM8rkZXA1pWguPMHPKg8GS3BrI7whtmSq2U2K4_4Cy62m10y2l3IQp3KuiLRyaLaZWKCUiGJGEWVJ9K4zcTc

What can I do to make postman take the callback ?code form the URL?

1
Are you able to raise this as an issue on the Postman Issue Tracker, please? Just so that it's directed at the folks who can investigate the behaviour github.com/postmanlabs/postman-app-support/issuesDanny Dainton
Doing it now, thanks @DannyDaintonLee Hambley
Postman has the console, where you debug queries learning.postman.com/docs/postman/sending-api-requests/… Try it and find what and how is postman sending auth request.Jan Garaj
If it wasn't clear from the write-up, I did that, but the Postman console does not show the HTTP requests for the browser popover, so I can neither see the URL that postman is requesting in the flow, nor the response (to check that it has a code that makes sense). The only request shown in the postman console is the failing POST to the token exchange endpoint.Lee Hambley

1 Answers

2
votes

This is a confirmed bug in Postman when both the callback_uri and the token OAuth server endpoints are on the same (localhost) domain.

Update: This issue was fixed in September 2020.