Metadata-Version: 2.1
Name: asymmetric_jwt_auth
Version: 1.0.1b6
Summary: Asymmetric key based authentication for HTTP APIs
Home-page: https://gitlab.com/crgwbr/asymmetric_jwt_auth
License: ISC
Author: Craig Weber
Author-email: crgwbr@gmail.com
Maintainer: Craig Weber
Maintainer-email: crgwbr@gmail.com
Requires-Python: >=3.10,<4.0
Classifier: Development Status :: 5 - Production/Stable
Classifier: Environment :: Web Environment
Classifier: Framework :: Django
Classifier: Intended Audience :: Developers
Classifier: License :: OSI Approved
Classifier: License :: OSI Approved :: ISC License (ISCL)
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.10
Classifier: Programming Language :: Python :: 3.11
Classifier: Programming Language :: Python :: 3.12
Requires-Dist: Django (>=3.2)
Requires-Dist: PyJWT (>=2.0.1)
Requires-Dist: cryptography (>=3.4.6)
Project-URL: Repository, https://gitlab.com/crgwbr/asymmetric_jwt_auth
Description-Content-Type: text/x-rst

Asymmetric JWT Authentication
=============================

.. image:: https://img.shields.io/pypi/v/asymmetric_jwt_auth.svg
    :target: https://pypi.python.org/pypi/asymmetric_jwt_auth

.. image:: https://gitlab.com/crgwbr/asymmetric_jwt_auth/badges/master/pipeline.svg
    :target: https://gitlab.com/crgwbr/asymmetric_jwt_auth/-/commits/master

.. image:: https://gitlab.com/crgwbr/asymmetric_jwt_auth/badges/master/coverage.svg
    :target: https://gitlab.com/crgwbr/asymmetric_jwt_auth/-/commits/master


What?
-----

This is an library designed to handle authentication in
*server-to-server* API requests. It accomplishes this using RSA public /
private key pairs.


Why?
----

The standard pattern of using username and password works well for
user-to-server requests, but is lacking for server-to-server
applications. In these scenarios, since the password doesn’t need to be
memorable by a user, we can use something far more secure: asymmetric
key cryptography. This has the advantage that a password is never
actually sent to the server.


How?
----

A public / private key pair is generated by the client machine. The
server machine is then supplied with the public key, which it can store
in any method it likes. When this library is used with Django, it
provides a model for storing public keys associated with built-in User
objects. When a request is made, the client creates a JWT including
several claims and signs it using it’s private key. Upon receipt, the
server verifies the claim to using the public key to ensure the issuer
is legitimately who they claim to be.

The claim (issued by the client) includes components: the username of
the user who is attempting authentication, the current unix timestamp,
and a randomly generated nonce. For example:

::

    {
        "username": "guido",
        "time": 1439216312,
        "nonce": "1"
    }

The timestamp must be within ±20 seconds of the server time and the
nonce must be unique within the given timestamp and user. In other
words, if more than one request from a user is made within the same
second, the nonce must change. Due to these two factors no token is
usable more than once, thereby preventing replay attacks.

To make an authenticated request, the client must generate a JWT
following the above format and include it as the HTTP Authorization
header in the following format:

::

    Authorization: JWT <my_token>

**Important note**: the claim is *not* encrypted, only signed.
Additionally, the signature only prevents the claim from being tampered
with or re-used. Every other part of the request is still vulnerable to
tamper. Therefore, this is not a replacement for using SSL in the
transport layer.

**Full Documentation**: https://asymmetric-jwt-auth.readthedocs.io

