Zusammenfassung

  • RFC9470 erlaubt Anforderungen an Stärke und Aktualität des mit dem Zugriffstoken verbundenen Authentifizierungsereignisses. Die Token-Ausgabe hat eine andere Uhr; Erneuerungen aus derselben Autorisierungsantwort behalten die Ereignisinformationen bei.
  • Die Ressource braucht tatsächliche Evidenz über den gewählten Prüfweg. Die Erweiterung empfiehlt, den verlangten Authentifizierungskontext zu erfüllen oder ausdrücklich zu scheitern, statt immer wieder unzureichende Token zurückzugeben.
  • Token-Gültigkeit, Ereignisalter und Kontext, Berechtigungsumfang und abgeschlossene Operation sind verschiedene Aussagen. Ihr gemeinsamer Vertrag macht OAuth nicht zum Authentifizierungsprotokoll und verlangt keine zentrale Zusatzgenehmigung für jede Operation.

Die gut zählbare Ausgabe beantwortet die falsche Frage

Ein Betriebsbericht könnte fortlaufend erfolgreiche Token-Erneuerungen verzeichnen. Der geschützte Dienst verlangt jedoch eine kürzlich erfolgte aktive Nutzerauthentifizierung. Seine neuen Token stammen aus einer früheren gemeinsamen Autorisierungsantwort, ohne neues Nutzerereignis. Der Bericht muss nicht falsch sein: Er zählt Ausgaben. Er belegt nur nicht die Bedingung, die die Ressource tatsächlich beurteilen will.

Dieses Szenario ist hypothetisch und kein in der Recherche gefundener Produktfehler. Es trennt zwei Uhren, bevor beide als aktuell gelten. Ein neues Zugriffstoken kann mit einem älteren Authentifizierungsereignis verbunden bleiben. Umgekehrt kann ein vorhandenes Ereignis die geltende Bedingung bereits erfüllen; daraus entsteht keine Pflicht, den Nutzer bei jeder Operation erneut interagieren zu lassen. Die konkrete Richtlinie und ihre Nachweise sind maßgeblich, nicht eine universelle Forderung nach weiteren Anmeldefenstern.

RFC9470, veröffentlicht im September 2023, beschreibt das OAuth-Verfahren für eine Aufforderung zu zusätzlicher Authentifizierung. Eine Ressource kann mitteilen, dass Stärke oder zeitliche Nähe des verbundenen Ereignisses nicht reichen. Die Spezifikation definiert die Authentifizierung selbst nicht. Sie setzt eine eigene Authentifizierungsschicht voraus und verbietet ausdrücklich, OAuth mit diesem Dokument als Authentifizierungsprotokoll darzustellen.

Die Grenze betrifft auch die Sprache eines Betriebsversprechens. Eine weitere Autorisierungsanfrage ist nicht automatisch eine neue Nutzerauthentifizierung. Ein zurückgegebenes Token belegt nicht automatisch den verlangten Kontext. Und eine erfüllte Authentifizierungsbedingung weist weder einen ausreichenden Berechtigungsumfang noch eine abgeschlossene Operation nach. Jede Erfolgsmeldung muss ihren Gegenstand nennen.

Das JWT-Feld iat zeigt den Umfang einer Uhr. RFC7519 definiert den Ausgabezeitpunkt des JWT, anhand dessen sein Alter bestimmt werden kann. Der Zeitpunkt der letzten aktiven Nutzerauthentifizierung ist damit nicht angegeben. Die allgemeine Optionalität hebt keine Anforderungen eines konkreten Profils auf. Auch ein korrekt geprüfter Ausgabezeitpunkt kann einen fehlenden Authentifizierungszeitpunkt nicht durch Schlussfolgerung ersetzen.

