Autorisierung ohne Authentifizierung

Authentifizierung und Autorisierung lösen verschiedene Probleme

Die meisten Anwendungen beginnen mit einer Schranke. Bevor ein Nutzer etwas tun kann, muss er seine Identität nachweisen: eine E-Mail eingeben, einen Bestätigungscode abrufen, ein Passwort wählen oder einem Magic Link folgen. Dieser Schritt ist die Authentifizierung, also das Bestätigen, wer jemand ist, gegenüber einem Datensatz einer zentralen Instanz.

Die Autorisierung beantwortet eine andere Frage: Was darf diese Person tun? Teams fassen beides meist zu einem einzigen „Anmelden"-Ablauf zusammen, doch es bleiben getrennte Vorgänge. Ihre Trennung bringt eine nützliche Erkenntnis zutage.

Ein Server muss nicht wissen, wer ein Nutzer ist, um durchzusetzen, was dieser tun darf.

JustCall baut auf dieser Trennung auf. Es gibt keine Registrierung, keine Kontotabelle, kein Passwort und keine persönlichen Daten auf dem Server. Die Autorisierung trägt das gesamte System, während Authentifizierung im klassischen Sinn fehlt. Drei Bausteine machen das möglich: ein privater Schlüssel, ein öffentlicher Schlüssel und eine delegierte Rolle, die wir Master-Schlüssel nennen.

Wie Public-Key-Identität Konten ersetzt

Wenn du JustCall zum ersten Mal öffnest, erzeugt der Browser lokal ein Geheimnis und überträgt es nie. Daraus leitet er ein Schlüsselpaar ab, und die öffentliche Hälfte wird zu deiner Nutzer-ID:

// The private key is generated on your device. The server never sees it.
privateKey = crypto.randomUUID();

// The PUBLIC half, encoded as text, becomes your user ID.
userId = await derivePublicUserId(privateKey);

Die Kennung ist der öffentliche Schlüssel selbst, keine Datenbankzeile, die auf ihn verweist. Diese eine Entscheidung beseitigt mehrere Risiken klassischer Kontosysteme:

Kein Registrierungsschritt. Der Server akzeptiert mit einer ID signierte Anfragen, sobald er sie erstmals sieht.
Keine E-Mail, keine Telefonnummer. Die ID stammt aus einem zufälligen Geheimnis auf deinem Gerät, nicht aus einem persönlichen Detail.
Kein Passwort. Es gibt kein gemeinsames Geheimnis zu speichern, zu hashen oder zu verlieren, da der Server stets nur den öffentlichen Schlüssel hält.
Kein Passwort-Reset und kein Credential Stuffing, denn es gibt keine wiederverwendbaren Anmeldedaten zum Angreifen.

Du gibst dem Server nie eine Identität preis. Du beweist kryptografisch, dass du den privaten Schlüssel hinter einem bestimmten öffentlichen Schlüssel besitzt, und dieser Beweis genügt als Autorisierung.

Wie der Server eine Anfrage autorisiert

Ohne Sitzungen oder Login-Tokens trägt jede Anfrage ihren eigenen Beweis. Der Client baut eine Nutzlast, signiert sie mit dem privaten Schlüssel und sendet beides. Auf dem Server reduziert sich die Autorisierung auf eine einzige Signaturprüfung, ohne Sitzungssuche und ohne Abfrage eines Anmeldedatenspeichers:

const isValid = await verifyPayload(
  request.userId,   // the public key = the claimed identity
  request.payload,  // exactly what was signed
  request.signature,
);

if (!isValid) {
  return jsonResponse({ message: "invalid signature" }, 401);
}

Eine gültige Signatur macht die Anfrage in einem Vorgang authentisch und autorisiert. Ein Angreifer kann keine Anfrage für eine ID fälschen, deren privaten Schlüssel er nicht besitzt, weil er keine passende Signatur erzeugen kann. Der Besitz des privaten Schlüssels ist die Befugnis.

Der Master-Schlüssel: Geräte ohne Geheimnisweitergabe verbinden

