Authlib: a Python OAuth and OpenID Connect toolkit for clients and providers

What Authlib solves, and who ends up using it

OAuth is a family of RFCs, not a single function call. A provider has to issue authorization codes, validate redirect URIs, handle PKCE, publish authorization server metadata, and support token revocation and introspection if clients ask for them. Authlib packages those flows as reusable pieces so you write the parts that are specific to your product, such as user lookup and consent screens, rather than the parts that are specified by the RFCs. The README describes it as a "generic, spec-compliant implementation to build clients and providers", and the feature list is organised by specification rather than by convenience wrapper.

The audience is narrow but real. If you are integrating one third-party login into a small app, a hosted identity provider will cost you less work. Authlib earns its place when you are the identity provider, or when you need a client that speaks protocol details the average SDK abstracts away: RFC7636 PKCE, RFC8628 device authorization, RFC9101 JWT-secured authorization requests, RFC7662 token introspection, RFC9068 JWT access tokens. It also covers OAuth 1.0 through RFC5849, which matters if you still talk to an older API. The framework integrations listed in the README are Flask, Django, Starlette and FastAPI, plus Requests and HTTPX for plain HTTP clients.

How the pieces fit: providers, clients and the JOSE layer

The repository separates three concerns. The provider side lets you build an OAuth 1.0, OAuth 2.0 or OpenID Connect authorization server, with documented integrations for Flask and, per the feature list, other web frameworks. The client side gives you OAuth1Session and OAuth2Session on top of Requests, AsyncOAuth1Client and AsyncOAuth2Client on top of HTTPX, and web-framework clients for Flask, Django, Starlette and FastAPI. The third concern is JOSE: JWS, JWE, JWK, JWA and JWT, historically exposed through the authlib.jose module.

That third layer is where the project is moving. The README carries a migration note stating that "Authlib will deprecate authlib.jose module" and points to a migration guide from authlib.jose to joserfc. The dependency list in pyproject.toml confirms the direction: Authlib depends on both cryptography (>=45.0.1) and joserfc (>=1.6.8). So the crypto primitives are increasingly delegated rather than maintained inside Authlib, and the JOSE surface you import is the part most likely to change under you between minor versions. If your code only needs to sign and verify tokens, you are now carrying a framework-sized dependency for a job that joserfc does on its own.

The specification coverage is uneven in a way the README is honest about. Two JOSE items are unchecked in the feature list: RFC7797, the JWS unencoded payload option, and draft-madden-jose-ecdh-1pu-04, public key authenticated encryption for ECDH-1PU. OpenID Connect Core 1.0, Discovery 1.0, Dynamic Client Registration 1.0 and RP-Initiated Logout 1.0 are all marked as done. If your integration depends on either unchecked item, Authlib is not the piece that will supply it.

Installing Authlib and building a first OAuth 2.0 provider

The README points at PyPI and conda-forge, and pyproject.toml sets requires-python to ">=3.10", so the install is a normal pip or conda operation. Authlib pulls in cryptography and joserfc transitively, which means a working build toolchain for cryptography on platforms without wheels. There is no separate install step for the JOSE or provider features; they ship in the same package.

pip install Authlib

After installation, the documented starting point for a provider is the Flask OAuth 2.0 provider, which the README links under "Build your own OAuth 1.0, OAuth 2.0, and OpenID Connect providers".

Where Authlib is the wrong tool

The clearest limitation is the JOSE deprecation. If your requirement is "sign a JWT and verify one on the way back", installing Authlib means adopting a package whose README explicitly announces that the module you would use is going away. The migration guide it links points at joserfc, which is already a direct dependency. Starting a new token-only service on authlib.jose is starting on a surface the maintainer has said will be removed.

The second limitation is scope. Authlib is not an identity provider you deploy; it is a library you embed. Teams that pick it expecting a self-hosted alternative to a hosted identity service will find themselves writing the parts they thought they were buying. The README's integration list makes this concrete: every entry is a framework binding, not a service.

Third, the commercial dimension. The repository contains a COMMERCIAL-LICENSE file, the project URLs include a Purchase link to authlib.org/plans, and the README links a funding page described as the way to "access additional features". The BSD-3-Clause licence covers the code in the repository, but the README says funding gives access to additional features, so anyone planning a production rollout should read the funding page before committing to a design that assumes everything in the docs is free.

Authlib compared with oauthlib and PyJWT

The two comparisons people reach for are oauthlib and PyJWT, and they fail in different directions. oauthlib is also a protocol implementation, but the division of labour differs: oauthlib historically relies on framework-specific glue packages such as requests-oauthlib and django-oauth-toolkit to connect the protocol layer to a web framework. Authlib ships the framework bindings in the same distribution, with documented Flask, Django, Starlette and FastAPI clients and Flask providers. That means fewer packages in your dependency tree and one upgrade cadence instead of two, at the cost of a larger single dependency and less freedom to swap the protocol layer independently of the integration layer.

PyJWT is not a competitor to the provider side at all; it is a token library. The comparison only matters because Authlib's JOSE module is deprecated. If your need is JWT encoding and decoding, PyJWT or joserfc is the smaller answer, and Authlib's own migration path points at joserfc. Authlib makes sense over either of them when the token is one part of a flow that also includes authorization endpoints, grant registration, metadata discovery and introspection, because then you would otherwise be assembling three libraries into a protocol implementation yourself.

Maintenance, licensing and the cost of upgrading

The repository is not archived, and the most recent push recorded for it is 2026-11-02. The latest release listed is v1.9.2 on 2026-11-01, following v1.9.1 and v1.9.0, both on 2026-10-14. The version numbers stay in the 1.x line.

The upgrade cost is concentrated in two places. The first is the jose-to-joserfc migration, which the README treats as significant enough to announce at the top of the file rather than bury in a changelog. Any code importing from authlib.jose should be planned for migration, and the guide is the one the README links. The second is the Python floor: requires-python is ">=3.10", and the classifiers list 3.10 through 3.15, so an application still on 3.9 cannot install the current release at all. The cryptography floor in pyproject.toml is >=45.0.1, which is a hard constraint on shared environments where another package pins cryptography lower.

On licensing: the package metadata declares BSD-3-Clause, and the repository carries both a LICENSE and a COMMERCIAL-LICENSE file. BSD-3-Clause is permissive and does not require you to open your own source. The presence of a separate commercial licence file and a Purchase link means the project operates some form of dual arrangement. Read the funding page and the commercial licence text yourself rather than inferring the split from the licence identifier alone.

Editorial conclusion

Adopt Authlib if you are building an OAuth 2.0 or OpenID Connect provider in Python, or a client that needs PKCE, token introspection, device grants or JWT-secured requests without hand-rolling the protocol. Do not adopt it if you only need to mint and verify JWTs, because the README says authlib.jose is being deprecated in favour of joserfc, and do not adopt it expecting a hosted identity service, because it is a library you wire into your own application. Verify first that the framework integration you need is the one documented for your stack, that your Python is 3.10 or newer, and that your dependency resolver has picked a joserfc version at or above 1.6.8.

Frequently asked questions

Official sources

1. authlib/authlib on GitHub
2. License: BSD-3-Clause
3. Project website
4. README
5. Releases