Metadata-Version: 2.4
Name: multikeyjwt
Version: 1.8.0
Summary: Verify JWTs with multiple public keys, FastAPI middleware for auth
License: MIT
License-File: LICENSE
Author: Eero af Heurlin
Author-email: eero.afheurlin@iki.fi
Requires-Python: >=3.10,<4.0
Classifier: License :: OSI Approved :: MIT License
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.10
Classifier: Programming Language :: Python :: 3.11
Classifier: Programming Language :: Python :: 3.12
Classifier: Programming Language :: Python :: 3.13
Classifier: Programming Language :: Python :: 3.14
Provides-Extra: all
Provides-Extra: fastapi
Requires-Dist: click (>=8.0,<9.0)
Requires-Dist: cryptography (>=41.0)
Requires-Dist: fastapi (>0.89,<1.0) ; extra == "fastapi" or extra == "all"
Requires-Dist: libadvian (>=1.0,<2.0)
Requires-Dist: pendulum (>=3.0,<4.0)
Requires-Dist: pyjwt[crypto] (>=2.12,<3.0)
Project-URL: Homepage, https://github.com/pvarki/python-multikeyjwt/
Project-URL: Repository, https://github.com/pvarki/python-multikeyjwt/
Description-Content-Type: text/x-rst

===========
multikeyjwt
===========

Verify JWTs with multiple public keys, FastAPI middleware for auth

NOTE: Due to https://github.com/encode/starlette/discussions/2446 .env file is no longer
supported for configuration.

Verifying audiences
-------------------

Pass an expected audience explicitly when verifying a token::

    from pathlib import Path
    from multikeyjwt import Verifier

    verifier = Verifier(pubkeypath=Path("public-keys"))
    payload = verifier.decode(token, audience="service-a")
    payload = verifier.decode(token, audience=("service-a", "service-b"))

Audience matching follows PyJWT's case-sensitive string/list rules. A supplied
expectation requires a matching ``aud`` claim. Empty expectations are errors.
``decode(token)`` keeps its existing behavior: tokens without an audience work,
while a nonempty ``aud`` requires an explicit expectation. Audience verification
is never disabled implicitly. ``JWT_AUDIENCE`` configures issuing only; it does
not set verifier or middleware policy.

The verify command accepts repeated audience options::

    multikeyjwt verify -k public-keys/ --audience service-a < token.txt
    multikeyjwt verify -k public-keys/ --audience service-a --audience service-b < token.txt

FastAPI authentication
----------------------

Each dependency can set its own audience without changing the shared verifier::

    from fastapi import Depends
    from multikeyjwt.middleware import JWTBearer, JWTPayload

    async def endpoint(jwt: JWTPayload = Depends(JWTBearer(audience="service-a"))):
        return jwt

An Authorization header takes precedence over the cookie configured by
``JWT_COOKIE_NAME``. If a header is present but invalid, empty or uses another
scheme, authentication fails; it never falls back to a valid cookie. Cookies
are used only when the header is absent. Bearer scheme matching is case-insensitive.

Compatibility changes: headers now take precedence over cookies, and
``JWTBearer(auto_error=False)`` returns ``None`` for missing or invalid credentials.
The default still raises HTTP 403 on authentication failure. ``request.state.jwt``
contains the verified payload on success and ``None`` on failure. Routes requiring
header-only authentication must additionally reject requests without a header.

Creating signing keys
---------------------

.. code-block:: bash

    multikeyjwt genkey ./jwtsign.key

see --help for more info

Docker
------

For more controlled deployments and to get rid of "works on my computer" -syndrome, we always
make sure our software works under docker.

It's also a quick way to get started with a standard development environment.

SSH agent forwarding
^^^^^^^^^^^^^^^^^^^^

We need buildkit_::

    export DOCKER_BUILDKIT=1

.. _buildkit: https://docs.docker.com/develop/develop-images/build_enhancements/

And also the exact way for forwarding agent to running instance is different on OSX::

    export DOCKER_SSHAGENT="-v /run/host-services/ssh-auth.sock:/run/host-services/ssh-auth.sock -e SSH_AUTH_SOCK=/run/host-services/ssh-auth.sock"

and Linux::

    export DOCKER_SSHAGENT="-v $SSH_AUTH_SOCK:$SSH_AUTH_SOCK -e SSH_AUTH_SOCK"

Creating a development container
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Build image, create container and start it::

    docker build --ssh default --target devel_shell -t multikeyjwt:devel_shell .
    docker create --name multikeyjwt_devel -v `pwd`":/app" -it `echo $DOCKER_SSHAGENT` multikeyjwt:devel_shell
    docker start -i multikeyjwt_devel

pre-commit considerations
^^^^^^^^^^^^^^^^^^^^^^^^^

If working in Docker instead of native env you need to run the pre-commit checks in docker too::

    docker exec -i multikeyjwt_devel /bin/bash -c "pre-commit install"
    docker exec -i multikeyjwt_devel /bin/bash -c "pre-commit run --all-files"

You need to have the container running, see above. Or alternatively use the docker run syntax but using
the running container is faster::

    docker run --rm -it -v `pwd`":/app" multikeyjwt:devel_shell -c "pre-commit run --all-files"

Test suite
^^^^^^^^^^

You can use the devel shell to run py.test when doing development, for CI use
the "tox" target in the Dockerfile::

    docker build --ssh default --target tox -t multikeyjwt:tox .
    docker run --rm -it -v `pwd`":/app" `echo $DOCKER_SSHAGENT` multikeyjwt:tox

Production docker
^^^^^^^^^^^^^^^^^

There's a "production" target as well for running the application, remember to change that
architecture tag to arm64 if building on ARM::

    docker build --ssh default --target production -t multikeyjwt:latest .
    docker run -it --name multikeyjwt multikeyjwt:amd64-latest

Development
-----------

TLDR:

- Create and activate a Python 3.11 virtualenv (assuming virtualenvwrapper)::

    mkvirtualenv -p `which python3.11` my_virtualenv

- change to a branch::

    git checkout -b my_branch

- install Poetry: https://python-poetry.org/docs/#installation
- Install project deps and pre-commit hooks::

    poetry install
    pre-commit install
    pre-commit run --all-files

- Ready to go.

Remember to activate your virtualenv whenever working on the repo, this is needed
because pylint and mypy pre-commit hooks use the "system" python for now (because reasons).

