Token validation checks whether an access token has the right format, is unexpired, carries a valid signature, and satisfies other validity conditions. It establishes that a request presents an authentic token before authorization checks decide what the identity may access. section 7.1 section 4.4
JWTs are only as secure as their validation process. Accepting a tampered, unsigned, or expired token can let an attacker impersonate another user, escalate privileges, or access sensitive data. Validation must therefore happen on every request, preferably in server middleware. section 8.3 section 8.7
A secure validation process should:
- Constrain the accepted signing algorithm instead of trusting the token header’s alg field. section 8.3 section 8.7
- Verify the signature with the correct shared secret or public key, and reject unsigned or expired tokens. section 4.4 section 8.3
- Check all relevant claims, including the expected audience and issuer, rather than treating a valid signature as sufficient. section 8.7
- Use a robust JWT library and test it against none-algorithm and algorithm-confusion examples. section 8.3 section 8.7
Validating an API request
A healthcare API first validates the access token on every request. It then checks whether the identity has the required role or scope and may verify access to the particular patient resource. A doctor, receptionist, and patient can therefore receive different permissions even when all present valid tokens. section 7.1
With an OpenID Connect provider, obtain integration details from the discovery endpoint and locate signing keys through the JWKS endpoint. Use the token’s kid value to select the key, then validate the signature with the resulting public key. section 8.4 section 8.7
