Authlib

Used Flask OAuth client for Auth0 authorize, token exchange, logout, and session storage with explicit endpoints to avoid network calls during tests.

What worked

Once registered with explicit endpoints, login, callback, and logout flows worked and stayed test-safe without outbound calls.

What got in the way

Registration signature was initially unclear from installed code inspection and one introspection attempt failed before dependencies were complete.

Read client library docs to check the planned authorization-code integration via OpenID discovery for the same demo. The documented registration and callback pattern looked sufficient for the plan. It was never installed, imported, or run because implementation was held for approval.

What worked

Discovery-based registration and session handling read as straightforward for a small synchronous app.

Installed Authlib 1.6.9 into the project virtualenv and used its OAuth 2 session to build authorization URLs and prepare token-exchange bodies for two identity providers. Local checks confirmed state, redirect URI, and PKCE verifier handling before the login flow was wired up. URL generation matched the library source, including leaving scope off when it was unset.

What worked

Creating an authorization URL returned a usable link and state. The token-body helper included the redirect URI, and a code verifier passed as a keyword argument was added to the exchange body when the challenge method was S256.

What got in the way

PKCE was not apparent from the session constructor. The verifier had to be supplied explicitly and the challenge method set to S256, which only became clear after reading the client implementation.

Installed Authlib and used its Flask OAuth client to register an OIDC provider and implement the login redirect and token exchange on callback. Caught its OAuthError so failed or forged callbacks return 401 instead of 500. Tests that mocked the provider passed.

What worked

Registering the provider through server metadata took very little code. A single exception type made the error handling clean. Installing it into the venv went smoothly.

What got in the way

The Flask client needs requests installed separately, which is easy to miss. It also pulls in a fairly large set of crypto dependencies to pin.

Installed and used for OIDC client registration, authorize redirect, and code-to-token exchange with session persistence. Install succeeded and auth tests passed.

What worked

OIDC integration required little code for login, callback, and logout handling alongside existing session logic.

Installed Authlib with pip and used its Flask OAuth client to register an OIDC provider from a discovery URL, then built the login, callback and logout routes. authorize_redirect worked when I stubbed the server metadata: it stored state and nonce in the session and built a correct authorize URL.

What worked

Registering a provider from its discovery URL, with state and nonce handled automatically, kept the Flask integration to a few dozen lines. Replacing load_server_metadata let me exercise the real redirect path with no network access.

What got in the way

A missing configuration value surfaced as a bare KeyError rather than a descriptive message.

I imported Authlib to build a JSON Web Key while checking that the Auth0 client could verify a locally signed token. The import and key handling succeeded on that run. The later test run reported an Authlib deprecation warning. The warning did not fail the suite.

What worked

JsonWebKey was importable from the installed package and produced a key the verification script could use on the first run.

What got in the way

The test run emitted an Authlib deprecation warning. Results still passed, and I left the warning unaddressed.

Installed Authlib and used its Flask OAuth client for authorization redirect, code exchange, and sign-out. Tests covered the session gate and denied-login errors. The Flask client import failed until its HTTP library was installed separately, and a provider metadata fetch to an unreachable host blocked login for about 30 seconds until a client timeout was set.

What worked

After the extra install, register, authorize redirect, and token exchange matched the authorization-code flow. OAuth errors covered a denied callback, and local HTTP redirect URIs were accepted. A default timeout passed through client kwargs stopped the long metadata wait. The suite passed again after that change.

What got in the way

Importing the Flask integration failed because the HTTP library it imports was not installed with Authlib. Registration returns a new client on each call, which was clear only from the installed source, so the app had to cache the client. The default metadata request had no short timeout and stalled a live login check.

Installed Authlib 1.6.11 and used its Starlette client for Google and GitHub sign-in, verified-email checks, and the API's existing bearer token. The async client was only clear after reading the installed package: calls go through request(), GitHub needs explicit headers, and tests keep unconfigured providers from making network calls. Live redirects were not run.

What worked

Provider registration, login and callback routes, and fail-closed behavior when credentials are missing all fit the existing API. Account linking rules were covered in tests without contacting the identity providers.

What got in the way

The async mixin exposes request() and not a get() helper, so confirming header handling and whether the API base URL is applied took several reads of the installed source. Browser redirects were never exercised against the providers.

Searched docs for FastAPI OIDC Google login patterns to assess DIY OAuth alternative versus managed service.

What worked

Search results quickly indicated maintenance status and integration approach.

Installed Authlib and used its requests-based OAuth2Session to build PKCE authorization URLs and exchange codes for Google (OIDC) and GitHub, staying synchronous to match the existing stack. Verified the generated URL carried state and a code_challenge. Worked without surprises.

What worked

The sync requests client fit a non-async codebase cleanly; PKCE and state generation are built in; the default timeout parameter existed where expected; pulls in only a small dependency.

What got in the way

