Web banking authentication security
Mobile trust is a hardware key.
What does the browser hold instead?
A concept-learning portal for the web security layer a mobile bank needs when it adds web banking — FAPI 2.0, DPoP, PKCE, sender-constrained tokens, and the rest of the stack, built as the explanation itself rather than a summary of one.
The mobile→web problem
A full mobile bank runs on a hardware root of trust: a private key in the phone’s secure enclave, gated by biometrics, signing a hash into every request so the backend knows the call came from that bound device. Now the bank is adding web banking — and the browser gives you none of that for free. This portal works out what the web security layer has to be to hold the same bar for UK/EU banking, and teaches every concept it touches.
It’s a learning artifact, not a product. I built the explanation rather than reading one — the fastest way to understand something well enough to explain it to a client.
The core problem
Mobile security rests on hardware you control. The browser doesn’t offer an equivalent. So the web strategy is two moves: get as close to hardware binding as the browser allows (passkeys + sender-constrained tokens), then compensate for the residual gap with layered risk signals. Every page here hangs off that one diagnosis.
Five layers of trust
The whole domain decomposes into eight capabilities across five layers, detailed below. The Atlas is the full concept glossary.
| Layer | Question it answers | Capabilities |
|---|---|---|
| Establish | Who is the user? | User authentication (C1) |
| Bind & maintain | Is every request from the real, bound client? | Device binding & request integrity (C2) |
| Protect | Is the browser environment safe? | Browser-side security (C3) · anti-phishing (C4) |
| Enforce | Where is policy applied? | Gateway / API edge (C5) |
| Judge | Is this session actually risky? | Fraud & device intelligence (C6/C7) · risk decisioning (C8) |
Capability Map
The web security layer decomposes into eight capabilities across the five layers above. This is the architecture; each row becomes its own deep-dive.
Mental model: establish trust (who + what device) → maintain it (every request) → protect the environment (the browser) → enforce it (the gateway) → judge it (risk + fraud).
| # | Capability | The need | Ways to achieve it | Standard |
|---|---|---|---|---|
| C1 | User Authentication | Prove the person is the genuine customer, un-replayably. | WebAuthn/FIDO2 passkeys; OIDC + PKCE; OTP fallback (weak). | FIDO2, OIDC |
| C2 | Device Binding & Request Integrity | Tie the session to a device and prove every call — the web equivalent of the mobile enclave key + per-request hash. | Device-bound passkey / WebCrypto key; DPoP or mTLS; short-lived tokens; PSD2 dynamic linking. | FAPI 2.0, WebAuthn, DPoP |
| C3 | Browser / Client-Side Security | Lock down delivery, rendering and client code (clickjacking, Magecart, XSS). | TLS/HSTS, CSP, frame-ancestors, SameSite cookies, CORS, anti-CSRF; SRI, RASP, DOM monitoring. | OWASP ASVS, CSP |
| C4 | Anti-Phishing | Prevent and detect credential-harvesting; make harvested credentials useless. | Origin-bound passkeys; DMARC/DKIM/SPF; brand + look-alike domain monitoring. | FIDO, DMARC |
| C5 | Gateway / API Edge | One point that applies the web-channel policy and validates PoP tokens, without changing product APIs. | Channel-aware policy; DPoP/mTLS validation + anti-replay; FAPI 2.0 (PAR, PKCE); WAF; bot management. | FAPI 2.0, OAuth2 |
| C6 | Fraud & Malware / Device-Threat | Detect compromised devices, RATs, emulators, known-fraud devices. | Malware/RAT/emulator SDK; ThreatMetrix; bot detection; connection anomaly. | Vendor (ThreatMetrix) |
| C7 | Device Intelligence & Behavioral | Continuous signal beyond login feeding the risk decision. | Fingerprinting + reputation; behavioral biometrics; velocity/geo. | Vendor integration |
| C8 | Risk Decisioning & Adaptive Step-Up | Decide in real time: allow, challenge, or block — offsetting the web’s structural weakness. | Risk engine (rules + ML); step-up orchestration; PSD2 TRA exemptions; gateway tie-in. | PSD2 SCA/RTS |
Where to start
- Atlas — every concept, grouped, one line each.
- FAPI 2.0 — the bank-grade rulebook for OAuth.
- Sender-Constrained Tokens — the direct web heir to the mobile per-request hash.
- Try It — poke the concepts: decode a token, generate a PKCE pair, watch a stolen token fail.
Operating principle: speed of learning beats speed of shipping. A narrow set of concepts understood completely and shown interactively beats a broad glossary understood vaguely.