Module 6 of 9 · Lesson 16 of 26

Validate JWTs and resolve the current user

Work through validate JWTs and resolve the current user using a runnable reference, a focused regression check and a local extension.

Read in any order. All lessons stay open, including after an unanswered or incorrect check.

In this lesson you will validate JWTs and resolve the current user. Work with the Equipment Rental API in the downloadable lab. The reference is a complete solution with separate lesson checks, so you can inspect the answer, make a deliberate local change and verify its behavior.

A JWT is a signed set of claims, not encrypted storage for secrets. The reference issues a short-lived token containing a UUID subject, issue time, expiry, issuer and audience. Validation explicitly allows HS256 and requires those claims. It rejects expired tokens, wrong issuers, wrong audiences, unexpected algorithms and malformed subjects.

After validating the signature and claims, identity loads the current user from the database and checks active state. It derives the role from the current record, rather than trusting an old token to preserve a privilege grant forever. A valid signature alone is not permission to perform every action. Missing or invalid authentication returns 401; the next lesson handles 403 for a valid identity denied by policy. The symmetric key is supplied by local configuration and has no committed value. Production key rotation, revocation strategy and identity-provider integration need their own design. Do not include passwords or hashes in claims, log bearer tokens, or choose an algorithm from untrusted token headers.

Worked source: equipment/security.py, token_subject.

Run lesson16. It accepts a correctly issued token and rejects five distinct invalid cases: expired, wrong audience, wrong issuer, malformed UUID and HS384. Read the options.require list. Then follow identity in api.py to the database lookup that resolves current active state and role.

pythonCopyable

def token_subject(token, key):
    try:
        claims = jwt.decode(
            token,
            key,
            algorithms=["HS256"],
            issuer=ISSUER,
            audience=AUDIENCE,
            options={"require": ["sub", "iat", "exp", "iss", "aud"]},
        )
        return uuid.UUID(claims["sub"])
    except (jwt.InvalidTokenError, ValueError, TypeError, KeyError) as error:
        raise DomainError(
            "unauthenticated", "A valid, unexpired token is required.", 401
        ) from error

TerminalPython 3.13 virtual environment; Docker running; extracted lab directory

python run_checks.py -k lesson16

Expected result The selected lesson test passes against a new temporary PostgreSQL database; the container is removed afterward.

Keep for reference

Equipment Rental lab and lesson checks

ZIP containing Python source, real Alembic migrations, 26 lesson checks, a dependency lock and text instructions. Extract it before following the local exercise.

Download Equipment Rental lab and lesson checks

Practise locally

Add a request test that signs in a synthetic user, marks that user inactive in the disposable database and tries to read a protected rental with the previously issued token. Require 401. Add a missing-expiry token test. Explain which checks establish identity and which later checks decide permission.

The lesson check verifies the reference behavior. Add your own assertions for your change. Local practice is not uploaded or scored by this learning release.

Pause and reflect

What failure does this lesson prevent, and which assertion in lesson16 would expose it?

Use a concrete input, expected result and limitation from your local work. Saving a reflection does not certify the project.

Optional knowledge check

A token has a valid signature but the wrong audience. What should happen?

Reject it as invalid authentication.

Correct. The token was not issued for this API audience, even if its signature verifies.

Accept it because signatures make issuer and audience checks optional.

Try another answer. A signature alone does not establish that this API is the intended recipient.

Use the algorithm named by the token header without an allow-list.

Try another answer. The verifier must choose its allowed algorithms from trusted configuration.

This practice does not assess your project or award a certificate.

Your reading progress

Progress is saved in this browser when storage is available.