Ein Modell, in dem ein Gerät den einzigen Schlüssel hält, scheitert, sobald jemand ein zweites Gerät hinzufügt. Hält dein Telefon den alleinigen Schlüssel zu deiner Identität, ist dein Laptop dem System fremd.

Der Master-Schlüssel löst das. Das erste Gerät wird zum Master und hält das ursprüngliche Geheimnis, aus dem deine ID abgeleitet ist. Jedes weitere Gerät erzeugt ein eigenes, separates Schlüsselpaar. Ein neues Gerät kann nicht in deinem Namen signieren, und der Master-Schlüssel wird nie zwischen Geräten kopiert. Die Verknüpfung läuft per Delegation: Der Master signiert ein kurzes Zertifikat, das den öffentlichen Schlüssel des neuen Geräts an deine ID bindet.

// Only the master can authorize a new device.
const authorization = {
  action: "device-authorization",
  userId: identity.userId,
  devicePublicKey: newDevice.devicePublicKey, // the new device's PUBLIC key
  role: newDevice.role,
  createdAt: Date.now(),
};
const signature = await signPayload(identity.privateKey, authorization);

Danach signiert das neue Gerät seine Anfragen mit dem eigenen Schlüssel, und der Server prüft sie gegen den Schlüssel, für den der Master gebürgt hat. Der Master stellt einen Berechtigungsnachweis aus, ohne sein Geheimnis je offenzulegen, genauso wie eine Zertifizierungsstelle für eine Website bürgt, deren privaten Schlüssel sie nicht besitzt.

So erhältst du das volle Vokabular eines produktiven Berechtigungssystems: Rollen, Delegation, Widerruf und geringste Rechte, alles über Signaturen ausgedrückt. Der Master kann jedes verbundene Gerät umbenennen oder widerrufen, und ein widerrufenes Gerät scheitert an seiner nächsten Signaturprüfung, während seine aktive Verbindung geschlossen wird.

Was ein kontoloser Server speichert

Sieh dir an, was die Datenbank tatsächlich enthält. Jedes Konto hält einen vom Nutzer gewählten Anzeigenamen, optional ein Avatar und eine Liste öffentlicher Geräteschlüssel. Sonst nichts. Es gibt keine E-Mails, Telefonnummern, Passwort-Hashes oder Sicherheitsfragen und keine privaten Schlüssel, die die Geräte des Nutzers nie verlassen.

Betrachte das klassische Leak-Szenario, in dem die gesamte Datenbank abfließt. Der Angreifer erhält eine Menge öffentlicher Schlüssel, die per Design öffentlich und ohne die passenden privaten Schlüssel nutzlos sind, dazu ein paar selbst gewählte Anzeigenamen. Er kann niemanden imitieren, weil Imitation einen privaten Schlüssel erfordert, den der Server nie gespeichert hat. Er kann Nutzer nicht mit einem Passwort-Dump abgleichen, weil keine Passwörter existieren. Er kann niemanden über „deine E-Mail" phishen, weil nie eine erfasst wurde.

Ein System kann keine Daten leaken, die es nie hält. Der zuverlässigste Weg, persönliche Informationen zu schützen, ist, sie nicht zu erheben, und ein Identitätsmodell, in dem die ID ein öffentlicher Schlüssel ist, macht das wörtlich wahr.

Warum passwortlose Autorisierung das Leak-Risiko senkt

Vergleiche die Angriffsflächen direkt. Eine klassische App mit E-Mail und Passwort muss eine Anmeldedatenbank, Passwort-Reset-Abläufe, E-Mail- und SMS-Codes, Sitzungs-Tokens und einen Bestand regulierter persönlicher Daten verteidigen, für den sie nun verantwortlich ist. Jeder Punkt ist eine wiederkehrende Quelle von Kontoübernahmen und Datenlecks.

Das Public-Key-Modell verteidigt eine Sache: dass der Nutzer seinen Schlüssel behält. Das ist ein echter Kompromiss, denn keine zentrale Instanz kann einen verlorenen Schlüssel zurücksetzen. Dafür verschwindet jeder Punkt der vorigen Liste. Der Schaden einer Serverkompromittierung schrumpft darauf, dass ein Angreifer öffentliche Schlüssel und Anzeigenamen liest, also Informationen, die nie sensibel waren.

