Silent failure when id_token returned as query parameter

[andyMyersIBM]

If the OAuth OIDC provider returns an id_token as a query parameter, rather than as a fragment, in the Location header, then the test tool returns silently, providing no error or log information.

[sozkan]

@zandbelt I reviewed the code and I believe that this needs to be fixed in pyoidc. pyoidc parses the response and throws a generic error without providing any details about the root cause.

[zandbelt]

@tpazderka would you agree?

[tpazderka]

Could be. Do you have more details? Which particular test/endpoint causes this?

This will probably need a fix here as well, once the error is more specific/different, it might need to be caught properly, but that depends.

[sozkan]

Reproduction steps:

• Log in to docker_op_1 docker exec -it docker_op_1 /bin/bash
• Edit lib/helpers/redirect_uri.js and disable fragment mode, for example change case 'fragment' to case 'fragmentX' so that the fragment mode is not invoked and response will be always returned in query.
• Stop docker_op_1 docker container stop docker_op_1 (do not rebuild it or your changes will be lost)
• Start docker_op_1 docker container start docker_op_1
• Go to https://op-test:60003 and change configuration to enable Implicit(id_token) response type
• Run OP-Response-id_token test. You will be returned to tests lists without any errors.
• Check op-test logs

  
  2019-05-02 13:55:16,668 oic.oauth2:DEBUG request: <class 'oic.oic.message.AuthorizationRequest'>
  2019-05-02 13:55:16,669 cherrypy.access.139855459558736:INFO 172.20.0.1 - - [02/May/2019:13:55:16] "GET /OP-Response-id_token HTTP/1.1" 303 472 "https://op-test:60003/profile" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1 Safari/605.1.15"
  2019-05-02 13:55:18,692 cherrypy.access.139855459558736:INFO 172.20.0.1 - - [02/May/2019:13:55:18] "GET /authz_cb?id_token=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6InIxTGtiQm8zOTI1UmIyWkZGckt5VTNNVmV4OVQyODE3S3gwdmJpNmlfS2MifQ.eyJzdWIiOiIxZjc5MTkwYy1hOTM0LTQyMzktOGZiZS1lNmRhYTZhZDAwNGUiLCJub25jZSI6ImJUUGJqUFloQTF4M0VKRjciLCJzaWQiOiJjMzVlOTc5YS1mMzk5LTQ2OGYtODBjOC00NDczOGUxZWI4ZDUiLCJzX2hhc2giOiJHc1BsRjhMZzU4aElJcFRDUUNRRnFBIiwiYXVkIjoiNzUzMTk4NDYtNjVjMi00NTcwLWEzNzYtNjY0ZmZhNGE5NzMzIiwiZXhwIjoxNTU2ODA4OTE4LCJpYXQiOjE1NTY4MDUzMTgsImlzcyI6Imh0dHBzOi8vb3A6NDQzMyJ9.VGBaPmfIa4G-KQxSN2j4SUQ7_SdCNKCCvCzSMTY6rinGUUi-wKT80DkxKpNIF60tdniP-tgVqvuHlxFcEgND9mqlFE6udRDKkEgaQdSFC6OZlJG5LjDrbjPStZnxF41CYgRsgb10_tV-X13jDDjlPuTPbiX2AsYL3aCOLEYx-JKv9JKBHZZUUinfk9Y5S5VkqQJuwkSUd6DU9-HRpoLUMDVv9X6H43JkAPdUF5VmdRCPK8_XaAu7rBI0B09AImY_jqO70ny7Ur1MmvcDCxWpY5AmXRLvSSTX5HKuC2RaOn--fO-Gj_4stE8sGsbNYI5PK9pncOB-DuPFfpzOoY73rA&state=aQZsCyd0fJLZ15eP&session_state=182e9c2244a8ab1ab5b3edec3f9fda5f4555a6e51ec1cd7f405e48a8858a23ed.a9abd5edcbd7f785 HTTP/1.1" 200 545 "https://op:4433/interaction/51287597-2534-41cd-90e0-d42c3515b6d2" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1 Safari/605.1.15"
  2019-05-02 13:55:18,723 otest.aus.tool:INFO <--<-- 3 --- <class 'oidctest.op.oper.AsyncAuthn'>
  2019-05-02 13:55:18,723 otest.aus.request:INFO Response: x
  2019-05-02 13:55:18,724 oic.oauth2:DEBUG Initial response parsing => "{}"
  2019-05-02 13:55:18,724 oic.oauth2:ERROR Missing or faulty response
  2019-05-02 13:55:18,724 otest.handling:ERROR [run_sequence] ExcList: Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/otest-0.7.3-py3.6.egg/otest/aus/request.py", line 331, in parse_response
  keyjar=_conv.entity.keyjar  # , algs=algs
  File "/usr/local/lib/python3.6/dist-packages/oic-0.15.1-py3.6.egg/oic/oauth2/__init__.py", line 555, in parse_response
  raise ResponseError("Missing or faulty response")
  oic.oauth2.exception.ResponseError: Missing or faulty response

2019-05-02 13:55:18,725 otest.handling:ERROR [run_sequence] Exception: Missing or faulty response

Note the origin of the error `"/usr/local/lib/python3.6/dist-packages/oic-0.15.1-py3.6.egg/oic/oauth2/__init__.py", line 555`.

[zandbelt]

thanks @sozkan; @tpazderka I hope this helps to create an enhancement

[tpazderka]

Not sure about this. I think that the behaviour of pyoidc is correct in this case, it raises a ResponseError indicating that it cannot parse the response (as it is not where it is expected). The otest code is catching it and than throwing the exception in the logs:

https://github.com/openid-certification/otest/blob/825649302b2b986670a2fc888ccf859d7c9fc7aa/src/otest/aus/request.py#L327-L337

It looks like it should rather return None instead of the error instance, but that is probably a question for @rohe.

[sozkan]

@tpazderka if pyoidc can log the actual error reason (i.e using query parameters instead of fragment) that would be a significant improvement. Without that all we have is a generic "Missing or faulty response" at best.

[tpazderka]

Pyoidc cannot actually know that. It parses whatever is in the info variable and the test suite passes an empty string, so the best it can give you is a Missing response (that would require adding a check for empty string - could be added as an enhancement) but I am not sure if that would help you much.

If you want to be more specific in the error response, you can probably do some detection here: https://github.com/openid-certification/otest/blob/825649302b2b986670a2fc888ccf859d7c9fc7aa/src/otest/aus/request.py#L305-L318

[sozkan]

Thanks for the clarification @tpazderka. It looks it can be handled in otest before it reaches pyoidc as you suggested.

[sozkan]

@tpazderka I just changed it to return None in case of an error, see below: https://github.com/sozkan/otest/commit/15eaa0094560ebf472b02a9dc563b6e707094a10

After the above change, some tests started to return stack traces, so I made another change. https://github.com/sozkan/oidctest/commit/4a76abc847f60b2160b9c05afa8580130bbcd4a1

Now I have one more issue, now during VerifyResponse check last_protocol_response returns a RegistrationResponse, because I guess None is not added as a protocol response and last protocol response is the registration response. For example if you run OP-claims-auth_time-essential with the above changes, you get the following error which is not technically the right check.

verify-response: status=ERROR, message=Got a RegistrationResponse response !? [Checks that the last response was one of a possible set of OpenID Connect Responses]

Looks like a small change but it leads to more issues. I don't have a specific question but would appreciate any tips.