Phishing-resistant
Passkeys and security keys
FIDO2 passkeys and security keys cannot be replayed on a fake site. Security keys are also device-bound and can be limited to approved models.
Platform / Sign-in
Authentication Methods
WebFrolic supports eleven ways to prove who someone is, from passwords and one-time codes to phishing-resistant passkeys and security keys, push approvals, and federated sign-in with SAML 2.0 and OpenID Connect. Each method states what it can be used for, so policy follows the strength of the method.
Available now in WebFrolic.
Why it matters
Two factors only help if the second one is the right kind.
A password and an email code are both things someone can be tricked into handing over. Policy that knows which methods are knowledge, possession, phishing-resistant or recovery-safe can ask for the right proof instead of simply more proof.
Recovery-aware
Not every method recovers an account
Only password, email, SMS, single-use passwords and security questions can be used for recovery, so a stolen device alone cannot reset an account.
Federated
Bring your own identity provider
Customers and tenants can sign up and sign in with SAML 2.0 or OAuth2/OIDC providers.
All eleven methods
What each method can do.
These are the defaults. Knowledge factors are something you know or receive; possession factors prove you hold a device. SAML and OAuth2/OIDC hand sign-in to another identity provider and are treated as knowledge factors by default. Administrators can update a method’s characteristics, such as its factor type, to match how they trust each provider.
| Method | Factor (default) | Sign-up | Sign-in | Recovery | Phishing-resistant | Device-bound | Several per user | User can reset | Admin or agent can enroll |
|---|---|---|---|---|---|---|---|---|---|
| Password | Knowledge | — | ✓ | ✓ | — | — | — | ✓ | — |
| Knowledge | ✓ | ✓ | ✓ | — | — | ✓ | ✓ | ✓ | |
| SMS | Possession | ✓ | ✓ | ✓ | — | — | ✓ | ✓ | ✓ |
| Single-use password | Knowledge | — | ✓ | ✓ | — | — | ✓ | — | ✓ |
| TOTP authenticator app | Possession | — | ✓ | — | — | — | ✓ | ✓ | — |
| Passkeys (FIDO2) | Possession | — | ✓ | — | ✓ | — | ✓ | — | — |
| Security key (FIDO2) | Possession | — | ✓ | — | ✓ | ✓ | ✓ | — | — |
| Push (APNs and FCM) | Possession | — | ✓ | — | — | — | ✓ | ✓ | — |
| Security questions | Knowledge | — | ✓ | ✓ | — | — | — | ✓ | — |
| SAML 2.0 (federated) | Knowledge | ✓ | ✓ | — | — | — | — | — | — |
| OAuth2 / OIDC (federated) | Knowledge | ✓ | ✓ | — | — | — | — | — | — |
Why characteristics matter
They decide the assurance of every session.
WebFrolic calculates authenticator assurance across the session from the characteristics of the methods a person has used. The table above shows the defaults; administrators can update them per authenticator, so treat any change as a security change. How assurance is calculated · Passkeys and security keys
| Characteristic | What it means | How it affects assurance |
|---|---|---|
| Factor type | Knowledge (something you know or receive) or possession (something you hold). Federated SAML and OIDC are knowledge by default. | Two methods of the same factor type do not count as two independent factors. |
| Phishing-resistant | The credential cannot be replayed on a look-alike site. Passkeys and security keys are phishing-resistant. | Needed to reach the strongest assurance levels. |
| Device-bound | The credential cannot leave a single device. Security keys are device-bound; synced passkeys are not. | Proves a specific, controlled device, which some policies require. |
| Sign-up, sign-in and recovery | Which journeys the method may be used in. | Recovery is only as strong as the weakest method allowed to perform it. |
| Several per user, user reset, admin enrollment | Whether people can hold more than one, reset it themselves, or have it enrolled for them. | Shapes how safely a lost credential can be replaced. |
When to use each
A short guide.
| Method | In one line | Typical use |
|---|---|---|
| Password | The familiar baseline; pair it with a second factor. | Fallback, always with MFA |
| A one-time code or link sent to a verified address; works for sign-up. | Customer sign-up and recovery | |
| SMS | A one-time code sent to a verified phone number; works for sign-up. | Customer sign-up and recovery |
| Single-use password | Codes that work once, such as recovery codes an administrator or support agent issues. | Support-assisted recovery |
| TOTP authenticator app | Time-based codes from apps such as Google Authenticator or 1Password. | Second factor for staff and customers |
| Passkeys (FIDO2) | Phishing-resistant sign-in that can sync across a person’s devices. | Default sign-in for everyone |
| Security key (FIDO2) | Phishing-resistant, device-bound hardware keys; can be limited to approved models by AAGUID. | Administrators and privileged roles |
| Push (APNs and FCM) | Approve a sign-in from a notification on a registered iOS or Android device. | Low-friction approval on a phone |
| Security questions | Answers stored encrypted; best kept as a recovery fallback. | Last-resort recovery only |
| SAML 2.0 (federated) | Sign up and sign in with a business’s own SAML identity provider. | Enterprise and tenant SSO |
| OAuth2 / OIDC (federated) | Sign up and sign in with a social or enterprise OpenID Connect provider. | Social and enterprise sign-in |
In the console
Set it up in four steps.
Menu names match the WebFrolic console. The setup guide has the detail.
Choose methods per persona
In Authenticators, enable the methods each persona may use: for example passkeys and email for customers, security keys for administrators.
Separate sign-in and recovery
Decide which methods may be used for recovery, and keep at least one that does not depend on the same device.
Set assurance levels
Raise the assurance level on sensitive roles and applications so only phishing-resistant methods satisfy them.
Test enrollment and recovery
Enroll each method with a test user, then test losing a device and recovering the account.
Before rollout
Questions worth answering.
Settle these first and the rollout is mostly configuration.
- List the methods each persona may use for sign-up, sign-in and recovery.
- Require a phishing-resistant method for administrators and privileged roles.
- Allow more than one passkey or security key so a lost device does not lock anyone out.
- Decide who may issue single-use passwords, and audit every one.
- Keep security questions for recovery only, if at all.
Related capabilities
Explore what connects to this.
These capabilities are usually configured together.
Evaluate with your scenario
Start with a concrete workflow.
Share the identities, resource boundary and decision you want to test. The walkthrough can focus on the relevant behavior rather than a generic feature tour.