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. |
Protokollanforderungen
- 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_jktist an den Authorization Code Exchange gebunden.
Supportstufen
| Stufe | OAuth- und OIDC-Funktionen |
|---|---|
| Implementiert | Autorisierungscode, PKCE S256, Aktualisierungsrotation, PAR, DPoP-Proof und dpop_jkt-Bindung, dynamische Client-Registrierung, ID-Tokens, Benutzerinformationen, Hybrid-Antworttypen, signierte JAR-Anforderungsobjekte, signierte JARM-Antworten, RAR-resource_access-Autorisierungsdetails, Token-Austausch, mTLS-Client-Authentifizierung, Front-Channel- und Back-Channel-Abmeldung, Gerätefluss, Sitzungsverwaltung, CIBA, Profil-Gates für browserbasierte Apps und FAPI 2.0-Profiltore. |
| Minimale Implementierung | OpenID Federation stellt nur Entitätsmetadaten und eine Registrierungsgrenze bereit. Vertrauenskettenauflösung, Vertrauensanker, Richtlinienverarbeitung und Produktionsinteroperabilität sind nicht implementiert. |
| Geplant | Shared Signals, CAEP, RISC, GNAP, UMA, HEART, OpenID4VP und OpenID4VCI stellen reservierte Routen bereit, die explizite 501-Fehler zurückgeben. Es handelt sich nicht um Protokollimplementierungen. |
| Produktionsnachweise | Lokale Implementierungs- und Konformitätstore sind keine Produktionszertifizierung. Downstream-SaaS-OIDC verwendet die generische OIDC-Basislinie, aber jede SaaS-Integration erfordert immer noch echte externe L4-Nachweise. |
| Veraltet oder nicht unterstützt | Implicit Flow, Password Grant, Plain-PKCE und Wildcard-Redirects. |
Rollengrenzen
| 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-Typen
| 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. |
Geschützte oder minimale OAuth- und OIDC-Erweiterungen
| 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 | Es werden nur negative Routen- und Metadaten-Stubs angezeigt. Nicht unterstützte Vorgänge geben explizites 501 unsupported_feature zurück; Es wird keine funktionale Protokollunterstützung beansprucht. |