RFC9068 lässt Authentifizierungsinformationen wie auth_time, acr und amr in den betreffenden Autorisierungen zu. Ihre Werte bleiben über Token hinweg fest, die aus derselben Autorisierungsantwort hervorgehen, einschließlich Erneuerungen und Austausch. RFC9470 macht den Unterschied für auth_time und acr deutlich. Dabei muss die gemeinsame Herkunft als Bedingung erhalten bleiben. Eine tatsächlich neue Nutzerauthentifizierung liefert andere Evidenz; nicht jeder denkbare Erneuerungsablauf wird hier von Authentifizierung ausgeschlossen.

Der Dienstvertrag muss deshalb die Ereignisherkunft erklären, nicht nur die letzte Token-Ausgabe. Automatisierte Erneuerung kann Verfügbarkeit sichern und andere Schutzmaßnahmen ergänzen. Sie bekommt dadurch keine Befugnis, ein nicht wiederholtes Ereignis zeitlich zu verjüngen. Es geht nicht darum, Erneuerung abzulehnen, sondern ihren Erfolg auf die Aussage zu beschränken, die sie wirklich belegt.

Die Ressource verlangt eine Eigenschaft des Ereignisses

insufficient_user_authentication bezeichnet eine nicht erfüllte Authentifizierungsanforderung. Das ist nicht stets dieselbe Diagnose wie Token-Ablauf oder fehlender Berechtigungsumfang. Die Aufforderung kann acr_values als bevorzugt geordnete Liste akzeptabler Kontextklassen und max_age als erlaubte Zeit seit aktiver Authentifizierung enthalten. Beide können gemeinsam auftreten. Fehlt auch scope, kann die Ressource ihn nach den referenzierten Bearer-Regeln angeben.

Der Klassenname führt keine Authentifizierungsmethode aus. OpenID Connect Core verlangt eine Vereinbarung über die Bedeutung der Werte, die vom Kontext abhängen kann. Ein standardisiertes Feld macht die Zusage eines Anbieters nicht zur universellen Aussage über ein bestimmtes Verfahren oder Sicherheitsniveau. Die Ressource muss wissen, was sie akzeptiert, und der Autorisierungsserver, welches Ereignis diese Bedeutung erfüllen kann.

max_age drückt eine nichtnegative ganze Zahl von Sekunden seit dem aktiven Ereignis aus, nicht seit der jüngsten Ausgabe. Nur das zuletzt ausgegebene Token zu betrachten, weist dieses Intervall nicht nach. Das ist keine Diagnose einer Schwachstelle im Betrieb, sondern die Benennung der Evidenz, die vor dem Versprechen einer hinreichend aktuellen Authentifizierung nötig wäre.

Der Client sollte vorhandene Parameter beim Aufbau der Autorisierungsanfrage übernehmen. Präziser Transport erleichtert Koordination, beweist aber keine Erfüllung. Weiterleitung, Navigation und Token-Rückgabe sind verschiedene Vorgänge. Die Ressource muss die zurückgegebenen Authentifizierungsinformationen noch beurteilen, statt aus einem reibungslosen Ablauf sämtliche Ergebnisse abzuleiten.

Die angeforderte Eigenschaft braucht ein Ergebnis

OpenID Connect Core behandelt acr_values allgemein als Anfrage nach einem freiwilligen Claim. Die Regeln für den Kontext im ID Token garantieren deshalb nicht bedingungslos jedes gewünschte Niveau. max_age verlangt einen Versuch aktiver erneuter Authentifizierung, wenn die erlaubte Zeit überschritten ist, und auth_time im zurückgegebenen ID Token. Diese Regeln eines Identitätstokens belegen nicht den Inhalt jedes beliebigen Zugriffstokens.

RFC9470 beschreibt die Zugriffstoken von Servern, die seiner Erweiterung folgen, einschließlich acr und auth_time als Antwort auf die jeweiligen Parameter. Vor allem empfiehlt es, den verlangten acr als notwendig für eine erfolgreiche Erfüllung anzusehen: die Bedingung erreichen oder mit unmet_authentication_requirements scheitern. Ein weiteres Token, das den Ressourcenanforderungen nicht genügt, würde den Client nur im Kreislauf halten.

