JWT support should implement aud, exp and nbf

[optnfast]

Background

https://tools.ietf.org/html/rfc7519#section-4.1 lists several registered JWT claim names, among them:

• nbf and exp which provide lower and upper bounds for the time range in which a JWT is valid
• aud which binds the JWT to a particular audience.

Use of the claims is optional (i.e. they need not appear in a JWT) but honoring them is a MUST if they are present.

The OPA JWT support currently does not act on any of the claim names. It's possible to check them in rego, although it's a bit of a performance due to them being optional (and I've not yet attempted to handle the annoying special case where aud is a string rather than a list).

OPA Support for exp and nbf

The point of this issue is to that support for these the time claims should be transparently built into the OPA JWT support. Specifically, io.jwt.decode should check them against the current time and error if it is after exp or before nbf.

The main reason in favor is, of course, that it means that it becomes impossible to accidentally implement a non-compliant JWT parser in rego (whether by getting the rego wrong or simply neglecting to implement nbf and exp).

The possible argument against is that this creates a backwards incompatibility. But it only creates an incompatibility for systems that do not fully comply with the JWT spec, and more rational way of viewing the change is that it fixes a vulnerability in such systems.

OPA support for aud

This is slightly trickier since the desired audience must be specified somehow; adding support to io.jwt.decode would be more disruptive. I'm not sure what the best way to proceed is.

[tsandall]

The io.jwt.decode function was not intended to perform any kind of validation, e.g., it doesn't even check the signature.

I think we could add an io.jwt.decode_and_verify built-in that implements RFC and best practices.

For example: io.jwt.decode_and_verify(str, {"alg": <identifier>, ...}, [header, payload, signature]) where the second argument identifies the signature algorithm and contains scheme specific params like PEM-encoded certificate or shared secret.

It would be good to include a separate io.jwt.verify_claims or similar so that users can still easily verify claims like nbf and exp when they aren't using the wrapper.

WDYT about starting here and dealing with the aud once we have more data?

[optnfast]

That seems reasonable. Expect an initial PR for discussion in a bit.

[tsandall]

hey @optnfast, have you made progress on this ticket? If not, I'd like to assign this to someone else to work on. Let me know. Thanks!

[optnfast]

Yes I have. My current work can be found at: https://github.com/optnfast/opa/tree/jwt

I also made a start on adding support for delivering keys via a JWK set. It might be better to treat that as a separate issue though?

(Apologies for the radio silence, I spent a while making rapid progress but then had to put things down for unrelated reasons.)

[tsandall]

@optnfast that sounds like a good candidate for another PR. If you'd like, feel free to open an issue to track it.

[optnfast]

I've not made any further progress on JWK set support yet, I'll revisit that with a fresh PR sometime as you suggest.

[tsandall]

Fixed by #967