Zusammenfassung

  • Eine Ressource kann erst beim konkreten Aufruf erkennen, welche Authentifizierung sie benötigt. Eine standardisierte Forderung garantiert jedoch keinen erfüllbaren Ablauf.
  • Ein neues Zugriffstoken bedeutet nicht zwangsläufig ein neues Authentifizierungsereignis. Bleibt die entscheidende Bedingung unverändert, kann die nächste Runde zur gleichen Ablehnung führen.
  • Die Befugnis, Nutzer erneut zu beschäftigen, braucht Grenzen: verfügbare Mittel, einen geordneten Abbruch, angemessene Offenlegung und eine Zuordnung des ausgelagerten Aufwands.

Eine Sicherheitsregel mit fremdem Kostenkonto

Für den Verantwortlichen einer API kann eine zusätzliche Anforderung wie eine kleine Änderung aussehen. Bestimmte Aufrufe werden abgewiesen, bis eine passende Authentifizierung vorliegt. Den nächsten Schritt erledigen andere: der Identitätsdienst, die Anwendung, der Support und der Mensch, dessen Arbeit unterbrochen wurde.

Man stelle sich einen Nutzer vor, der das benötigte Gerät nicht bei sich hat. Die API kann ihre Regel korrekt anwenden, und der Identitätsdienst kann korrekt feststellen, dass er die Forderung derzeit nicht erfüllen kann. Das System ist dadurch noch nicht in der Lage, einen sinnvollen nächsten Schritt anzubieten. Dieses Beispiel ist ein Gedankenexperiment, kein Bericht über eine konkrete Einführung.

Der zusätzliche Schutz kann notwendig sein. Ein Dienst kennt mitunter erst beim Aufruf die Eigenschaften des Vorgangs, die eine andere Authentifizierung rechtfertigen. Diese Entscheidung vollständig in die frühere Tokenausgabe zu verlagern, würde wichtige Informationen ausblenden. Nicht die späte Entscheidung ist das Problem, sondern eine Entscheidung ohne Vereinbarung darüber, wie ihre Folgen bewältigt werden.

Wer Anforderungen verschärft, sollte deshalb nicht nur nachweisen, dass die Gegenstelle die Nachricht versteht. Er sollte erklären können, wie die betroffenen Nutzer sie erfüllen und wer für fehlende Voraussetzungen zuständig ist.

Verständigung ist noch keine Durchführbarkeit

Der im September 2023 veröffentlichte RFC 9470 ermöglicht eine Aufforderung, die unzureichende Nutzerauthentifizierung sowie akzeptable Kontexte oder zeitliche Anforderungen benennt. Der Client trägt sie zum Autorisierungsserver; die Ressource bewertet anschließend das Ergebnis.

Der RFC lässt ausdrücklich Raum für Richtlinienkombinationen, die Nutzer nicht erfüllen können. Er warnt außerdem vor einem Missbrauch der Möglichkeit, Nutzerinteraktion auszulösen. Diese Hinweise beschreiben Risiken, nicht die gemessene Häufigkeit entsprechender Vorfälle.

Für eine Beschaffung ergeben sich daraus zwei getrennte Prüfgegenstände. Die Unterstützung des Protokolls betrifft die Kommunikation der Komponenten. Die Erfüllbarkeit betrifft das gesamte Angebot für eine bestimmte Nutzergruppe. Geräte, Registrierung, Wiederherstellung und verfügbare Unterstützung gehören zum zweiten Gegenstand.

Eine erfolgreiche Vorführung mit einem vorbereiteten Konto beweist nicht, dass auch ein neu registrierter Nutzer oder jemand im Wiederherstellungsverfahren den Vorgang abschließen kann. Solche Fälle rechtfertigen nicht automatisch geringere Sicherheit. Sie verlangen eine vorher festgelegte Antwort, die mehr leistet als eine erneute Aufforderung.

Die Metapher vom höheren Niveau

Step-up klingt nach einer Leiter. Wer eine Stufe höher steigt, müsste danach alles können, was vorher möglich war, und zusätzlich noch mehr. Als allgemeines Modell für Authentifizierungskontexte ist das zu bequem.

