Chapter 4: Security & Authentication

The Security Imperative

Financial data is among the most sensitive information exchanged electronically. A single breach can result in significant financial losses, regulatory penalties, and irreparable damage to reputation. Security must be designed into every layer of financial data exchange.

OAuth 2.0 & OpenID Connect

OAuth 2.0 is the industry standard for authorization, widely used in open banking and fintech APIs. OpenID Connect adds an identity layer on top of OAuth 2.0 for authentication.

OAuth 2.0 Flow for Open Banking

// Step 1: Client redirects user to authorization endpoint
GET https://bank.example.com/oauth/authorize?
  response_type=code&
  client_id=CLIENT_ID&
  redirect_uri=https://app.example.com/callback&
  scope=accounts transactions&
  state=RANDOM_STATE

// Step 2: User authenticates and grants consent

// Step 3: Bank redirects back with authorization code
https://app.example.com/callback?code=AUTH_CODE&state=RANDOM_STATE

// Step 4: Client exchanges code for access token
POST https://bank.example.com/oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=AUTH_CODE&
redirect_uri=https://app.example.com/callback&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET

// Step 5: Response with access token
{
  "access_token": "eyJhbGciOiJSUzI1NiIs...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",
  "scope": "accounts transactions"
}
            

Security Best Practices

PKCE (Proof Key for Code Exchange): Prevents authorization code interception
State Parameter: Prevents CSRF attacks
Short-lived Tokens: Access tokens expire in 15-60 minutes
Refresh Token Rotation: One-time use refresh tokens
Scope Limitation: Request minimum necessary permissions

JWT (JSON Web Tokens)

JWTs are self-contained tokens that carry claims about the user and can be verified without database lookups. They're commonly used in financial APIs for stateless authentication.

// JWT Structure: header.payload.signature

// Header
{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "key-2025-01"
}

// Payload
{
  "iss": "https://auth.bank.example.com",
  "sub": "user@example.com",
  "aud": "api.bank.example.com",
  "exp": 1735138200,
  "iat": 1735134600,
  "scope": "accounts:read transactions:read",
  "account_id": "ACC-12345"
}

// Signature (RS256)
RSASHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  privateKey
)
            

JWT Security Considerations

⚠️ Warning: Never put sensitive data like passwords or credit card numbers in JWT payloads. JWTs are encoded, not encrypted, and can be decoded by anyone.

Use strong signing algorithms (RS256, ES256)
Validate signature, issuer, audience, and expiration
Keep private keys secure (HSM when possible)
Implement token revocation for sensitive operations
Rotate signing keys regularly

Mutual TLS (mTLS)

Mutual TLS provides strong authentication by requiring both client and server to present certificates. It's commonly used for high-security B2B integrations and regulatory reporting.

mTLS Handshake Process

Client initiates TLS connection to server
Server presents its certificate to client
Client validates server certificate against trusted CA
Server requests client certificate
Client presents its certificate to server
Server validates client certificate
Encrypted communication channel established

Certificate Management

Certificate Authority: Use trusted CA for production (DigiCert, GlobalSign)
Certificate Expiration: Monitor and renew before expiry (typically 1-2 years)
Certificate Revocation: Implement CRL or OCSP checking
Key Storage: Store private keys in HSM or secure key vault

Encryption Standards

Transport Layer Security (TLS 1.3)

TLS 1.3 is mandatory for all financial data exchange. It provides encryption, integrity, and authentication for data in transit.

Feature	TLS 1.2	TLS 1.3
Handshake	2 round trips	1 round trip (faster)
Cipher Suites	37 options (many weak)	5 strong options only
Forward Secrecy	Optional	Always enabled
0-RTT Resumption	No	Yes (with replay protection)

Data at Rest Encryption

Financial data must be encrypted when stored in databases, file systems, or backups:

AES-256-GCM: Industry standard symmetric encryption
Key Management: Use AWS KMS, Azure Key Vault, or HashiCorp Vault
Key Rotation: Rotate encryption keys annually or when compromised
Field-Level Encryption: Encrypt PII fields individually for granular access

Tokenization

Tokenization replaces sensitive data with non-sensitive tokens, critical for PCI DSS compliance in payment systems.

// Original PAN (Primary Account Number)
4111 1111 1111 1111

// Tokenized (format-preserving)
4622 7890 1234 5678

// Token properties:
// - Same length and format as original
// - No mathematical relationship to original
// - Useless to attackers without tokenization system
// - Can be used for display and routing
            

Tokenization vs Encryption

Aspect	Tokenization	Encryption
Reversibility	Lookup in vault required	Decrypt with key
Format	Can preserve format	Different format
PCI DSS Scope	Reduces scope significantly	Still in scope
Performance	Lookup overhead	CPU overhead

Compliance Requirements

PCI DSS (Payment Card Industry Data Security Standard)

Any organization that stores, processes, or transmits credit card data must comply with PCI DSS:

Requirement 1-2: Firewall and network segmentation
Requirement 3-4: Protect stored data, encrypt transmission
Requirement 5-6: Anti-malware, secure development
Requirement 7-9: Access control, monitoring, physical security
Requirement 10-12: Logging, testing, policies

GDPR (General Data Protection Regulation)

When processing EU citizens' data, implement these GDPR requirements:

Lawful Basis: Obtain consent or establish legitimate interest
Data Minimization: Collect only necessary data
Right to Erasure: Delete data upon request
Data Portability: Provide data in machine-readable format
Breach Notification: Report breaches within 72 hours
Privacy by Design: Build privacy into systems from start

PSD2 (Payment Services Directive 2)

European regulation requiring Strong Customer Authentication (SCA) and secure communication:

SCA: Two-factor authentication for payments >€30
Qualified Certificates: Use eIDAS-compliant certificates
API Security: OAuth 2.0, mutual TLS required
Consent Management: Explicit customer consent for data access

Security Best Practices

Defense in Depth

Implement multiple layers of security controls:

Network Layer: Firewalls, IDS/IPS, DDoS protection
Application Layer: WAF, API gateway, rate limiting
Data Layer: Encryption, tokenization, access controls
Identity Layer: MFA, RBAC, principle of least privilege
Monitoring Layer: SIEM, anomaly detection, audit logs

API Security

// Security headers for financial APIs
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
Content-Security-Policy: default-src 'self'
Referrer-Policy: no-referrer
Permissions-Policy: geolocation=(), microphone=(), camera=()

// Rate limiting
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 87
X-RateLimit-Reset: 1735138200

// API versioning
API-Version: 2.0
            

Incident Response

Prepare for security incidents with a comprehensive response plan:

Detection: Continuous monitoring and alerting
Containment: Isolate affected systems immediately
Eradication: Remove threat and patch vulnerabilities
Recovery: Restore services with enhanced security
Lessons Learned: Document and improve processes

Security is not a one-time implementation but an ongoing process. Regular audits, penetration testing, and security training are essential for maintaining robust protection of financial data.