OIDC und OAuth

Discovery-, Autorisierungs-, Token-, Logout- und OAuth-Erweiterungsendpunkte.OAuth-Erweiterungsendpunkte.

Kernendpunkte

Endpunkt	Beschreibung
`/.well-known/openid-configuration`	OIDC-Discovery für den aktuellen Aussteller.
`/.well-known/oauth-protected-resource`	OAuth Protected Resource Metadata für von XID gehostete Ressourcenendpunkte.
`/jwks`	Öffentliche Signaturschlüssel der Instanz mit aktiven und rotierenden Schlüsselkennungen.
`/authorize`	Autorisierungsendpunkt mit PKCE, State, Nonce, PAR und Übergabe an Hosted Auth.
`/par`	Pushed Authorization Requests mit einmaligen request_uri-Werten.
`/token`	Autorisierungscode, Refresh-Token, Client-Zugangsdaten, Gerätecode und Tokenaustausch.
`/userinfo`	Benutzeransprüche aus Bearer- oder DPoP-Access-Token.
`/end_session`	RP-initiierter Logout mit registrierten Post-Logout-Weiterleitungen.

PKCE verwendet S256. PKCE ohne Transformation wird abgelehnt.
Der Abgleich der Weiterleitungs-URI ist exakt. Platzhalter werden nicht akzeptiert.
Autorisierungscodes können nur einmal verwendet werden.
Refresh-Token rotieren bei jeder Verwendung, und Wiederholung widerruft die Token-Familie.
DPoP-gebundene Clients muessen fuer Token- und Ressourcenaufrufe einen gueltigen DPoP Proof vorlegen. Die Authorization Request dpop_jkt ist an den Authorization Code Exchange gebunden.

Stufe	OAuth- und OIDC-Funktionen
Implementiert	Authorization Code, PKCE S256, Refresh-Rotation, PAR, DPoP-Nachweis und `dpop_jkt`-Bindung, dynamische Client-Registrierung, ID-Tokens, Userinfo, Hybrid-Response-Typen, signierte JAR-Request-Objekte, signierte JARM-Responses, RAR`resource_access`-Autorisierungsdetails, Token-Exchange-Refresh und ID-Token-Ausstellung, mTLS-Client-Authentifizierung und Front-Channel-Logout.
Provider-ready	Device-Authorization-Polling, Session-Management-check_session, CIBA-Backchannel-Freigabe, FAPI-2.0-/Browser-Based-Apps-Profil-Gates, OpenID Federation und Shared Signals stellen geschützte minimale oder provider-ready Teilmengen bereit. GNAP, UMA, HEART, OpenID4VP und OpenID4VCI liefern bis zum Ausrollen vollständiger Profile negative oder 501-Stubs.
Geplant	Downstream-SaaS-OIDC nutzt lokal die aktuelle generische OIDC-Baseline, aber SaaS-spezifischer Produktionssupport erfordert weiterhin echtes SaaS L4.
Veraltet oder nicht unterstützt	Implicit Flow, Password Grant, Plain-PKCE und Wildcard-Redirects.

Rolle von XID	Aktueller öffentlicher Status
OIDC-/OAuth-Identitätsanbieter für Kundenanwendungen	In lokalen und Worker-Routen mit Abdeckung für Authorization Code, PKCE S256, PAR, DPoP, JAR, JARM, RAR, discovery, JWKS, token, userinfo, introspection und revocation implementiert.
Vorgelagerte Enterprise-OIDC-Relying-Party	Provider-ready für Enterprise-Verbindungen. Produktionsunterstützung erfordert eine echte IdP-Konfiguration und einen Callback-L4.
Social-OAuth-Relying-Party	Provider-ready für GitHub, Google, Microsoft-Konten und Apple. Anbieterbezogene Grenzen finden Sie unter Social-Anmeldung.
OIDC-Identitätsanbieter für nachgelagerte SaaS-Dienste	Eine generische OIDC-Basis ist lokal verfügbar. SaaS-spezifische Anwendungsvorlagen und ein echter SaaS-L4 sind weiterhin erforderlich, bevor Produktionsunterstützung zugesichert werden kann.

Client	Empfohlener Ablauf
Webanwendung	Autorisierungscode mit serverseitigem Tokenaustausch.
SPA	Autorisierungscode mit PKCE S256.
Native Anwendung	Autorisierungscode mit PKCE S256 und registrierten Weiterleitungen.
Maschine zu Maschine	Client-Zugangsdaten mit begrenztem Zugriff.

Stufe	Zustand
Assertion Grant Flows	JWT bearer und SAML bearer Assertion Grants sind nicht aktiviert. Registrierung weist Assertion Grant Metadaten ab, bis eine Trust Root existiert.
GNAP, UMA, HEART, OpenID4VP, OpenID4VCI	Minimale Routen-Teilmengen und discovery-freundliche Metadaten werden bereitgestellt. Nicht unterstützte Operationen liefern explizite Fehler, bis vollständige Profil-Handler verfügbar sind.