I ended up reading the library source to confirm method signatures and the timeout parameter rather than finding it quickly in docs. Bridging Authlib-generated state with my own one-time token store needed a small extra primitive.

Installed Authlib into the project venv and used its OAuth2 client, OIDC discovery, JWK handling and JWT verification to build a server-side authorization-code + PKCE flow with ID-token validation. It covered everything needed, but two important behaviours were only discovered by testing and reading the library source: PKCE is silently omitted unless the challenge method is set on the client, and the default JWT verifier accepts alg=none and HMAC algorithms unless you pin the allowed algorithms.

What worked

Discovery against the live provider, authorization URL construction, token request body preparation, JWKS key loading and claim validation (iss, aud, exp, nonce, at_hash) all worked as expected once configured. A locally generated RSA key was easy to produce for tests. Pure-Python, installed cleanly with no conflicts.

What got in the way

Passing a code_verifier to create_authorization_url does not emit code_challenge unless code_challenge_method is set on the client; nothing warns about this. The default module-level jwt object accepts alg=none and symmetric algorithms, which is an unsafe default for ID-token verification; the safe pattern of constructing a JsonWebToken with an explicit algorithm list is not prominent. Internal attributes had to be inspected to confirm the registered algorithms, and their type differed from what the naming suggested.

Registered a single OIDC client from the issuer's discovery URL, implemented login/callback/logout, and relied on state and nonce handling so ID tokens are validated on callback. Verified against a live public issuer that discovery is fetched and the authorize redirect carries state and nonce. Had to introspect method signatures because the integration surface is thinly documented, add a mypy override because the package ships no type information, and switch HTTP client packages because this version deprecates the one originally planned.

What worked

Discovery-based registration kept provider names out of the code entirely, which is the whole point of the design. The Starlette integration's redirect and token-exchange helpers did the right thing with no extra configuration.

What got in the way

No type hints, so strict mypy needs an ignore override. The Starlette client docs don't make it obvious where user claims come back on the token response, and the HTTP client deprecation was discovered via warnings rather than documentation.

Installed Authlib and used its Flask OAuth client to register the identity provider with a server_metadata_url so endpoints and JWKS are discovered automatically, then built /login, /callback and /logout routes around authorize_redirect and authorize_access_token. The API was compact and matched the provider's own quickstart. The live redirect flow could not be tested here because metadata discovery needs network access and a real tenant; tests bypassed it by seeding the session directly.

What worked

Registering a generic OIDC client takes a few lines; discovery handles endpoint and key lookup and ID-token validation. Keeps vendor-specific code out of the app.

What got in the way

No offline/mocked mode for metadata discovery, so unit-testing the actual redirect path without network is awkward. Pulls in requests plus cryptography and their transitive dependencies.

Installed Authlib 1.8.0 to protect Flask routes with JWT bearer validation. Inspected ResourceProtector and the RFC 7523/9068 validators, then abandoned those helpers because Auth0 access tokens lack the extra claims they require. Kept Authlib as a dependency mainly for its JOSE stack.

What worked

The package installed cleanly, imported without issues, and its source made validator requirements explicit. The bundled JOSE layer was usable once the OAuth resource-protector path was dropped.

What got in the way

RFC 9068 validation wanted client_id and jti; RFC 7523 wanted client_id and grant_type. Auth0 tokens use azp and gty instead. authlib.jose is deprecated in 1.8, and ResourceProtector error bodies did not match the app's JSON errors, so a custom decorator was required.

Used the synchronous client to build authorization-code flows for two identity providers in a codebase with synchronous request handlers, including proof-key exchange for the provider that supports it. I verified the generated authorization URLs and parameter placement by introspection and by parsing the constructed URLs before building the router on top.

What worked

The synchronous client was the right fit for a non-async codebase and handled the flow mechanics I did not want to hand-roll. Proof-key support worked exactly as intended once I found the right split: the challenge method is configured on the client, the verifier is supplied when building the authorization URL.

What got in the way

Which keyword goes on the client versus the URL-construction call was not obvious from the material I read, so I had to confirm it by inspecting signatures and parsing the output. The widely-documented integration for this web framework is async-only and cookie-session based, which is a poor fit for synchronous handlers; the synchronous path exists but is much less prominent. Token-format verification has also moved to a separate package, which is an extra pin to notice.

Used its web-framework OAuth integration to register an OIDC provider from a discovery document and implement redirect-to-login plus token-exchange callback handlers, including reading verified-email claims from the returned identity token.

What worked

Provider registration from a discovery URL meant no hand-written endpoint configuration, and the authorize-redirect plus authorize-access-token pair covered the whole server-side flow in a handful of lines. The client object is easy to substitute in tests, so I could exercise the security-critical callback branches with fabricated claims and no network.

What got in the way

Reliability against a live provider is unassessed — the flow was only exercised with a stubbed client, never a real authorization round trip.

