---
title: "OIDC und OAuth"
description: "Discovery-, Autorisierungs-, Token-, Logout- und OAuth-Erweiterungsendpunkte.OAuth-Erweiterungsendpunkte."
locale: "de"
---

> Documentation Index
> Fetch the locale documentation index at: https://xid.dev/de/llms.txt
> Use this file to discover all available pages before exploring further.

# OIDC und OAuth

## 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_jkt` ist an den Authorization Code Exchange gebunden.

## Supportstufen

| 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. |

## 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 | Minimale Routen-Teilmengen und discovery-freundliche Metadaten werden bereitgestellt. Nicht unterstützte Operationen liefern explizite Fehler, bis vollständige Profil-Handler verfügbar sind. |

Source: https://xid.dev/de/oidc-oauth/index.mdx