Authentication

django-allauth exists to handle local and social accounts in one app: a user can sign up with a password or log in with Google. Follow the quickstart: add its authentication backend, apps, and middleware, then include allauth.urls under accounts/. Its login, logout, and password views can replace the ones in django.contrib.auth.urls. Give each OAuth provider its client ID and secret in a SocialApp or the SOCIALACCOUNT_PROVIDERS setting. For a single-page or mobile app, add allauth.headless.

Authlib covers both sides of OAuth 2.0 and OpenID Connect. As a client, it comes in two kinds: HTTP clients for scripts and service-to-service calls, and web clients that log users in through Flask, Django, Starlette, or FastAPI. For login, create an OAuth registry and register() each provider. For an OpenID Connect provider like Google, pass its discovery URL as server_metadata_url, and Authlib reads the other endpoints from it. To run your own OAuth 2.0 or OpenID Connect provider, it has server integrations for Flask and Django.

PyJWT encodes and decodes JSON Web Tokens. Treat every token as untrusted input: hard-code the algorithms you pass to jwt.decode(), never read them from the token's own header, and don't mix HS and RS algorithms. For tokens from an OpenID Connect provider, point PyJWKClient at its JWKS endpoint instead of hard-coding its public keys.

oauthlib implements OAuth's logic without assuming a web framework or HTTP request object, so a framework or library maintainer can write a thin layer on top and get OAuth support. Its FAQ says most people use it indirectly: django-oauth-toolkit and django-allauth both build on it. To build a provider on it, most of the work is a RequestValidator that maps its checks to your storage.

django-oauth-toolkit is an OAuth 2.0 authorization server for Django: it issues and manages tokens from your existing project, and can also protect a Django or Django REST framework API. Django REST framework's docs recommend it for OAuth 2.0. Install it by adding oauth2_provider to INSTALLED_APPS, including its URLs under o/, and migrating. For an API, set OAuth2Authentication as Django REST framework's authentication class and guard views with TokenHasScope.

Django has a foundation for object permissions but no implementation, and django-guardian fills it with an extra authentication backend. Grant a permission on one object with assign_perm(), then check it with Django's own user.has_perm(perm, obj). Django REST framework's DjangoObjectPermissions names it as an example backend.

django-rules gives Django object permissions without a database. A permission is a rule built from predicates, plain functions like is_book_author(user, book) that you combine with |, &, and ~. Add its backend to AUTHENTICATION_BACKENDS, register each permission with rules.add_perm(), and check it with user.has_perm(). Keep predicates and rules in their own modules, and let AutodiscoverRulesConfig import each app's rules.py at startup.

On either side of OAuth, use PKCE. django-oauth-toolkit's security guide maps the OAuth security recommendations of RFC 9700 to its settings: PKCE is one, and the implicit and password grants must not be used. Authlib's client turns PKCE on with code_challenge_method. Also, don't pick JWTs for sessions just because they sound stateless. django-allauth's docs point out that if a token must stop working at logout, you need state to revoke it. JWTs help most when each service checks tokens without asking a central server.