What to validate 'iat' and 'sub' claims of a JWT against?

I am writing an SSO authentication server in Node.js and Express, using JWT for authentication. I've been reading up from articles from sources like Auth0 on how to better secure my JWTs. I've been able to include and validate most of the standard claims on a token, but I'm wondering what exactly to validate the 'iat' and 'sub' claims against.

For 'iat', when a token is passed to an Express route and that route begins to check the authentication status of a user before performing any sensitive operations, what is the best practice for providing a value to validate this claim against? My best guess was to pull out the userId from the token, before verifying the signature, and then comparing it to an 'iat' value which would be stored in the users table, but this doesn't seem right.

For 'sub', with a stateless server, how is the app supposed to know which user's 'sub' claim to expect and validate against, if the app gets its user information from the validated token itself?

Or am I understanding these use cases incorrectly? The purpose of this server is to provide authentication for the content inside this app itself, as well as other apps.

Solution

In order for JWT to work, the consuming application must be able to trust the SSO/JWT issuing server. When the issuing server generates a token and the cryptographic signature has been validated, the claims are inherently true. You should still validate all inputs in the token to check they are reasonable.

A claim like iat is the issuing server recording the time that it generated the token. Assuming it's a valid sensible time (not 1970) then the fact that the issuing server stated that and signed it it can be considered as fact.

Note: The header alg and typ values should always be validated as matching the values from the issuing server before validating the signature.

Issued at

iat: Identifies the time at which the JWT was issued. The value must be a Numeric Date.

Possible Validation:

Is a valid positive integer
Is in the past
Check this newer than you last security incident (quickly revoke all possibly compromised tokens)

Subject

sub: Identifies the subject of the JWT. (This is the user/name/user identifier)

Possible Validation: - It exists, not empty - The user exists and not locked etc in the database. (optional depending on how stateless you are going)