Is there an option to handle the userinfo response as JWT, not as JSON ?

[AramshamFedaykin]

Environment

• lua-resty-openidc version (e.g. 1.7.2)
• OpenID Connect provider OpenAM (ForgeRock)
• Kubernetes ingress-nginx 0.34.0

Expected behaviour

According to this spec : https://openid.net/specs/openid-connect-core-1_0.html#UserInfo in the point 5.3.2, the response of the userinfo endpoint can be a JWT, not only a JSON, determined by the content-type.

Actual behaviour

The userinfo returned is null as there a json parsing, and it's not a json. Is there an option to keep the userinfo response as JWT (RAW and decoded) instead of json ? The purpose would be to do some authZ checks and then fwd the jwt in a header.

Configuration and NGINX server log files

• 2020/07/23 14:23:28 [debug] 13256#5356: *8 [lua] openidc.lua:615: call_userinfo_endpoint(): userinfo response: ${JWT here}
• 2020/07/23 14:23:28 [error] 13256#5356: *8 [lua] openidc.lua:1134: authenticate(): error calling userinfo endpoint: JSON decoding failed, client: 127.0.0.1, server: _, request: "GET /.../authorization-code/callback..."

[bodewig]

No, the current openidc.call_userinfo_endpoint only supports an unsigned and unencrypted plain JSON response.

[realnate]

Hello. I created a pull request to fix this issue #508

From the PR...

This resolves issue #345. When the userinfo endpoint returns a JWT instead of JSON as identified by the Content-Type header of application/jwt then the userinfo response is validated and used. A unit test covering this case was added and existing unit tests were not broken.

I also tested this change using Keycloak with the "User info signed response algorithm" option set to "RS256". When set to "None" (the default) it succeeds, when set to "RS256", fails in the same manner reported in #345, userinfo is null and an error is logged "openidc.lua:1172: authenticate(): error calling userinfo endpoint: JSON decoding failed". With these changes, userinfo is now not null and the error is no longer present.

[realnate]

@bodewig is there anything further needed to review and merge the associated pull request?

[realnate]

@zandbelt I reached out to Bodwig. He is busy and doesn't have any time free to look at this. Can you look at the PR to resolve this item?

[zandbelt]

seems quite easy to merge indeed, but I'm guessing you'd want a new release as well...?

[realnate]

A release would be great because we are indirectly using this upstream via APISIX's OpenId-Connect plugin (https://apisix.apache.org/docs/apisix/plugins/openid-connect/). For this to go live in my scenario the APISIX folks would have to pick up a new release (I do not know yet if that would be automatic or if I need to do an issue and/or PR for that as well).

I personally have a workaround in place overwriting the openidc lua file with the version from the PR so it isn't super urgent if it could be combined with any other work you all have going on.

[zandbelt]

merged it so it will be in the next release, but I really don't know when that will be