Support for JWT via discovery without x5c

[iperdomo]

In the available documentation Sample Configuration for OAuth 2.0 JWT Token Validation, there is a comment: -- The jwks endpoint must provide a x5c entry

I just hit an issue when trying to validate a token:

2017/02/10 09:44:04 [debug] 7#7: *2 [lua] openidc.lua:411: openidc_jwks(): Response data: {"keys":[{"kid":"YDAkh8zPFq5KdfnqtZZlpVG2fajlLzAcqh7BmV289JE","kty":"RSA","alg":"RS256","use":"sig","n":"qT3Lnddxydyj1-clZwcsFVisAEgglHMQbcJgozhlDC3vHFV2b_-xIqEEQtC56CgdPGe4LVwDBcNOp5a23OheVPzaTAdr2JwNqVg8Oeen0ba2ca-fBySXJyUEP2qmlIW5Ar7kexqRT-LhGCCf3iA3Bjs2o_PIH5Eu5V3AaubnZO1hqni7VVHpF0QdLmfVCBWK6FoxrEqedRuPFHLoX4GF3tUTk-drPoEwe3Tf_J6UICAp1QaRr-hGVyKsIf0gjru8ArzFcLfZuH21ZJJ6QWuFGCFFe90KCWC3LdTzyYB5byq3z915E9MeEH0zraTPCs0_OelzuzjpUVQQsy6BNJwEww","e":"AQAB"}]}
2017/02/10 09:44:04 [debug] 7#7: *2 lua resume returned 2
2017/02/10 09:44:04 [error] 7#7: *2 lua entry thread aborted: runtime error: /usr/local/openresty/luajit/share/lua/5.1/resty/openidc.lua:458: attempt to index local 'x5c' (a nil value)
stack traceback:
coroutine 0:
	/usr/local/openresty/luajit/share/lua/5.1/resty/openidc.lua: in function 'pem_from_jwk'
	/usr/local/openresty/luajit/share/lua/5.1/resty/openidc.lua:694: in function 'bearer_jwt_verify'
	access_by_lua(nginx.conf:73):22: in function <access_by_lua(nginx.conf:73):1>, client: 172.17.0.1, server: , request: "GET /api HTTP/1.1", host: "localhost:8082"

There is TODO entry to check the x5c length at https://github.com/pingidentity/lua-resty-openidc/blob/v1.3.0/lib/resty/openidc.lua#L457

Our provider implementation don't expose this key, and it seems that google certs also don't expose a x5c property in their certs:

• https://kc.akvotest.org/auth/realms/akvo/protocol/openid-connect/certs
• https://www.googleapis.com/oauth2/v3/certs

I was wondering why x5c is a requirement for validation? I wouldn't like to hardcode the cert in the nginx.conf so I was trying to get the public cert via discovery. (Perhaps i'm missing something)

[zandbelt]

Discovery is not yet part of (standard) Auth 2.0, see also:
#24 (comment)

The author of this feature has added it for usage with Azure AD which supports x5c.

As indicated in the comment linked to above, it would be nice to have support for other-than-x5c JWK representations. Unfortunately that depends on lua-resty-jwt implementing that, see:
https://github.com/SkyLothar/lua-resty-jwt/blob/master/lib/resty/jwt.lua#L607

Perhaps worth checking there.

[zandbelt]

the latest commits to the master branch have addressed this: JWKs with RSA keys represented with "n" and "e" element are now also supported