HS256 options uses opts.secret instead of opts.client_secret

[web-seriesx]

It looks like line 628 should refer to opts.client_secret instead.

[zandbelt]

Technically lua-resty-openidc does not support HS256 for OpenID Connect yet (yes, it should probably mention that somewhere), only RS256.

The opts.secret option is used in OAuth 2.0 scenario's, see the sample config for that in the README.md: https://github.com/zmartzone/lua-resty-openidc/blob/master/README.md#sample-configuration-for-oauth-20-jwt-token-validation

It would not be too difficult to start supporting HS256 using the client_secret for OpenID Connect scenario's so we'll keep this issue as an enhancement request for that.

[web-seriesx]

Why not throw an error for non-RS256 usage until it is supported? That will make it impossible to miss.

[zandbelt]

In fact before 1.5.0 lua-resty-openidc did not check the signature, which is allowed when retrieving the id_token directly from a TLS protected server endpoint that has a valid SSL server certificate.

So to be backwards compatible I've added a suggested patch in e100ac2 , whilst still enforcing RSA signature validations because that's what we can support and is what OpenID Connect certification requires.

@bodewig and @web-seriesx please review.

[zandbelt]

@bodewig I see CI fails in that new branch because you already added checks for successful HS256 validation so perhaps we should start supporting that properly.

[bodewig]

this is because signature verification of the access token and the id token now use the same code path.

When I wrote the test for d token verification I had missed the fact that the secret used for id tokens is supposed to be the client secret and not another shared secret. I'm certainly in favor of supporting HS256 properly and can take a stab at it the coming days (unless you'd be able to get there first).

[zandbelt]

I took a quick look but it is not as straightforward as I hoped since one needs to find out whether the secret is can be used to validate the JWT that is passed in (since it can be a statically configured RSA key in the access token case), or else trigger discovery when available.

[bodewig]

yes, we'll need to look at the algorithm and use opts.secret for RS* (falling back to discovery) or when verifying an access token. opts.client_secret should only be used if it is an HS* signature and we are verifying the signature of an id token.

[zandbelt]

I guess an explicit input parameter secret would be good for this. I would also like to restore backwards compatibility for unknown/unsupported algorithms: they can just be accepted in OIDC flows just like "none" can.

[zandbelt]

another thing to be aware of: for proper HS256 support, lua-resty-jwt requires https://github.com/jkeys089/lua-resty-hmac rather than the one provided ootb by luarocks...

[bodewig]

It looks as if lua-resty-jwt was shipping hmac.lua as part of its own rock, so it should be available.

[bodewig]

I think bodewig@47eea01 does what we want.

• always use opts.secret or discovery when verifying an asymmetric signature (where we support the algorithm)
• use opts.secret for access tokens and opts.client_secret for id tokens when verifying an symmetric signature (where we support the algorithm)
• accept id tokens (but log a warning) if we don't support the algorithm
• regard access tokens as invalid if we don't support the algorithm

I have not amended the ChangeLog and not created a PR, yet, as I wanted to be sure this one is complete.

[zandbelt]

pretty close indeed; I do think it is somewhat awkward that in the OAuth scenario where a static public key is configured in opts.secret, opts.secret is passed in as the symmetric_key parameter value and then discarded for opts.secret again when the JWT is signed with an assymetric key, right?