Default private_key_jwt chosen without client_rsa_private_key

[XA21X]

The token_endpoint_auth_method setting defaults to private_key_jwt based on the discovery result from a default Keycloak client configuration. Keycloak discovery is correct as the realm does support private_key_jwt but the default Client Authenticator is only Client Id and Secret.

I briefly dug through the Keycloak source code and it seems like it just builds a list of all supported auth methods via dependency injection, which makes sense after second thought, because the discovery URL is at the realm level, while the auth method is set at the client level.

The new version of lua-resty-openidc tries to use private_key_jwt even when client_rsa_private_key has not been manually set, which can break old configurations on upgrade.

If my understanding is correct, I suggest only using private_key_jwt when client_rsa_private_key is set, and possibly improving error handling so the error from lua-resty-jwt isn't as cryptic.

Environment

• lua-resty-openidc v1.7.0-2? (w/ uncommitted modifications for traefik-idc)
• Keycloak v4.7.0

Expected behaviour

Version 1.7.0-2 should be fully compatible with configuration that was working for version 1.7.0.

Actual behaviour

2018/12/17 11:42:23 [error] 9#9: *1 lua entry thread aborted: runtime error: unknown reason
| stack traceback:
| coroutine 0:
|        [C]: in function 'error'
|        /usr/local/openresty/site/lualib/resty/jwt.lua:501: in function 'sign'
|        /usr/local/openresty/site/lualib/resty/openidc.lua:459: in function 'call_token_endpoint'
...

Please note that the line number doesn't match because I happen to be testing with my own fork :P
The error message being cryptic is what I'm trying to show rather than the stack trace. The equivalent line number in the current master branch for lua-resty-openidc is line 441.

Workaround / Solution

Explicitly specify the old behaviour/auth method:

opts.token_endpoint_auth_method = "client_secret_post"

[bodewig]

Maybe supported_token_auth_methods's values could be functions that verified preconditions on opts, for client_secret_jwt we'd require client_secret to be set.

I'll take a stab at it later.