1 of 4
One token. One key. One use.
IronIdP
01Thesis
One-time keys. No replays. Instant revocation.
Every IronIdP token is backed by a one-time key that is used up on first use. A stolen token is useless after its owner's next request: whichever party presents the token first consumes its key, the other party's next request fails, the session is invalidated, and the attempt is logged. Multi-factor authentication is mandatory and phishing-resistant: PIV/CAC and FIDO2/WebAuthn. Cryptography runs in wolfSSL's wolfCrypt module, FIPS 140-3 validated at Level 1.
- 001A token check proves the token is live at this moment, not that it was valid once. The check rotates the key as it runs.Holds for: every request
- 002A used key is atomically replaced or deleted. There is no instant in which both the old and the new key work.Holds for: every token
- 003A sign-in is a chain of one-time-key steps behind a phishing-resistant authenticator. Nobody can insert themselves into a sign-in in progress.Holds for: every sign-in
- 004One-time keys cover signup, login, session tokens, refresh, revocation and account deletion.Holds for: every flow
02Standards
A FIPS 140-3 validated module. Phishing-resistant MFA.
IronIdP uses wolfSSL's wolfCrypt module, FIPS 140-3 validated at overall Level 1 (NIST CMVP certificate 4718), through IronVelo's wolfSSL partnership.
OMB Memorandum M-22-09 states that for agency staff, contractors, and partners, phishing-resistant MFA is required, and tells agency systems to drop methods that fail to resist phishing: SMS, voice calls, one-time codes, push notifications. NIST SP 800-63B requires federal agencies to have their staff, contractors, and partners use phishing-resistant authentication, and names PIV and CAC cards and WebAuthn (FIDO2) as the ways to provide it. Phishing resistance, as NIST defines it, keeps secrets and valid authenticator outputs from an impostor verifier: a relay between user and IronIdP obtains neither.
03Comparison
Against the token designs in use today
| Property | In use today | IronIdP |
|---|---|---|
| A copied token | Bearer token (RFC 6750): anyone holding it can use it until it expires. | Useless after the owner's next request; the attempt is logged. |
| A bound token | DPoP (RFC 9449; Okta), mTLS (RFC 8705), Entra Token Protection: a copy fails elsewhere; a compromised client yields key and token together, valid until expiry. | A compromised client yields token and key too; that session ends at the owner's next request, and is logged. |
| A replay attempt | An ordinary request, unless it is a replayed refresh token under rotation (RFC 9700; Auth0). | Fails, and is logged as a security event for immediate analysis. |
| A sign-in in progress | A phishing-resistant authenticator stops a relay at the first step; later steps are each product's own. | A phishing-resistant authenticator stops the relay; one-time-key steps stop replay of any later step. |
| Revocation | A blocklist or introspection call per request; with Entra Continuous Access Evaluation, events pushed to subscribed services in near real time. | Delete the key; every session of a user in one step at any scale, one comparison inside each request's check; no separate blocklist. |
| Delegating authority | Token exchange (RFC 8693): the server sets the delegated scope; no narrowing is required. | Strictly narrower, checked by Scope-Forge; one hop; revoked with its parent. |
- Today
- Bearer token (RFC 6750): anyone holding it can use it until it expires.
- IronIdP
- Useless after the owner's next request; the attempt is logged.
- Today
- DPoP (RFC 9449; Okta), mTLS (RFC 8705), Entra Token Protection: a copy fails elsewhere; a compromised client yields key and token together, valid until expiry.
- IronIdP
- A compromised client yields token and key too; that session ends at the owner's next request, and is logged.
- IronIdP
- Fails, and is logged as a security event for immediate analysis.
- Today
- A phishing-resistant authenticator stops a relay at the first step; later steps are each product's own.
- IronIdP
- A phishing-resistant authenticator stops the relay; one-time-key steps stop replay of any later step.
- Today
- A blocklist or introspection call per request; with Entra Continuous Access Evaluation, events pushed to subscribed services in near real time.
- IronIdP
- Delete the key; every session of a user in one step at any scale, one comparison inside each request's check; no separate blocklist.
- Today
- Token exchange (RFC 8693): the server sets the delegated scope; no narrowing is required.
- IronIdP
- Strictly narrower, checked by Scope-Forge; one hop; revoked with its parent.
A copied token
A bound token
A replay attempt
A sign-in in progress
Revocation
Delegating authority
04Rotation
Every use rotates the key
Inside a sign-in, a replayed step invalidates the chain and sign-in starts again from a clean state. A mistyped code can be retried. A replay cannot.
05Revocation
Revocation is instant at any scale, with no blocklist
Revoking a token deletes its key. Every check reads the token's own key record, so revoking a user's every session is one step whose cost does not grow with the number of sessions, confirmed by one comparison in that check: no separate blocklist, no revocation database to scan.
06Delegation
Delegation that cannot widen
A contractor or an agent can hold part of a token's authority, never more. The delegated token is strictly narrower than its parent, and Scope-Forge checks that it is. It cannot be split again, and revoking the parent revokes every delegation from it.
07Assurance
What is verified, stated exactly
IronIdP's sign-in flows are correct by construction at the state-transition level: each step can be reached only from the steps permitted before it, enforced when the software is built, and no further claim is made for the flows. The machine-checked proofs sit beneath them: IronIdP runs on IronVelo's verified core libraries, and its permissions are written in Scope-Forge and enforced by the policies Scope-Forge compiles. Its external dependencies are pinned and audited. IronIdP sits beside the OAuth 2.0 or OpenID Connect sign-in provider already in place and connects to it through a hardened adapter that keeps the one-time-key protection: the tokens your applications hold are IronIdP's.