Eine Ressource kann eine bestimmte Art von Nachweis benötigen; eine andere legt Wert auf ein kürzlich erfolgtes aktives Ereignis. Die Bezeichnung eines Verfahrens stellt keine universelle Rangordnung her. Zusätzliche Faktoren ersetzen nicht automatisch jede andere Voraussetzung.

OpenID Connect Core unterscheidet einen freiwillig angefragten Kontext von einer als wesentlich angeforderten Auswahl bestimmter Werte, sofern der betreffende Mechanismus unterstützt wird. Auch das zulässige Alter der Authentifizierung und Vorgaben für die Nutzerinteraktion sind getrennte Anweisungen.

Diese Unterschiede sind für die Betriebsvereinbarung entscheidend. Hält die API einen Wert für zwingend, während der Identitätsdienst eine Präferenz verarbeitet, kann dessen ordnungsgemäße Antwort für die Ressource weiterhin ungeeignet sein. Beide Seiten können ihren Teil korrekt beschreiben und dennoch aneinander vorbeiarbeiten.

Führungskräfte müssen dafür nicht jedes Feld auswendig kennen. Sie müssen aber verlangen, dass angefragte und tatsächlich erreichte Eigenschaften auseinandergehalten werden. Die Meldung einer erfolgreichen Anmeldung allein beantwortet nicht, ob der konkrete Vorgang jetzt zulässig ist.

Wenn eine ehrliche Ablehnung mehr hilft als ein neues Token

Angenommen, der gewünschte Kontext steht einem Nutzer nicht zur Verfügung. Ein weiterer Autorisierungsvorgang liefert dann möglicherweise Informationen, die an der entscheidenden Bedingung nichts ändern. Die Ressource lehnt erneut ab. Neue Nachrichten sind ausgetauscht worden; eine neue Erfolgsaussicht ist nicht entstanden.

Die OpenID-Spezifikation für unerfüllte Authentifizierungsanforderungen definiert ein Fehlersignal, unter anderem für den nicht erfüllbaren wesentlichen Kontext. RFC 9470 empfiehlt für den beschriebenen Zugriffsvorgang, den verlangten Kontext als notwendige Bedingung zu behandeln. So soll vermieden werden, dass fortlaufend bereits als unzureichend erkennbare Tokens zurückkommen.

Ein Fehlersignal legt allerdings noch keinen verständlichen Abschluss fest. Die Anwendung muss wissen, ob sie den Vorgang beendet, eine genehmigte Alternative anbietet oder an eine zuständige Stelle verweist. Der Support muss erkennen können, ob eine Registrierung fehlt, ein Gerät vorübergehend nicht verfügbar ist oder die beteiligten Richtlinien grundsätzlich nicht zusammenpassen.

Der richtige Maßstab für eine Wiederholung ist deshalb nicht allein, ob ein weiterer Versuch technisch möglich wäre. Entscheidend ist, was sich seit der Ablehnung geändert hat. Ein verfügbares Gerät oder ein relevantes neues Ereignis kann einen weiteren Versuch rechtfertigen. Ein anderer Request-Bezeichner allein tut das nicht.

Eine geordnete Beendigung ist keine Zugriffserlaubnis. Die Organisation kann die notwendige Bedingung aufrechterhalten und zugleich erklären, dass der Vorgang unter den gegenwärtigen Umständen nicht abgeschlossen werden kann. Das bewahrt die Sicherheitsgrenze, ohne den Nutzer mit einer unlösbaren Aufgabe endlos zu beschäftigen.

Neu ausgegeben heißt nicht neu authentifiziert

Tokens sind sichtbare Ergebnisse eines Ablaufs. Eine neue Ausgabe und eine erfolgreiche Antwort können daher den Eindruck erwecken, die geforderte Aktualität sei hergestellt worden. Das muss nicht zutreffen.

Das JWT-Zugriffstoken-Profil RFC 9068 trennt die Ausgabezeit von Angaben zum Authentifizierungsereignis. Angaben aus derselben Autorisierungsantwort bleiben bei den betreffenden Erneuerungs- und Austauschvorgängen erhalten. Zugleich darf der Client seine Logik nicht vom Auslesen des Zugriffstokens abhängig machen: Aussteller und Ressource können dessen Format verändern.

