> ## Documentation Index
> Fetch the complete documentation index at: https://docs.iru.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Authentication architecture

> How Iru makes sign-in phishing-resistant, signs and replay-proofs every request, and establishes verifiable SSO trust with rotating keys.

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.

<CardGroup cols={2}>
  <Card title="Bound to the real origin" icon="link">
    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.
  </Card>

  <Card title="No server-side secret" icon="user-shield">
    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.
  </Card>

  <Card title="Real passkeys, with provenance" icon="fingerprint">
    Sign-in requires discoverable (resident) credentials and captures
    authenticator attestation at enrollment, so Iru knows the kind of authenticator
    in use.
  </Card>

  <Card title="Hardware-bound device keys" icon="microchip">
    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.
  </Card>
</CardGroup>

<Note>
  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.
</Note>

## 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](/en/identity/authentication/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.

| Mechanism                         | Standard | What it does                                                                                                                                                                             |
| --------------------------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **HTTP Message Signatures**       | RFC 9421 | Signs 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-Digest**                | RFC 9530 | A 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.                         |
| **DPoP**                          | RFC 9449 | Sender-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.

<AccordionGroup>
  <Accordion title="Signed (and optionally encrypted) SSO" icon="file-signature">
    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.
  </Accordion>

  <Accordion title="Standards-based discovery" icon="compass">
    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.
  </Accordion>

  <Accordion title="Zero-downtime key rotation" icon="arrows-rotate">
    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.
  </Accordion>
</AccordionGroup>

## 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](/en/identity/security/credentials-and-sessions).

## Where to go next

<CardGroup cols={2}>
  <Card title="Platform architecture" icon="server" href="/en/identity/security/platform-architecture">
    The services, regions, and infrastructure behind this.
  </Card>

  <Card title="Multi-tenant isolation" icon="database" href="/en/identity/security/multi-tenant-isolation">
    How each tenant's data stays separate and auditable.
  </Card>

  <Card title="Authenticators" icon="key" href="/en/identity/authentication/authenticators">
    The passkeys and Iru Access app people use day to day.
  </Card>

  <Card title="SAML & OIDC apps" icon="file-signature" href="/en/identity/applications/saml-applications">
    Configure the signing and encryption a specific app receives.
  </Card>
</CardGroup>