Why we are building WebFrolic
WebFrolic is being built for teams that need customer identity, tenant administration, workforce access and operational workflows to work together. The central belief: identity security is a system property, not a sign-in screen.
Founder & CTO
Author of Only as Secure as the Weakest Link, October 2026.
WebFrolic grew from studying how identity failures actually happen: credentials that stay valid after their owner leaves, privileged permissions that accumulate, recovery paths that accept too little evidence, and security checks that are not repeated when the surrounding flow changes.
The product's direction is to make the difficult parts of identity first-class design concerns: explicit state, distinct ceremonies, policy boundaries that match the identity, and audit records designed into the architecture.
Read the security white paper ↓The lessons behind the product
They often come from everyday controls that are absent, incomplete or disconnected from the rest of the system. These recurring patterns informed the product's design.
Weak credential storage, missing rate limits and absent multi-factor authentication have repeatedly turned small weaknesses into scalable attacks. Defenses should be part of the product, not optional add-ons forgotten during implementation.
Signup, enrollment, authentication and recovery have different preconditions. Reusing a path without preserving the full server-side state can create transitions that no single step appears to permit.
Employees, administrators, customers, service users and tenant administrators do not carry the same risk or need the same rules. A single flat set of policies makes that difference hard to enforce consistently.
Recovery and help-desk procedures can be targeted through social engineering. Support assistance should be constrained so it helps the account owner regain access rather than becoming a shortcut around their credentials.
When several people use the same secret, actions become hard to attribute. Service and machine identity constructs provide a route away from shared accounts and personally owned integration keys.
No connected system can promise that incidents will never happen. A practical design needs to make unusual changes discoverable and give operators ways to limit their impact.
Three design principles
The goal is not to make every action equally difficult. It is to put the appropriate checks around the action, record what happened and make the scope of an incident easier to understand.
Use context such as the identity category, resource, credential and policy configuration to decide which assurance steps are required for a sensitive action.
Audit capture is part of the architecture. Records include user, session and device information to support investigation, operational learning and compliance work.
Make identity changes reviewable and provide controls such as rate limits, network rules, session management and configurable recovery safeguards to help constrain an incident.
From lesson to implementation
These are examples of how the security lessons translate into documented WebFrolic capabilities. They are not a claim that any control removes every risk.
| Failure pattern | Design response | How to evaluate it |
|---|---|---|
| Credential stuffing | Rate limits can be customized by user, session, tenant, IP address and operation. | Review the rate-limit configuration and how shared proxies are handled. |
| Chained identity flows | Flow state lives on the server, including past/current/next steps and rules for valid transitions; enrollment, signup and verification are distinct. | Walk through enrollment and recovery paths, including invalid transitions. |
| Over-privileged identities | Customer, employee and administrator classifications can have different authenticator, role, network, session and profile rules. | Compare the policies for each identity category. |
| Shared or ownerless credentials | Service users and machine identities provide explicit models for non-person and application identities. | Inspect role assignment, API-key controls and attribution of actions. |
| Weak recovery process | Recovery can have its own assurance requirements, credential handling, account lock period and API-key revocation rules. | Test successful and unsuccessful recovery, including support-assisted recovery. |
| Incomplete investigation records | Audit trails capture actions against resources with user, session and device context. | Trace a representative operation from the initiating identity through the resulting record. |
Read the original thinking
The security white paper explains the breach patterns studied and the design choices made in response. The product guide and API reference give evaluators a route into the actual surfaces and operations.
“Only as Secure as the Weakest Link” — the original design narrative and security lessons.
Download the paper (PDF) →Understand the identity personas, dashboards, tenant use cases and everyday workflows described for WebFrolic.
Explore the product guide →Inspect the documented operations for users, tenants, groups, SCIM, applications, sessions, secrets and variables.
Open the API reference →Compare the approach against your needs
Tell us where your current identity model breaks down. We can walk through the relevant policy, integration, recovery and audit behavior with your team.
