Enable Banking Consent Management#

Enable Banking (European Open Banking / PSD2) uses a session-based consent model: a user authorizes access to their bank (ASPSP) once, which creates a time-bounded session on the Enable Banking API. Sure stores the session ID and its expiry locally and keeps that expiry in continuous sync with the API's authoritative value during every import.

Key model: EnableBankingItem (enable_banking_items table) — one record per bank connection per family. It holds all consent-relevant fields: session_id, session_expires_at, authorization_id, status (enum: good / requires_update), and ASPSP metadata columns. 1

Authorization and Session Creation#

The consent flow has two steps, both driven by EnableBankingItem:

1. Start authorization — begin_authorization! (or start_authorization when called directly) calls GET /aspsps to re-fetch fresh ASPSP metadata, then calls POST /auth on the Enable Banking API via Provider::EnableBanking#start_authorization. The response's access.valid_until is derived from aspsp_maximum_consent_validity (capped at 90 days). The returned authorization_id is stored on the item. 2 3

2. Complete authorization — complete_authorization exchanges the OAuth callback code for a session via POST /sessions. The resulting session_id and access.valid_until are persisted; if the API omits valid_until, Sure defaults to 90 days from now. Status is reset to :good and provider accounts are imported from the session response. 4 5

Session Validity Checks#

Three methods on EnableBankingItem gate all session-dependent operations 6:

The EnableBankingItem::Syncer calls session_valid? as a guard at the top of every sync. If the session is invalid, it immediately sets status: :requires_update and aborts — no API calls are made. 7

Continuous Session Expiry Reconciliation#

Because the Enable Banking API is the authoritative source of session expiry, Sure re-syncs the local session_expires_at on every import via reconcile_session_expiry!.

Call path: EnableBankingItem::Syncer → import_latest_enable_banking_data → EnableBankingItem::Importer#import → fetch_session_data (calls GET /sessions/{session_id}) → reconcile_session_expiry!(session_data) 8

The reconciliation method extracts access.valid_until from the API response and updates session_expires_at only if the value has changed. It is deliberately fault-tolerant: bad timestamps (ArgumentError/TypeError) and database update failures are caught, logged as warnings, and swallowed so a sync is never derailed by expiry bookkeeping. 9

This prevents two drift states:

• Premature expiry: local record thinks the session expired, but the API extended it
• Stale validity: local record thinks the session is still valid, but the API revoked it

ASPSP Metadata Storage#

During start_authorization, Sure captures bank-capability metadata from the GET /aspsps response and stores it on the item 10:

These columns were added in migration 20260405120000.

Auth method selection: select_auth_method picks the best authentication approach from the ASPSP's auth_methods list using a priority order of REDIRECT > DECOUPLED > EMBEDDED, excluding hidden methods. If the requested PSU type has no matching methods, it falls back to methods without a declared type. 11

PSU type validation: A model-level validator (psu_type_in_aspsp_types) ensures the configured PSU type is always one the ASPSP advertises. 12

⚠️ GDPR / PII note: last_psu_ip contains the user's IP address required for PSU context headers. A TODO in the model flags this for a data retention policy (nullify after session expiry or 90 days). 13 14

Session Revocation#

revoke_session calls DELETE /sessions/{session_id} and clears session_id, session_expires_at, and authorization_id regardless of whether the API call succeeds. API errors are logged as warnings and suppressed so local cleanup always completes. 15 16

Key Source Files#