Skip to main content
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.

An den echten Ursprung gebunden

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.

Kein serverseitiges Geheimnis

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.

Echte Passkeys mit Herkunftsnachweis

Die Anmeldung erfordert auffindbare (residente) Anmeldeinformationen und erfasst bei der Registrierung die Attestierung des Authenticators, sodass Iru die Art des verwendeten Authenticators kennt.

Hardwaregebundene Geräteschlüssel

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

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

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

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

​
Nächste Schritte

Plattformarchitektur

Die Dienste, Regionen und Infrastruktur dahinter.

Mandantenisolierung

Wie die Daten jedes Mandanten getrennt und prüfbar bleiben.

Authentifikatoren

Die Passkeys und die Iru Access-App, die Benutzer täglich verwenden.

SAML- und OIDC-Apps

Konfigurieren Sie die Signierung und Verschlüsselung, die eine bestimmte App erhält.