> ## 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.

# Authentifizierungsarchitektur

> Wie Iru die Anmeldung Phishing-resistent macht, jede Anfrage signiert und gegen Replay schützt und mit rotierenden Schlüsseln überprüfbares SSO-Vertrauen herstellt.

Die Authentifizierung ist der Teil von Iru, der am schwersten zu täuschen sein muss. Im Folgenden finden Sie die
kryptografischen Grundlagen: wie Benutzer ohne ein teilbares Geheimnis nachweisen,
wer sie sind, wie Anfragen signiert und gegen Replay geschützt werden und wie das Vertrauen,
das Iru Ihren Apps entgegenbringt, überprüfbar ist und sicher rotiert.

## Phishing-resistente Anmeldung

Iru basiert auf **Passkeys (WebAuthn/FIDO2)** und gerätegebundenen Anmeldeinformationen.
Es gibt kein Passwort, das abgegriffen, wiederverwendet oder kompromittiert werden könnte.

<CardGroup cols={2}>
  <Card title="An den echten Ursprung gebunden" icon="link">
    Ein Passkey ist kryptografisch auf den exakten Ursprung von Iru beschränkt. Eine für Iru
    erzeugte Anmeldeinformation erzeugt auf einer ähnlich aussehenden Phishing-Domäne
    schlicht keine gültige Signatur.
  </Card>

  <Card title="Kein serverseitiges Geheimnis" icon="user-shield">
    Iru speichert nur den **öffentlichen** Schlüssel, die Herkunft des Authenticators (AAGUID)
    und einen Signaturzähler. Der private Schlüssel verlässt nie das Gerät des Benutzers, sodass
    es auf dem Server nichts zu stehlen gibt.
  </Card>

  <Card title="Echte Passkeys mit Herkunftsnachweis" icon="fingerprint">
    Die Anmeldung erfordert auffindbare (residente) Anmeldeinformationen und erfasst bei der Registrierung
    die Attestierung des Authenticators, sodass Iru die Art des verwendeten Authenticators
    kennt.
  </Card>

  <Card title="Hardwaregebundene Geräteschlüssel" icon="microchip">
    Die Iru Access-App speichert ihre Schlüssel in der sicheren Hardware des Geräts (der
    **Secure Enclave** bei Apple, dem **TPM** unter Windows) und weist bei
    jeder Anfrage den Besitz mit einer Signatur pro Anmeldeinformation nach.
  </Card>
</CardGroup>

<Note>
  Die Schlüsselverwahrung in Secure Enclave / TPM ist eine Eigenschaft der Iru Access-App auf dem
  Gerät; der Server verifiziert bei jedem Aufruf die Signatur des gerätegebundenen öffentlichen Schlüssels.
</Note>

## Nachweis, dass das Gerät echt ist

Über den Nachweis hinaus, *wer* sich anmeldet, kann Iru verifizieren, *auf welchem Gerät* dies geschieht. Apple
**DeviceCheck** validiert, dass eine Anfrage von einem echten, unveränderten Apple-Gerät
stammt, und die Prüfung ist **fail-closed**. Um sie zu umgehen, ist eine bewusste
Konfiguration erforderlich. Unter Windows fließen von Iru Access gemeldete TPM-Signale in Device Trust-Entscheidungen
zum Gerätestatus ein. Siehe [Device Trust](/de/identity/authentication/device-trust).

## Jede Anfrage ist signiert und gegen Replay geschützt

Anfragen von der Iru Access-App und von Integrationen werden nicht nur per Bearer-Token
authentifiziert. Sie sind **signiert** und so gebunden, dass eine abgefangene Anfrage nicht
wiederverwendet werden kann.

| Mechanismus | Standard | Funktion |
| - | - | - |
| **HTTP Message Signatures** | RFC 9421 | Signiert Methode, Pfad, Authority und wichtige Anfragekomponenten, sodass jede Manipulation während der Übertragung die Anfrage ungültig macht. Schemata: `ed25519`, `ecdsa-p256-sha256`, `rsa-v1_5-sha256`. |
| **Content-Digest** | RFC 9530 | Ein SHA-256/512-Digest bindet die Signatur an den exakten Anfragetext. |
| **Einmalige, zeitlich begrenzte Nachweise** | - | Signaturen enthalten ein `created`/`expires`-Fenster (max. ca. 10 Min., ≤5 s Uhrenabweichung) und eine **Nonce, die mit einer Eindeutigkeitsbedingung gespeichert wird**. Eine wiederverwendete Nonce wird abgelehnt. |
| **DPoP** | RFC 9449 | Absendergebundene Proof-of-Possession-Tokens, die an einen vom Client gehaltenen Schlüssel gebunden sind (mit `htm`/`htu`/`ath`-Bindung und JTIs pro Nachweis). Ein gestohlenes Bearer-Token ist ohne den privaten Schlüssel nutzlos. |