Public-Key-Autorisierung in deiner eigenen App nutzen

Das Muster lässt sich weit über eine Anruf-App hinaus verallgemeinern:

Mach die Identität zu einem Schlüsselpaar und die Nutzer-ID zum öffentlichen Schlüssel. Erzeuge ihn auf dem Client, übertrage die private Hälfte nie und lass das Konto entstehen, sobald der Server eine gültige Signatur sieht.
Autorisiere durch das Prüfen von Signaturen statt durch das Prüfen von Sitzungen. Jede Aktion trägt eine Nutzlast und eine Signatur. Signiere über kanonische Bytes, damit Client und Server sich einig sind, was signiert wurde.
Nutze einen Master-Schlüssel zum Delegieren, nicht zum Teilen. Wenn eine Instanz Vertrauen auf ein zweites Gerät, ein Teammitglied oder einen API-Client ausdehnen muss, lass den Wurzelschlüssel ein begrenztes, widerrufbares Zertifikat für einen neuen Schlüssel signieren. Das Wurzelgeheimnis bewegt sich nie.
Speichere nur öffentliches Material, damit die Antwort auf „was passiert bei einem Leak" unspektakulär bleibt.

Einige Einschränkungen verdienen vor dem Launch Aufmerksamkeit. Die Schlüsselverwahrung wird zum zentralen Problem, daher ergänzen produktive Systeme Wiederherstellungsoptionen wie Social Recovery, ein optionales verschlüsseltes Backup oder einen Hardware-Schlüssel. Signierte Anfragen brauchen einen Zeitstempel oder eine Nonce gegen Replay. Da es keine Identität gibt, verlagert sich der Spam-Schutz auf Ratenbegrenzung oder Einladungen statt auf E-Mail-Verifizierung. Nichts davon untergräbt das Modell. Es sind die gewöhnlichen Anliegen jedes Systems, nur ohne die Passwortdatenbank in der Mitte.

Häufige Fragen

Wie kann eine App einen Nutzer ohne Authentifizierung autorisieren? Sie behandelt den Besitz eines privaten Schlüssels als Befugnis. Der öffentliche Schlüssel dient als Nutzer-ID, jede Aktion wird mit dem passenden privaten Schlüssel signiert, und der Server prüft diese Signatur gegen den öffentlichen Schlüssel. Der Nutzer beweist, dass er handeln darf, ohne einem zentralen Kontosystem seine Identität zu beweisen.

Ist ein kontoloses Modell weniger sicher als E-Mail und Passwort? In den meisten Punkten ist es sicherer. Es gibt keine Passwortdatenbank zum Leaken, keinen Reset-Ablauf zum Missbrauchen und keine persönlichen Daten zum Verlieren. Der Kompromiss ist die Schlüsselverwahrung: Verliert ein Nutzer seinen Schlüssel ohne Backup, kann keine zentrale Instanz das Konto wiederherstellen.

Was ist der Unterschied zwischen Authentifizierung und Autorisierung? Authentifizierung stellt fest, wer du bist. Autorisierung stellt fest, was du tun darfst. Die meisten Systeme verbinden beides, doch ein Schlüsselpaar erlaubt das Zweite ohne das Erste.

Was passiert, wenn JustCalls Server kompromittiert werden? Ein Angreifer fände öffentliche Schlüssel und Anzeigenamen. Öffentliche Schlüssel sollen öffentlich sein und sind ohne die privaten Schlüssel nutzlos, die deine Geräte nie verlassen. Es gibt keine Passwörter, E-Mails oder Telefonnummern zu stehlen.

Kann ich ohne Konto mehrere Geräte nutzen? Ja. Das erste Gerät dient als Master und signiert ein Zertifikat, das den öffentlichen Schlüssel jedes neuen Geräts an deine ID bindet. Das Master-Geheimnis wird nie kopiert, und der Master kann jedes Gerät jederzeit widerrufen.