Feature jwt discovery validation

[hanikesn]

This patch adds easy verification of jwt tokens, via the JWKS from the discovery endpoint.

Please feel free to leave any suggestions.

[zandbelt]

this code is nice to have since it can be re-used for several scenario's, however:

1. technically Discovery is part of OpenID Connect and not (at least not yet) part of OAuth 2.0; since validation of access_tokens in the Resource Server role is pure OAuth and not OpenID Connect related, I would be interested to know which Authorization Servers already support Discovery + jwks_uri in this "pre-standard" way
2. I believe that most RSA JWKs (at least on OIDC jwks_uri's today) would be represented using the n\e compact syntax as in https://tools.ietf.org/html/rfc7517#appendix-A.1 instead of using x5c; any chance you'd be willing to contribute support for that to lua-resty-jwt... :-0 ?

[hanikesn]

technically Discovery is part of OpenID Connect and not (at least not yet) part of OAuth 2.0; since validation of access_tokens in the Resource Server role is pure OAuth and not OpenID Connect related, I would be interested to know which Authorization Servers already support Discovery + jwks_uri in this "pre-standard" way

We're probably using it in a non-standard way to validate access_tokens which were created by the IDP in the first place.

I believe that most RSA JWKs (at least on OIDC jwks_uri's today) would be represented using the n\e compact syntax as in https://tools.ietf.org/html/rfc7517#appendix-A.1 instead of using x5c; any chance you'd be willing to contribute support for that to lua-resty-jwt... :-0 ?

I guess we're really fortunate that Azure Active Directory supports x5c. But I saw that e.g. Google does not. Maybe I can come up with a solution, it's just that OpenSSL isn't exactly easy to work with.

[hanikesn]

I took a closer look at supporting modulus and exponent format directly and it would basically mean writing a small ASN.1 DER encoder for:

RSAPublicKey ::= SEQUENCE {
    modulus           INTEGER,  -- n
    publicExponent    INTEGER   -- e
}

As the Integers are quite big some kind of big int support is probably also needed.