Die Iru Access-App pinnt zusätzlich das TLS-Zertifikat des Dienstes, mit dem sie kommuniziert
(eine agentenseitige Kontrolle), sodass sie keinem abfangenden Proxy vertraut.

## Überprüfbares SSO-Vertrauen mit sicherer Schlüsselrotation

Wenn Iru als Ihr Identitätsanbieter fungiert, sind die Erklärungen, die es an Ihre Apps sendet,
**signiert**, sodass jede App verifizieren kann, dass sie tatsächlich von Iru stammen und nicht
verändert wurden.

<AccordionGroup>
  <Accordion title="Signiertes (und optional verschlüsseltes) SSO" icon="file-signature">
    SAML-Antworten und -Assertions werden mit XML Signature signiert; Assertions können
    zusätzlich für den Service Provider **verschlüsselt** werden. OIDC-ID-Tokens sind
    JWS-signiert. Iru unterstützt moderne Algorithmen (RSA/ECDSA mit SHA-256 oder
    stärker, AES-GCM-Inhaltsverschlüsselung und RSA-OAEP-Key-Wrapping), auswählbar
    pro Integration, je nach den Anforderungen des jeweiligen Dienstes.
  </Accordion>

  <Accordion title="Standardbasierte Ermittlung" icon="compass">
    Iru veröffentlicht seine öffentlichen Schlüssel und Metadaten an Standard-Endpunkten: ein **JWKS**-Dokument,
    OAuth Authorization Server Metadata (RFC 8414) und OpenID Connect
    Discovery. Relying Parties konfigurieren und aktualisieren Schlüssel automatisch.
  </Accordion>

  <Accordion title="Schlüsselrotation ohne Ausfallzeit" icon="arrows-rotate">
    Signaturschlüssel rotieren nach einem **30-Tage**-Zeitplan mit einer **24-stündigen Überlappung**: Ein neuer
    Schlüssel übernimmt, während der vorherige noch laufende Tokens verifiziert, und läuft dann
    ab, statt gelöscht zu werden. Zu den Schlüsseltypen gehören ECDSA P-256/384/521 und
    RSA-2048. Dies begrenzt die Auswirkungen eines einzelnen Schlüssels ohne Unterbrechung
    für Ihre Apps.
  </Accordion>
</AccordionGroup>

## Verschlüsselung und Sitzungen

* **Bei der Übertragung:** Der gesamte Datenverkehr ist mit TLS geschützt; Sitzungscookies sind
  `Secure`, `HttpOnly` und `SameSite`.
* **Im Ruhezustand:** Sensible Felder werden mit **AES-256-GCM** verschlüsselt, mit einem Schlüssel,
  der zur Laufzeit aus einem verwalteten Secret Store bereitgestellt wird.
* **Sitzungen:** Anmeldesitzungen sind kurzlebig und haben ein gleitendes Inaktivitätsfenster;
  länger laufende Abläufe verwenden rotierende Refresh-Tokens mit Einmal-Code-Challenges
  (PKCE `S256`) und Replay-Erkennung. Sitzungen können **global, pro
  Benutzer oder pro Authenticator** widerrufen werden, sodass ein verlorenes Gerät oder ein kompromittiertes Konto
  sofort abgeschnitten werden kann. Siehe
  [Anmeldeinformationen und Sitzungen](/de/identity/security/credentials-and-sessions).

## Nächste Schritte

<CardGroup cols={2}>
  <Card title="Plattformarchitektur" icon="server" href="/de/identity/security/platform-architecture">
    Die Dienste, Regionen und Infrastruktur dahinter.
  </Card>

  <Card title="Mandantenisolierung" icon="database" href="/de/identity/security/multi-tenant-isolation">
    Wie die Daten jedes Mandanten getrennt und prüfbar bleiben.
  </Card>

  <Card title="Authentifikatoren" icon="key" href="/de/identity/authentication/authenticators">
    Die Passkeys und die Iru Access-App, die Benutzer täglich verwenden.
  </Card>

  <Card title="SAML- und OIDC-Apps" icon="file-signature" href="/de/identity/applications/saml-applications">
    Konfigurieren Sie die Signierung und Verschlüsselung, die eine bestimmte App erhält.
  </Card>
</CardGroup>