Beide Übertreibungen sind zu vermeiden. Eine jederzeit ignorierbare Präferenz zu behaupten, schwächt das empfohlene Zugriffstoken-Verhalten. Eine Erfolgsgarantie aus jeder Aufforderung abzuleiten, erfindet dagegen eine größere Zusage. Ein ausdrücklicher Fehlschlag kann die richtige Antwort auf ein nicht erreichtes Niveau sein. Die OpenID-Erweiterung benennt diesen Zustand; sie schafft keine neue Berechtigung und weist keine ausgeführte Operation nach.

Wiederholte Ablehnung könnte in einem hypothetischen Dienstpaar aus einer unerreichbaren Klasse, unzureichender Altersevidenz oder unvereinbaren Bedingungen entstehen. Keine dieser Situationen wurde hier bei einem Produkt beobachtet. Sie zeigen, warum die jüngste Token-Ausgabe den Konflikt nicht lokalisieren kann. Das Paar braucht eine Erklärung erreichbarer Bedingungen und abschließender Ergebnisse, nicht nur die Aussicht auf einen weiteren Versuch.

Klare Fehlerbehandlung ist daher eine Verantwortungsfrage. Eine Ausgabe kann im Autorisierungsdienst erfolgreich aussehen und für die Ressource trotzdem unbrauchbar bleiben. Getrennte Erfolge als denselben Fortschritt zu zählen, versteckt die nicht erfüllte Bedingung. Besseres Nutzererlebnis sollte nicht heißen, ein präzises negatives Ergebnis durch immer neue lokale Erfolgsmeldungen zu ersetzen.

Der Prüfweg ist Teil des Vertrags

RFC9470 verbindet Ereignisinformationen mit zwei gängigen Methoden: JWT-Zugriffstoken unter den anwendbaren Validierungsregeln und OAuth-Token-Introspektion. Andere Kodierungen und Prüfverfahren sind möglich, aber außerhalb dieses Dokuments. Der Bedarf an Authentifizierungsevidenz erzwingt keine identische Betriebsarchitektur für alle Anwender.

Bei JWT ersetzt das Lesen von auth_time und acr nicht die Token-Prüfung. Aussteller, vorgesehener Empfänger und weitere Profilbedingungen zählen weiterhin; anschließend ist die Ereignisinformation zu interpretieren. Ein Wert aus nicht vertrauenswürdiger Eingabe wird durch einen bekannten Feldnamen allein nicht zum Nachweis. Diese Aussage ist konzeptionell, keine Sicherheitsprüfung einer konkreten Implementierung.

Bei Introspektion bezeichnet active:true einen Token-Zustand, nicht die Erfüllung aller Richtlinien. Ein Ereignis kann zu alt oder sein Kontext nicht akzeptabel sein. RFC7662 liefert Zustand und Metadaten, RFC9470 ergänzt Antwortfelder zur Authentifizierung. Sie verlangen eine eigene Bewertung neben dem Aktivitätsindikator.

Daraus folgt keine universelle Pflicht zur Online-Abfrage einer Zentralinstanz für jede Operation. JWT wiederum macht eine Offline-Prüfung nicht überall ausreichend. Ein Betrieb wählt einen zu seinen Verantwortlichkeiten und weiteren Bedingungen passenden Weg. Der gemeinsame Vertrag kann Informationen beschreiben, ohne allen Ressourcen einen einzigen Betriebsmodus vorzuschreiben.

Autorisierungsserver-Metadaten geben ein anderes Signal. acr_values_supported kündigt unter RFC9470 Verständnis und Beachtung der einschlägigen Parameter an. Das beschreibt eine Fähigkeit, nicht die Aufzeichnung eines bestimmten gelungenen Nutzerereignisses, dessen tatsächliches Alter oder das Ergebnis der Ressource. Ein Fähigkeitskatalog wird nicht zum Ereignisnachweis, weil er vom selben Anbieter stammt.

