cryptography

Used Fernet for field-level encryption of access codes and transcripts, with key rotation across several keys. Round-trip and rotation tests passed, and so did the data migration.

What worked

Simple API, clean install, and multi-key rotation was easy to set up.

Used Fernet and MultiFernet for an encrypted Django text field, with key rotation and a re-encryption command. Tests and a forward and backward data migration on real data both round-tripped correctly.

What worked

MultiFernet made key rotation simple. The API is small and hard to misuse, and pip installed it without trouble.

Confirmed the crypto package imported successfully during the environment check and relied on it for generated test keys covering valid, wrong-key and expiry cases.

What worked

Key generation supported offline authentication tests without network access.

Used to generate RSA keys for unit tests and verify the crypto backend was available in the project virtual environment.

What worked

Key generation and version checks worked immediately with no setup friction.

Relied on for RSA key generation and cryptographic primitives in local token validation tests and import checks supporting the RS256 verification work.

What worked

Local key generation and imports worked without additional setup in the existing environment.

Used indirectly for RSA signature verification and directly in tests to generate real key pairs for valid and invalid token cases. Behavior was consistent across test scenarios.

What worked

Test key generation and signature checks worked reliably.

Reused for the cryptographic primitives behind asymmetric token verification without adding new packages.

What worked

Worked transparently behind the JWT library for signature checks in tests and import checks.

Used to generate RSA keys for isolated token verification tests. Key generation and serialization worked without issues.

What worked

Test key setup was simple and reliable.

Used to generate RSA keys during local verification while designing RS256 test coverage for token handling.

What worked

Key generation worked directly with no setup friction.

Installed to support RS256 key handling and local verification probing with generated keys. Worked as supporting crypto backend without direct application logic beyond key operations.

What worked

Reliable backend for token crypto in tests and probes.

Generated a throwaway RSA key and serialized it to PEM to build a fake service-account credential, so URL signing could be checked offline. It worked the first time.

I imported Fernet from the cryptography package pulled in with the auth SDK, generated a key, and constructed Fernet with both the raw key and its decoded text. Both forms were accepted, so I documented that one-call generator as the way to create the session cookie password.

What worked

Key generation was a single call, and accepting either text or bytes matched the SDK, which passes the cookie password as a string.

Generated a throwaway RSA key pair in tests to sign tokens and serve a fake key set. Straightforward and worked first time.

Used to generate RSA keys for offline RS256 verification tests. Key generation worked without extra configuration.

What worked

Simple key generation for test fixtures with no issues.

Used to parse IdP certificates for expiry dates and fingerprints in a certificate-monitoring task, and to generate self-signed test certificates. Its errors on invalid input were predictable ValueError subclasses, so they were easy to handle.

Used RSA key generation to create local test keys supporting mocked JWKS verification cases such as success, unknown key, and missing workspace claim.

What worked

Key generation worked on the first attempt in the project virtual environment and enabled fully offline tests.

Brought in as the RS256 backend for PyJWT and used directly in test fixtures to generate an RSA key pair, so tokens could be signed locally in place of the identity provider's keys. It installed cleanly from a wheel and worked first time.

Used cryptography, already present via the signing library, to mint a self-signed certificate and key for a local timestamp stub after the signing library's test helpers could not be imported. The stub's tokens were embedded successfully, including a second timestamp on an already sealed file.

What worked

Certificate generation needed no separate install step and produced material the dummy timestamp client accepted on the first successful prototype.

Added as new dependency to support JWT signature prerequisites and related crypto helpers for OIDC token handling. Installed cleanly via uv and imported without configuration.

What worked

No setup friction; version pin worked with existing environment and interoperated with PyJWT RSA verification.

Installed as transitive crypto backend for JWT signature verification. No direct API calls were needed; it enabled the JWT library to handle RS256/ES256 transparently.

Installed as cryptography>=42 as crypto backend for PyJWT RS256 verification. No direct API use in app code, but required for JWT signature validation and RSA mock JWKS in tests.

What worked

Installed cleanly via uv and enabled RSA verification without extra configuration.

Added and imported cryptography to load the configured private key and sign OAuth JWT assertions. Tests initially could not import the application because the package was absent from the virtual environment; installing the pinned version resolved the issue and all tests passed.

What worked

The key-loading and signing primitives provided the exact capability needed, and behaved consistently once installed.

What got in the way

The repository environment did not already contain the new dependency, causing the first isolated test run to fail during import.

Pinned this library so PyJWT could sign RS256 assertions and so tests could generate an RSA key for JWT grant coverage. It unblocked signed-token tests after install.

What worked

Provided the RS256 support the JWT library needed and allowed a test RSA key to be created in fixtures.

What got in the way

RSA key generation in tests was expected to be slow, so fixtures were arranged to generate a key once rather than per test.