# Authlib: OAuth, OIDC and JOSE in one Python library

> Authlib is a spec-compliant Python library for OAuth 1.0, OAuth 2.0 and OpenID Connect, on both the client and provider side, with JOSE primitives included. The authlib.jose module is deprecating in favor of the separate joserfc package, and a commercial license sits alongside the BSD one.

**authlib/authlib** — The ultimate Python library in building OAuth, OpenID Connect clients and servers. JWS, JWE, JWK, JWA, JWT included.

- Repository: https://github.com/authlib/authlib
- Website: https://authlib.org
- Stars: 5,429 · Forks: 567
- Language: Python
- License: BSD-3-Clause
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/authlib-authlib

## One library for both ends of the handshake

Authlib serves the two sides of OAuth that projects need at different times. On the client side, built-in integrations connect third party OAuth providers, with session classes for requests (OAuth1Session, OAuth2Session, AssertionSession), async equivalents for HTTPX (AsyncOAuth1Client, AsyncOAuth2Client, AsyncAssertionClient), and framework-level clients for Flask, Django, Starlette and FastAPI. On the provider side, you can build OAuth 1.0 servers, OAuth 2.0 authorization servers and OpenID Connect providers, with Flask and Django documented for each role. That duality is the pitch: one library signs you into other people's systems and lets other people sign into yours, under one import and one set of specs, instead of stitching a client library and a server framework together. For a product team, the split matters when scope grows: the same dependency that added third party login this quarter can become the token issuer next quarter without a second evaluation round.

## The RFC checklist, with two boxes still empty

Spec coverage is tracked as a checklist of RFCs. Beyond the OAuth 2.0 core in RFC6749, the implemented list includes PKCE in RFC7636, token introspection in RFC7662, token revocation in RFC7009, the device authorization grant in RFC8628 and JWT-secured authorization requests in RFC9101, with bearer usage, dynamic client registration and management, authorization server metadata, issuer identification and the JWT profile for access tokens also covered. OAuth 1.0 arrives via RFC5849. OpenID Connect support spans Core, Discovery, Dynamic Client Registration and RP-Initiated Logout. On the JOSE side, JWS, JWE, JWK, JWA, JWT and JWK thumbprints are implemented per their RFCs. Two entries carry empty checkboxes: RFC7797, the JWS unencoded payload option, and the ECDH-1PU draft. Publishing the gaps beside the coverage is more useful than a blanket compliance claim.

## authlib.jose is deprecating into joserfc

The most consequential current change is a subtraction. The project has announced that authlib.jose, the module holding the JWS, JWE, JWK, JWA and JWT implementations, will deprecate, with a migration guide titled Migrating from authlib.jose to joserfc. The direction is visible in the dependency list: pyproject.toml already pulls in joserfc>=1.6.1 alongside cryptography>=45.0.1, so the JOSE work is being absorbed by a separate package rather than disappearing. Code importing authlib.jose is exactly what the deprecation notice addresses, and anyone with signing or encryption logic on that module should treat the migration guide as required reading before the next major upgrade. The notice is current rather than historical: the tree carrying it was last pushed on 2026-08-31, the day after v1.8.0 shipped, so this is the live release line talking.

## Getting it: PyPI, Python 3.10+, two dependencies

The package is published on PyPI as Authlib, and compatibility starts at Python 3.10. Two runtime dependencies do the heavy lifting: cryptography>=45.0.1 for the cryptographic primitives and joserfc>=1.6.1 for the JOSE layer. A curiosity sits in setup.py: it declares install_requires cryptography>=3.2 with a comment that metadata lives elsewhere and these entries exist for GitHub's dependency graph, so two different floors for the same dependency appear in one repository depending on which file you read. Contributors get a Makefile path for checks, running the suite across framework environments in one line:

```make
tests:
	@TOXENV=py,flask,django,coverage tox
```

That env list explains the support posture better than prose can: plain Python, Flask, Django and coverage, exercised together.

## BSD on the surface, a commercial license underneath

The repository carries both a LICENSE file, BSD-3-Clause, and a COMMERCIAL-LICENSE file, and the links section sells a commercial license at authlib.org/plans. A funding page is linked with the words Fund Authlib to access additional features, and the sponsor block promotes Auth0's Python SDK and Typlog. What those additional features are is not spelled out anywhere in the repository; the plans page is the authority. The practical reading for a team is a dual-licence arrangement: BSD terms apply as stated in LICENSE, and paid terms exist for whatever the plans page defines. Procurement should read both files before shipping a product on top of the library. The sponsor framing is worth noting for budgeting: the same README that ships the code also references paid tiers, so the funding model is visible rather than buried.

## Quality signals you can click through

Assurance is unusually public. Badges link GitHub Actions, codecov, SonarCloud and Code Climate, and the tree backs the badges up: sonar-project.properties, .codeclimate.yml and .codecov.yml configure the analyzers, .readthedocs.yaml publishes docs.authlib.org, and the Makefile rebuilds documentation with sphinx-build docs build/_html -a. Development dependencies include pytest, pytest-asyncio for the async clients, diff-cover, coverage and tox-uv, and a .pre-commit-config.yaml keeps hook-based checks running before commits land. Release history runs v1.8.0 on 2026-08-30, v1.7.2 on 2026-05-06 and v1.7.1 on 2026-05-04, with the last push on 2026-08-31, so activity is current and the Development Status classifier reads 5, Production/Stable.

## Where PyJWT and Keycloak sit relative to it

The comparisons people search for name PyJWT, Keycloak and python-jose, and the honest answer is that they occupy different shapes. PyJWT is a library for encoding and decoding JSON Web Tokens; it does not implement OAuth flows, so when token signing is the whole job, it is the smaller tool. Keycloak is an identity provider you deploy and run as its own server; adopting it means operating a service, while adopting Authlib means adding library code to the Python application that already exists. python-jose overlaps Authlib's JOSE half, which is precisely the half migrating to joserfc. Teams pick by shape: library code in one runtime, a deployed server, or a single-purpose token tool. Authlib's differentiator is covering client and provider roles for OAuth 1.0, OAuth 2.0 and OpenID Connect in one import.

## Conclusion

Adopt Authlib when one Python codebase needs to be both an OAuth client and an OAuth or OpenID Connect provider across Flask, Django, Starlette or FastAPI. Look at PyJWT if you only sign and verify tokens, and at a standalone identity server such as Keycloak when you want authentication as a deployed service rather than library code. Verify first whether your code touches authlib.jose, since that module is deprecating into joserfc, and whether the BSD licence covers your use or the commercial one applies.

## FAQ

### What is Authlib?

Authlib is a Python library for building OAuth and OpenID Connect clients and servers, with JOSE support covering JWS, JWE, JWK, JWA and JWT. It is compatible with Python 3.10 and newer.

### How do I install Authlib?

The package is published on PyPI under the name Authlib and requires Python 3.10 or newer. Its runtime dependencies are cryptography>=45.0.1 and joserfc>=1.6.1, listed in pyproject.toml.

### What is authlib.jose?

authlib.jose is the module implementing JSON Object Signing and Encryption: JWS, JWE, JWK, JWA and JWT, per RFCs 7515 through 7519. The project has announced it will deprecate this module in favor of the separate joserfc package, with a migration guide in the documentation.

## Sources

- [authlib/authlib on GitHub](https://github.com/authlib/authlib)
- [License: BSD-3-Clause](https://github.com/authlib/authlib/blob/main/LICENSE)
- [Project website](https://authlib.org)
- [README](https://github.com/authlib/authlib/blob/main/README.md)
- [Releases](https://github.com/authlib/authlib/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/authlib-authlib