JWT client token validation

[c0c0n3]

@gboege needs refinement.

[gboege]

Extract the DAT-JWT from header-Header Object and validate it with the CA public key (included in the provided cert files) They have issued and signed the DAT-JWT

[c0c0n3]

Implemented by PR #12 even though it should've been done in a separate PR---see note there about it.

For the record, we validate the input JWT data and verify its provenance using a configurable RSA public key. We make sure the following is true:

• the JWT data is well-formed;
• the token got signed with the private key paired to the configured pub key;
• if present, exp ("expires at") contains a date in the future;
• if present, iat ("issued at") contains a date in the past;
• if present, nbf ("not before") contains a date in the past.

Notice that at the moment if any of the above standard claims (i.e. fields exp, iat, nbf) gets set to 0, we just ignore that field during validation, so e.g. this token

{ alg: RS256 }.{ exp: 0 }.valid-rs256-signature

passes validation with flying colours even though it expired at the beginning of the epoch! We have an issue about this, see #14.