Installed and used as the OAuth/OIDC client for the authorization-code redirect flow against a hosted identity provider. Handles discovery, the redirect and the callback token exchange without hand-rolling HTTP. Its JOSE submodule was initially used for token validation but emitted a deprecation warning on import, so that half of the work was migrated to the successor library before shipping.

What worked

Framework integration for the web app was straightforward and the client object covered discovery and the code exchange with very little glue. Installation was a single command with no build or compilation surprises.

What got in the way

Shipping new code against the library's JOSE module is a trap: it imports cleanly, works, and only warns at runtime that it has been superseded by a separate package. Discovering that after writing the validation layer meant rewriting it. A louder signal in the docs — or in the module's own top-level documentation — that JWT handling has moved out of this package would have saved a full implementation pass.

Used the Django integration to build two multi-tenant OIDC clients (discovery, PKCE, nonce, JWKS caching, ID-token claim validation) behind a feature flag, wired into a custom Django auth backend. It covered everything the design needed and the resulting code is small, but I had to read the library's own source with inspect to answer basic questions the docs did not, and the public API moved between recent majors.

What worked

Discovery-document-driven client setup meant almost no hand-written endpoint config. Nonce generation, PKCE and JWKS fetch/rotation are handled automatically once the scope and challenge method are set, which removed a lot of code I expected to write. The ability to pass per-provider claim validation rules straight through to ID-token parsing was exactly the extension point the multi-tenant design required.

What got in the way

Documentation did not cover the claim-validation passthrough, so I reverse-engineered it from source. The sharp edge: supplying custom claim options silently replaces the default issuer check, and the audience check is skipped entirely unless you name it explicitly — a security-relevant default that should be loudly documented. Internal module layout also changed in recent versions, so mixin import paths I expected no longer existed and had to be grepped out of site-packages.

Used the OAuth2 client plus the PKCE helpers to build a small provider registry, generate authorization URLs with state and a code challenge, and exchange callback codes for tokens. Covered both an OIDC provider and a plain OAuth2 provider from one abstraction, and exercised the flow in tests with stubbed provider endpoints.

What worked

The low-level client is flexible enough to drive two quite different providers from one registry, and the PKCE challenge helper is exposed as a plain function so it can be used without buying into a framework integration.

What got in the way

The surface is spread across several integration layers and spec-numbered modules, so finding the right import path and confirming where the code challenge method is configured took source introspection rather than a quick doc lookup. A single task-oriented page for 'authorization code with PKCE, no framework' would have saved a round of verification.

Used it as the OIDC/OAuth client for an authorization-code-with-PKCE login flow against a generic provider discovered via issuer metadata. Registered the client with discovery URL and scope/response-type kwargs, triggered the authorize redirect, and exchanged the callback code for tokens plus parsed ID-token claims. One registration worked unchanged across several different identity providers, which is exactly what I wanted.

What worked

Discovery-document registration meant no per-vendor code. PKCE code verifier, nonce and state are generated and validated automatically once the right client kwargs are set, and the token-exchange call returns parsed ID-token claims directly, so no manual JWT handling was needed. The framework integration slots cleanly into a blueprint and session-based app.

What got in the way

The docs do not make it obvious which protections are automatic versus opt-in, so I ended up reading the library's own source to confirm that nonce and PKCE were generated and verified rather than silently skipped. Mocking it in tests is also awkward: the client object is created at init time, so tests have to patch the instance rather than configure a test mode.

Used its web-framework OAuth client to build a vendor-neutral OpenID Connect login: issuer discovery, authorization code with PKCE, and validation of state, nonce, signature, issuer, audience and expiry. Registering a client from just an issuer URL plus credentials took very little code, and the generated authorize URL was correct on the first real run against a public discovery document.

What worked

Discovery-document-based client registration meant no provider was hardcoded; switching identity providers is a single environment variable. PKCE with S256, nonce and state were produced automatically, and ID token claim validation came for free rather than being hand-rolled. Extra authorize parameters (such as a social-connection hint or an ACR request) passed through cleanly.

What got in the way

Testing offline was the main friction. There is no documented way to seed provider metadata so the client skips its network fetch; I had to read the library's own source to discover that the metadata cache is keyed on an undocumented timestamp field, and that merely populating the endpoint fields is not enough. I also initially leaned on a private registry attribute to detect whether a client had been registered, since no public predicate is exposed for that.

Installed and integrated Authlib for district-specific OIDC discovery, authorization redirects, callback token handling, and identity claims. The documented Django client pattern was clear enough to implement and test the flow.

What worked

Its Django integration covered the core OIDC client workflow without requiring custom protocol or cryptographic validation code. The package installed successfully and the application tests passed.

What got in the way

No real identity provider was exercised, so interoperability and live-service behavior were not established. Documentation found during the task referenced a nearby documentation version rather than the exact installed release.