Zusammenfassung

  • Revision 04 von OAuth for First-Party Applications definiert einen HTTPS-Endpunkt, der einen Code ausgibt, weitere Nutzereingaben über die App anfordert oder den Browser erzwingt. Ohne Redirect werden installiertes Binary, Publisher-Beleg, Oberfläche und Befolgung des Fallbacks Teil der Vertrauensentscheidung.
  • auth_session, PKCE und DPoP können Kontinuität an Instanz und Schlüssel binden. Sie beweisen weder echte First-Partyness noch den angezeigten Challenge, identische Hinweise in Schwester-Apps, rechtzeitigen Browserwechsel oder den externen Erfolg.

Der Einmalcode wurde in der Bank-App eingegeben, an den Server gesendet und ein authorization code kam über den Back Channel zurück. Kein Browser öffnete sich. Die Reibung sank; die Darstellungsautorität wechselte.

OAuth 2.0 for First-Party Applications revision 04 führt den Authorization Challenge Endpoint ein. Der Client kann login hints, signierte Passkey-Challenges oder MFA-Codes liefern. Der Server gibt einen Code aus, antwortet mit insufficient_authorization für einen weiteren Schritt oder mit redirect_to_web, um die Interaktion im Browser zu übernehmen.

Revision 04 ist ein aktiver OAuth-WG Internet-Draft vom 1. Juli 2026, läuft am 2. Januar 2027 ab und zielt auf Standards Track. Sie ist kein RFC. IANA-Abschluss, Implementierung, Interoperabilität, Deployment, Attestation-Abdeckung, weniger Phishing oder Geschäftserfolg sind nicht belegt.

Die native API verlagert die Oberfläche

Im üblichen Code Flow kontrolliert der Authorization Server die Seite für Credentials. Hier führt ein hoch vertrauter Client einen Teil der Zeremonie aus. Er sendet OAuth-Parameter und gesammelte Daten. Web-spezifische Extensions können nativ bedeutungslos sein; ihre Behandlung bleibt offen.

Der Server entscheidet über die Code-Ausgabe. Die App kann Prompt, Eingabekomponente, Fehlertext und proprietäre Zwischenendpunkte prägen. Formate, Challenge-Schemas und Reihenfolge sind nicht standardisiert; ein Deployment braucht Profile für Interoperabilität.

Der Beleg sollte Build, installierte Instanz, Profil, Eingabeklasse ohne Geheimwert, Scopes, Policy-Version, Antwort und Folgeschritt enthalten. Ein gültiger Code beweist die Ausgabe des Grant-Artefakts, nicht den Bildschirm davor.

First-party ist eine Beziehung

Der AS muss die “first-partyness” vor Fortsetzung prüfen: App und Server stehen unter derselben Entity, und Nutzer verstehen sie als zusammengehörig. Wie das bewiesen wird, schreibt der Entwurf nicht vor.

Plattform-Attestation, Attestation-Based Client Authentication und Dynamic Client Registration liefern Teilbelege. Sie verschmelzen Unternehmenskontrolle, Distribution, Binary-Integrität, Schlüsselbesitz und Markenwahrnehmung nicht.

Ein signiertes Package kann alt oder kompromittiert sein. Eine echte App kann täuschen. Ein DPoP-Key kann ohne passendes Enrollment zu einer kopierten Instanz gehören. Eine vertraute Oberfläche kann imitiert werden.

Publisher, Distributor, Attester, Freshness, Nonce, Policy und Instanz gehören getrennt von client_id, auth_session und Code in den Receipt. “First-party verifiziert” ist eine Schlussfolgerung.

auth_session ist von der App getragener Kontext

auth_session verbindet Anfragen derselben Instanz wie ein Cookie. Der Client speichert und präsentiert den opaque value, übernimmt Rotation, behält ihn nach Code-Ausgabe und löscht ihn beim Logout.

Der Wert muss einzigartig sein; zufällige Werte sollten 256 Bit Entropie haben. Device Binding wird empfohlen. Es gibt keine feste Lifetime: Zeit, Risiko oder Revocation können ihn ungültig machen.

Das Audit braucht Generation, Vorgänger, Instanz, Kontext, DPoP-Key, Stage, Rotation, Logout und Endzustand, nicht den Wert selbst. Eine akzeptierte Session belegt Kontextfortsetzung, nicht ehrliche frühere Prompts oder denselben Menschen.

DPoP bindet den Schlüssel, nicht den Screen

DPoP kann Challenge, Code, Token, Resource und auth_session an denselben Public Key binden und Private-Key Possession bei Fortsetzung prüfen. Das begrenzt Replay gestohlener Werte.

Key Continuity ist keine App-Provenienz. Sie sagt nicht, wer Enrollment erlaubte, welches Package rendert, ob die Instanz sauber bleibt, ob die Policy sie noch akzeptiert oder ob der Nutzer den Scope wollte. DPoP, Attestation, Registration, First-Party-Policy, Prompt-Profil und User Authorization bleiben eigene Zustände.

redirect_to_web ist ein Sicherheitsübergang

High Risk, fehlende Methode, Recovery oder Exception können redirect_to_web auslösen. Der Client startet einen neuen Code Flow im External User Agent, eventuell mit PAR request_uri.

Ohne initiale PKCE code_challenge darf der Server kein request_uri zurückgeben. Der Web-Pfad muss Native-App-Regeln, Security BCP und Issuer Identification erhalten.

Receipt-Felder sind Trigger, Risk Band, PKCE, Issuer, Referenz, Browser, Return URI, State und Callback. Browserstart beweist kein richtiges Ziel; native Fortsetzung kein geringes Risiko. Ignorieren oder Embedded Webview überschreiten die Policy.

Mehrere Apps vervielfachen Vertrauen

Der Entwurf verlangt identische native Experience für mehrere First-Party-Apps. Mehr legitime Credential-Flächen trainieren Nutzer auf mehr Formen. Jede Implementierung bringt Parser, Storage, Accessibility, SDK und Fehler.

Ein gemeinsames SDK reduziert Drift und konzentriert Abhängigkeit. Version, Signatur, Rollout und Notfallrücknahme sind Controls. Gleichheit umfasst Texte, Herkunftshinweise, Secret Handling, Screenshots, Accessibility, Fallback, Fehler, Session Storage und Redaction.

Der AS muss Clients auf Entity, Publisher, Channel, Builds, SDK, Profil und Retirement abbilden. Eine schwache Schwester-App erbt nicht automatisch Vertrauen.

Der Code ist nicht das Ergebnis

Code, PKCE, DPoP, auth_session, Step-up und Access Token haben verschiedene Aussagen. Keine beweist Resource-Entscheidung oder nachgelagerte Wirkung. Ein Transfer kann scheitern, eine Zahlung rückgängig werden, ein Credential uninstalliert bleiben. Outcome-Evidence folgt nach OAuth.