Ein erfülltes Kriterium schafft keinen größeren Umfang

Die OAuth-Erneuerungsregeln verbieten angefragten scope außerhalb der ursprünglichen Gewährung; bei Auslassung bleibt dieser Umfang erhalten. Client-Authentifizierung am Token-Endpunkt ist auch nicht die kürzliche Authentifizierung des Endnutzers. Eine automatisierte Transaktion weist weder neue Nutzerinteraktion noch eine Ausweitung von dessen Befugnissen nach.

Eine Ressource kann Authentifizierungsqualität als Zugriffsbedingung verwenden, ohne sie zur gesamten Entscheidung zu erklären. Gültigkeit, Empfänger, Umfang, Kontext und zeitliche Nähe können getrennt zählen. Ein erfülltes Kriterium erzeugt die anderen nicht. Selbst eine korrekte Zugriffsentscheidung belegt keine vollständig ausgeführte Operation. Eine Erfolgsaussage muss ihren Nachweisgegenstand nennen.

RFC9470 lässt Beschränkungen der Richtlinien des Ressource/Autorisierungsserver-Paares außerhalb seines Umfangs. Ein Betrieb kann Bedingungen setzen, die Nutzer nicht erfüllen können oder die unerwünschte Erfahrungen auslösen. Die tatsächlichen Mittel, etwa benötigte Geräte, stehen nicht einfach im Klassennamen. Eine präzise übermittelte Bedingung macht nicht jede Kombination für jeden Menschen machbar.

Die Aufforderung beweist nicht einmal eine vorher abgeschlossene Prüfung des Eingabetokens. Die Spezifikation erlaubt ihre Logik vor oder nach der gewöhnlichen Validierung und eine Antwort ohne vorherige Prüfung eines gültigen Tokens. Sie benennt dann die Offenlegung verlangter Eigenschaften gegenüber einem nicht ausgewiesenen Akteur. Reihenfolge ist eine Wahl mit Folgen, keine von diesem Artikel erfundene allgemeine Vorschrift.

Kontextwerte können Hinweise auf privilegierte Nutzer oder weitere Zielinformationen verraten. Ein Mechanismus, der Nutzerinteraktion auslöst, kann auch von einer bösartigen Ressource missbraucht werden. Hier wurde kein Angriff oder Betroffener beobachtet. Die Quellen erklären Möglichkeiten und verlangen Vorsicht, ohne ihre Häufigkeit in aktuellen Diensten zu messen.

RFC9700 bietet den aktualisierten OAuth-Sicherheitskontext, keinen neuen Authentifizierungszeitpunkt. Refresh-Token-Rotation und bessere Absicherung von Zugangsmerkmalen betreffen eigene Fragen. Sie weisen nicht automatisch ein neues Nutzerereignis nach. Sinnvolle Kontrollen können sich ergänzen, ohne gegenseitig als Evidenz sämtlicher anderer Bedingungen aufzutreten.

Lu Hengs minimale Anfangsspezifikation, lokalisierte Zukunftsentscheidungen und freiwillige Übernahme helfen als redaktioneller Bezug. Die gemeinsame Basis macht Aufforderung und Ereignis verständlich. Das passende Dienstpaar erklärt Richtlinien und erfüllbare Bedingungen; Anwender wählen auf dieser Grundlage. Eine zusätzliche Stelle für jedes einzelne Ja ist nicht nötig, sichtbare lokale Verantwortung aber schon.

Ein neues Token kann Teil einer begründeten Entscheidung sein. Es ersetzt weder ein neues Authentifizierungsereignis noch die erfüllte Bedingung oder die vollendete Handlung. Der Vorteil des gemeinsamen Vertrags liegt im Koordinieren, nicht im Aufheben dieser Unterschiede. So erhält die Ausgabeuhr keine Befugnis, die das Erzeugen einer Zugangskennung nicht liefert.

Quellen