How Numero Protects Access to Your Financial Data

Numero uses Google OpenID Connect to establish who is signing in. Connecting Gmail is a separate authorization decision. Keeping those grants distinct prevents a login action from silently becoming consent to inspect financial messages.

The Gmail integration requests exactly gmail.readonly. That scope permits reading authorized mailbox data but does not permit Numero to send messages, change them, or delete them. The application also checks that the scopes returned by Google contain what was requested; partial or unexpected consent does not quietly become a connected source.

Users can disconnect a source. Numero calls Google's token-revocation endpoint and removes the local connection. Account deletion goes further by revoking connected sources on a best-effort basis, deleting the user's stored financial records through the owning data relationships, and clearing the browser session.

All three reviewed OAuth integrations use the Authorization Code flow with PKCE using the S256 challenge method. Each transaction creates cryptographically random state, nonce, and verifier values. The callback verifies those values, the expected issuer and audience, the registered public host, and the email-verification claim before completing sign-in or source connection.

Transaction cookies are encrypted, short-lived, HttpOnly, Secure in production, SameSite=Lax, and path-scoped to the callback that consumes them. A used or expired transaction cannot simply be replayed as a fresh authorization attempt. SameSite=Lax remains intentional because OAuth callbacks are cross-site top-level navigations; state, nonce, PKCE, Origin enforcement, and callback-host validation provide the accompanying controls.

A Gmail refresh token cannot be hashed like a password because Numero must later present it to Google to obtain a short-lived access token. The application therefore encrypts source credentials with AES-256-GCM before persistence. GCM provides confidentiality and authentication together, so modified ciphertext fails instead of producing altered plaintext.

Production validates that the integration encryption key is present, correctly encoded, and not a known development value. OAuth transaction encryption uses a different dedicated key from source-token encryption and session signing. Separation limits the impact of one credential being misconfigured or exposed.

Encryption is one layer, not a substitute for access control. Database operations remain scoped to the authenticated user, raw token values are excluded from logs, and only the integration service decrypts a token when it needs to call the authorized provider.

Numero issues a 15-minute access token and a 30-day refresh token for the web session. Both are delivered as Secure, HttpOnly cookies in production rather than browser local storage. JavaScript cannot read an HttpOnly session cookie, and Secure prevents the browser from sending it over an unencrypted connection.

Expiration is only one control. Logout fingerprints both tokens with SHA-256 and adds those fingerprints to a Redis-backed revocation store. Every later validation checks revocation and fails closed if that check cannot be completed. The server never needs to store the raw token to reject it.

A password change updates a server-side cutoff timestamp. Tokens issued before that point are rejected on their next request, while the browser performing the change receives a fresh pair. JWT validation also pins HS256, requires issuer, audience, expiry, and token identity claims, and ignores attacker-supplied key-selection headers.

Authorized message bodies and attachments may be processed ephemerally to identify financial facts, but they are not retained as Financial Memory. Numero persists approved structured metadata and provenance needed to explain a financial record. It does not become a permanent store for raw MIME, attachments, PDF content, prompts, or model responses.

Restricted content is also excluded from operational logging. Production refuses debug-level logging, and payment or provider failures are reduced to bounded status information rather than copied response bodies. Temporary extraction-comparison records used to evaluate quality are removed after 90 days.

No architecture can promise that incidents are impossible. These boundaries are intended to reduce what is collected, narrow who and what can access it, shorten credential exposure windows, and give users concrete revocation and deletion controls when they no longer want the service connected.