Für den Betrieb folgt daraus eine begrenzte, aber wichtige Forderung. Bevor man eine weitere Runde startet, sollte geklärt sein, ob sie das benötigte Ereignis überhaupt hervorbringen kann. Ein neuer Gegenstand ist kein Ersatz für eine neue Handlung des Nutzers.

Die Token-Introspektion nach RFC 7662 bietet einer berechtigten Ressource eine weitere Möglichkeit, Zustand und Metadaten abzufragen. RFC 9470 ergänzt diesen Austausch um Kontext und Zeitpunkt der Authentifizierung. Ein aktives Token erfüllt trotzdem nicht automatisch sämtliche Bedingungen einer konkreten Anfrage.

Ob die Information im Token oder über eine Abfrage ankommt, darf die vereinbarte Bedeutung nicht verändern. Die Verantwortlichen müssen festlegen, wer das Ereignis belegt, wer es bewertet und was den Vorgang tatsächlich weiterbringen kann. Improvisiertes Auslesen durch den Client löst diese Abstimmung nicht.

Die Aufforderung verrät möglicherweise mehr als beabsichtigt

Detaillierte Anforderungen erleichtern einem legitimen Client den nächsten Schritt. Gleichzeitig verlassen damit Informationen die Ressource. Treten bestimmte Forderungen nur bei ausgewählten Nutzern oder Vorgängen auf, kann ein Beobachter unter Umständen Unterschiede erkennen, die nicht öffentlich werden sollten.

Der Standard nennt diese Möglichkeit als Sicherheitsrisiko. Daraus folgt keine Behauptung über einen erfolgreichen Angriff auf einen bestimmten Anbieter. Wohl aber entsteht eine Entscheidung darüber, welche Details wem nach welchen Prüfungen zugänglich gemacht werden.

Eine Aufforderung vor der Tokenvalidierung ist im Protokoll möglich. Das macht diese Reihenfolge nicht für jedes Angebot richtig. Sie kann Anforderungen gegenüber einem Aufrufer offenlegen, der noch nicht nachgewiesen hat, dass er ein gültiges Token für die Ressource erhalten kann.

Ähnlich ist bei Diagnosedaten abzuwägen. Zur Unterscheidung eines nicht verfügbaren Kontexts von einem Übertragungsfehler müssen nicht zwangsläufig vollständige Tokens und persönliche Attribute gesammelt werden. Untersuchung, Zugriffsrechte und Aufbewahrung sollten im Verhältnis zum konkreten Zweck stehen.

Die Reparatur eines stockenden Ablaufs darf nicht unbemerkt ein zweites Problem schaffen: eine unnötig umfassende Sammlung von Identitätsinformationen.

Unterbrechungen sind kein Erfolgsmaß

Mehr Authentifizierungsaufforderungen können mit einer sinnvollen Sicherheitsänderung, einer fehlerhaften Integration oder einer unerfüllbaren Bedingung zusammenhängen. Die Zahl allein bewertet diese Ursachen nicht.

Aussagekräftiger ist, ob die beabsichtigte Aufgabe unter den vorgesehenen Bedingungen abgeschlossen wurde. Unerfüllte Anforderungen, unveränderte Wiederholungen, Abbrüche und genehmigte Wiederherstellungswege sollten getrennt sichtbar bleiben. Das sind hier vorgeschlagene Beobachtungen, keine berichteten Messergebnisse.

Weniger Aufforderungen sind ebenfalls nicht automatisch besser. Werden dafür notwendige Bedingungen entfernt, verschleiert ein flüssiger Ablauf eine Risikoentscheidung. Ziel ist weder möglichst viel Zeremonie noch möglichst wenig Reibung, sondern eine angemessene und durchführbare Anforderung mit einem verständlichen Ende.

Vor der Einführung einige legitime Grenzfälle durchzugehen, garantiert keine allgemeine Fehlerfreiheit. Es zwingt die Beteiligten aber dazu, Annahmen über Geräte, Registrierung und Erreichbarkeit offenzulegen. Genau dort beginnt die Betriebsverantwortung, die ein kompatibles Protokoll nicht übernehmen kann.