Authlib

Authlib is a comprehensive Python library for OAuth 1.0, OAuth 2.0, and OpenID Connect, covering both the client side (consuming third-party OAuth providers) and the server side (implementing your own OAuth/OIDC provider). It bundles a full JOSE implementation — JWS, JWK, JWA, and JWT — used internally for token signing/verification and exposed directly for applications that need to issue or validate JSON Web Tokens on their own.

Rather than being tied to one web framework, Authlib ships dedicated integration modules for Flask, Django, Starlette/FastAPI, and generic requests/httpx HTTP clients, so the same core OAuth/OIDC logic can back a Django-based identity provider, a Flask API consuming Google/GitHub login, or an async FastAPI service, all through framework-specific adapters over shared primitives. It is licensed under BSD-3-Clause with an optional commercial license available for companies wanting paid support or additional features.

What You Get

• OAuth 1.0 and OAuth 2.0 client implementations for consuming third-party providers (Google, GitHub, etc.)
• OAuth 2.0 and OpenID Connect server/provider implementations for building your own identity provider
• A full JOSE stack: JWS, JWK, JWA, and JWT signing/verification, usable standalone
• Framework-specific integrations for Flask, Django, and Starlette (both client and OAuth-provider sides)
• requests and httpx OAuth-aware HTTP client wrappers for calling authenticated APIs
• SQLAlchemy-backed OAuth2 provider mixins (sqla_oauth2) for persisting tokens and clients

Common Use Cases

• Adding ‘Login with Google/GitHub/etc.’ OAuth client flows to a Flask, Django, or FastAPI app
• Building a custom OAuth 2.0 / OpenID Connect provider to issue tokens to first-party or third-party clients
• Issuing and validating JWTs for API authentication independent of any OAuth flow
• Signing and verifying JOSE payloads (JWS/JWK/JWA) in services that need standards-compliant crypto primitives
• Persisting OAuth2 clients, tokens, and authorization codes via the SQLAlchemy provider mixins

Under The Hood

Architecture - The package is organized by protocol layer under authlib/: jose/ (bridging to the joserfc dependency for JWS/JWK/JWA/JWT), oauth1/ and oauth2/ for the respective protocol implementations, oidc/ for OpenID Connect on top of OAuth2, and integrations/ housing framework adapters (flask_client, flask_oauth2, django_client, django_oauth2, starlette_client, httpx_client, requests_client, sqla_oauth2). This layering means the framework integrations are thin adapters over shared, framework-agnostic OAuth/OIDC/JOSE core logic rather than separate reimplementations per framework.

Tech Stack - Python 3.10+, with cryptography and joserfc as its only two runtime dependencies per pyproject.toml — Authlib delegates the actual cryptographic primitives to cryptography and increasingly to the joserfc library for JOSE operations (the README notes authlib.jose is being deprecated in favor of joserfc). Built with setuptools, tested via GitHub Actions with Codecov coverage and SonarCloud maintainability tracking.

Code Quality - The tests/ directory contains 115 test files, organized to mirror the source layout (separate suites per framework integration and per protocol). CI badges for build status, code coverage, and SonarCloud maintainability rating are all surfaced in the README, and the project participates in Tidelift’s subscription program, signaling formalized security/maintenance practices beyond a typical hobby project.

API Design - Authlib’s client-side API centers on a OAuth registry object (oauth.register('google', ...)) that Flask/Django/Starlette apps use to declare providers and then call .authorize_redirect()/.authorize_access_token(), while the provider-side API composes AuthorizationServer and grant-type classes (AuthorizationCodeGrant, etc.) that applications subclass to hook in their own user/client models. This ‘compose from framework-provided base classes’ pattern gives OAuth server implementers full control over persistence and business logic at the cost of more upfront wiring than a fully batteries-included auth-as-a-service SDK.