What must the relying party check when it validates an ID token?

The signature (with the OP's key), that iss is the expected OP, that aud contains its own client ID, that the token has not expired (exp) and was issued recently (iat), and that the nonce matches the one it sent; optionally auth_time and acr against its policy.

In step 5 of the flow the RP must not simply decode the token and believe it. The checks, in a sensible order:

1. Signature: verify it with the OP's public key from the jwks_uri (or with the client secret for HS256), using the algorithm the RP expects, never blindly the one named in the header.
2. Issuer: iss exactly matches the issuer identifier from discovery.
3. Audience: aud contains the RP's own client_id. Otherwise the token was issued to another application and could be a substituted token.
4. Time: the current time is before exp; iat is not unreasonably old.
5. Nonce: if a nonce was sent, the claim equals the value stored in the user's session (anti-replay).
6. Policy (optional): auth_time is recent enough if max_age was requested; acr meets the required authentication level.

Only then does the RP read sub and establish its own session. When the token comes directly from the token endpoint over TLS, the specification allows TLS server validation to stand in for the signature check, but checking it anyway is common practice.

Go deeper:

• OpenID Connect Core 1.0: ID Token Validation — the complete normative checklist.
• JSON Web Token (Wikipedia): Vulnerabilities — the alg: none and algorithm-confusion attacks that careless validation allows.