Skip to main content
Authentication is the part of Iru that has to be hardest to fool. This page explains the cryptographic foundations: how people prove who they are without a shareable secret, how requests are signed and replay-proofed, and how the trust Iru extends to your apps is verifiable and rotates safely.

​
Phishing-resistant sign-in

Iru is built around passkeys (WebAuthn/FIDO2) and device-bound credentials - there is no password to phish, reuse, or breach.

Bound to the real origin

A passkey is cryptographically scoped to Iru’s exact origin. A credential minted for Iru simply won’t produce a valid signature on a look-alike phishing domain.

No server-side secret

Iru stores only the public key, the authenticator’s provenance (AAGUID), and a signature counter. The private key never leaves the person’s device, so there’s nothing on the server to steal.

Real passkeys, with provenance

Sign-in requires discoverable (resident) credentials and captures authenticator attestation at enrollment, so Iru knows the kind of authenticator in use.

Hardware-bound device keys

The Iru Access app holds its keys in the device’s secure hardware - the Secure Enclave on Apple, the TPM on Windows - and proves possession on every request with a per-credential signature.
Secure Enclave / TPM key custody is a property of the Iru Access app on the device; the server verifies the device-bound public-key signature on each call.

​
Proving the device is genuine

Beyond proving who is signing in, Iru can verify what they’re on. Apple DeviceCheck validates that a request comes from a genuine, untampered Apple device, and the check is fail-closed - bypassing it requires deliberate configuration. On Windows, TPM signals reported by Iru Access feed device-trust posture decisions. See Device trust.

​
Every request is signed and replay-proofed

Requests from the Iru Access app and integrations aren’t just bearer-token authenticated - they’re signed, and bound so a captured request can’t be reused.
MechanismStandardWhat it does
HTTP Message SignaturesRFC 9421Signs the method, path, authority, and key request components, so any tampering in transit invalidates the request. Schemes: ed25519, ecdsa-p256-sha256, rsa-v1_5-sha256.
Content-DigestRFC 9530A SHA-256/512 digest binds the signature to the exact request body.
Single-use, time-boxed proofs-Signatures carry a created/expires window (max ~10 min, ≤5s clock skew) and a nonce stored with a uniqueness constraint - a replayed nonce is rejected.
DPoPRFC 9449Sender-constrained, proof-of-possession tokens bound to a client-held key (with htm/htu/ath binding and per-proof JTIs). A stolen bearer token is useless without the private key.
The Iru Access app additionally pins the TLS certificate of the service it talks to (an agent-side control), so it won’t trust an intercepting proxy.

​
Verifiable SSO trust - with safe key rotation

When Iru acts as your identity provider, the statements it sends your apps are signed so each app can verify they genuinely came from Iru and weren’t altered.
SAML responses and assertions are signed with XML Signature; assertions can additionally be encrypted to the service provider. OIDC ID tokens are JWS-signed. Iru supports modern algorithms - RSA/ECDSA with SHA-256 or stronger, AES-GCM content encryption, and RSA-OAEP key wrapping - selectable per integration to match what each service requires.
Iru publishes its public keys and metadata at standard endpoints - a JWKS document, OAuth Authorization Server Metadata (RFC 8414), and OpenID Connect Discovery - so relying parties configure and refresh keys automatically.
Signing keys rotate on a 30-day schedule with a 24-hour overlap: a new key takes over while the previous one keeps verifying in-flight tokens, then expires rather than being deleted. Key types include ECDSA P-256/384/521 and RSA-2048. This limits the blast radius of any single key with no interruption to your apps.

​
Encryption and sessions

  • In transit: all traffic is protected with TLS; session cookies are Secure, HttpOnly, and SameSite.
  • At rest: sensitive fields are encrypted with AES-256-GCM using a key supplied at runtime from a managed secret store.
  • Sessions: sign-in sessions are short-lived with a sliding inactivity window; longer-lived flows use rotating refresh tokens with one-time code challenges (PKCE S256) and replay detection. Sessions can be revoked globally, per user, or per authenticator, so a lost device or compromised account can be cut off immediately. See Credentials and sessions.

​
Where to go next

Platform architecture

The services, regions, and infrastructure behind this.

Multi-tenant isolation

How each tenant’s data stays separate and auditable.

Authenticators

The passkeys and Iru Access app people use day to day.

SAML & OIDC apps

Configure the signing and encryption a specific app receives.