79| Feld | Erforderlich | Beschreibung |79| Feld | Erforderlich | Beschreibung |
80| - | - | - |80| - | - | - |
81| `issuer` | Ja | OIDC-Discovery-Basis. Muss Discovery unter `/.well-known/openid-configuration` bereitstellen. Verwenden Sie HTTPS in der Produktion; das Gateway akzeptiert einen `http://`-Aussteller. Ein Loopback-Aussteller wie `http://localhost:8081` wird vom [SSRF-Schutz](/docs/de/claude-apps-gateway-deploy#threat-model-summary) abgelehnt, sofern `CLAUDE_GATEWAY_ALLOW_LOOPBACK=1` in der Umgebung des Gateways nicht gesetzt ist. |81| `issuer` | Ja | OIDC-Discovery-Basis. Muss Discovery unter `/.well-known/openid-configuration` bereitstellen. Verwenden Sie HTTPS in der Produktion; das Gateway akzeptiert einen `http://`-Aussteller. Ein Loopback-Aussteller wie `http://localhost:8081` wird vom [SSRF-Schutz](/docs/de/claude-apps-gateway-deploy#threat-model-summary) abgelehnt, sofern `CLAUDE_GATEWAY_ALLOW_LOOPBACK=1` in der Umgebung des Gateways nicht gesetzt ist. |
82| `client_id` / `client_secret` | Ja | Aus Ihrer OAuth-Client-Registrierung |82| `client_id` | Ja | Aus Ihrer OAuth-Client-Registrierung |
83| `client_secret` | Sofern `token_endpoint_auth_method` nicht `private_key_jwt` ist | Aus Ihrer OAuth-Client-Registrierung. Lassen Sie es weg, wenn Sie [zertifikatbasierte Client-Authentifizierung](#certificate-client-authentication) verwenden. |
83| `allowed_email_domains` | Nein | Lehnen Sie id\_tokens ab, deren `email`-Anspruch nicht in einer dieser Domänen liegt, Groß-/Kleinschreibung wird ignoriert. Defense-in-Depth gegen Multi-Tenant-IdP-Fehlkonfiguration. Unabhängig von dieser Einstellung wird ein id\_token, dessen `email_verified`-Anspruch explizit `false` ist, immer abgelehnt. |84| `allowed_email_domains` | Nein | Lehnen Sie id\_tokens ab, deren `email`-Anspruch nicht in einer dieser Domänen liegt, Groß-/Kleinschreibung wird ignoriert. Defense-in-Depth gegen Multi-Tenant-IdP-Fehlkonfiguration. Unabhängig von dieser Einstellung wird ein id\_token, dessen `email_verified`-Anspruch explizit `false` ist, immer abgelehnt. |
84| `allowed_groups` | Nein | Beschränken Sie die Anmeldung auf Mitglieder dieser IdP-Gruppen, abgeglichen gegen `groups_claim`. Ein Benutzer in einer zulässigen E-Mail-Domäne, aber in keiner dieser Gruppen, wird abgelehnt. Erfordert, dass der IdP den Gruppenanspruch ausgibt. Der Abgleich ist ein exakter, Groß-/Kleinschreibung beachtender Zeichenfolgenvergleich gegen die Werte in diesem Anspruch, und das Gateway erweitert verschachtelte Gruppen nicht: Um Mitglieder einer Untergruppe zuzulassen, listen Sie die Untergruppe hier auf oder konfigurieren Sie den IdP so, dass er flache Mitgliedschaften ausgibt. |85| `allowed_groups` | Nein | Beschränken Sie die Anmeldung auf Mitglieder dieser IdP-Gruppen, abgeglichen gegen `groups_claim`. Ein Benutzer in einer zulässigen E-Mail-Domäne, aber in keiner dieser Gruppen, wird abgelehnt. Erfordert, dass der IdP den Gruppenanspruch ausgibt. Der Abgleich ist ein exakter, Groß-/Kleinschreibung beachtender Zeichenfolgenvergleich gegen die Werte in diesem Anspruch, und das Gateway erweitert verschachtelte Gruppen nicht: Um Mitglieder einer Untergruppe zuzulassen, listen Sie die Untergruppe hier auf oder konfigurieren Sie den IdP so, dass er flache Mitgliedschaften ausgibt. |
85| `groups_claim` | Nein | Welcher id\_token-Anspruch trägt die Gruppenmitgliedschaft. Standard `groups`. Microsoft Entra gibt App-Rollen unter `roles` aus. Akzeptiert einen flachen Schlüssel oder einen RFC-6901-JSON-Pointer wie `/resource_access/gateway/roles` für verschachtelte Ansprüche. |86| `groups_claim` | Nein | Welcher id\_token-Anspruch trägt die Gruppenmitgliedschaft. Standard `groups`. Microsoft Entra gibt App-Rollen unter `roles` aus. Akzeptiert einen flachen Schlüssel oder einen RFC-6901-JSON-Pointer wie `/resource_access/gateway/roles` für verschachtelte Ansprüche. |
91| `userinfo_fallback` | Nein | Wenn das id\_token E-Mail oder Gruppen auslässt, rufen Sie diese von `/userinfo` ab. Erforderlich für Keycloak-Lightweight-Zugriffstokens, den Okta-Org-Server und ADFS-Minimal-Tokens. Das id\_token bleibt maßgeblich; userinfo füllt nur Lücken. Standard `false`. |92| `userinfo_fallback` | Nein | Wenn das id\_token E-Mail oder Gruppen auslässt, rufen Sie diese von `/userinfo` ab. Erforderlich für Keycloak-Lightweight-Zugriffstokens, den Okta-Org-Server und ADFS-Minimal-Tokens. Das id\_token bleibt maßgeblich; userinfo füllt nur Lücken. Standard `false`. |
92| `use_pkce` | Nein | Senden Sie eine PKCE-Herausforderung (S256) in der Autorisierungsanfrage. Standard `true`. Setzen Sie `false` nur, wenn Ihr IdP PKCE für diesen vertraulichen Client ablehnt. |93| `use_pkce` | Nein | Senden Sie eine PKCE-Herausforderung (S256) in der Autorisierungsanfrage. Standard `true`. Setzen Sie `false` nur, wenn Ihr IdP PKCE für diesen vertraulichen Client ablehnt. |
93| `clock_skew_seconds` | Nein | Tolerieren Sie Uhrenabweichungen beim Validieren von id\_token-Zeitansprüchen. Standard `0`, was streng ist. Erhöhen Sie, wenn Sie unmittelbar nach der Anmeldung aufgrund von Host-/IdP-Uhrenabweichung Fehler „Token abgelaufen / noch nicht gültig" sehen. |94| `clock_skew_seconds` | Nein | Tolerieren Sie Uhrenabweichungen beim Validieren von id\_token-Zeitansprüchen. Standard `0`, was streng ist. Erhöhen Sie, wenn Sie unmittelbar nach der Anmeldung aufgrund von Host-/IdP-Uhrenabweichung Fehler „Token abgelaufen / noch nicht gültig" sehen. |
94| `token_endpoint_auth_method` | Nein | Überschreiben Sie die Token-Endpunkt-Authentifizierungsmethode. Akzeptiert `client_secret_basic` oder `client_secret_post`. Standardmäßig automatisch ausgehandelt. |95| `token_endpoint_auth_method` | Nein | Wie sich das Gateway beim Token-Endpunkt des IdP authentifiziert: `client_secret_basic`, `client_secret_post` oder `private_key_jwt` für [zertifikatbasierte Client-Authentifizierung](#certificate-client-authentication). Standardmäßig wählt das Gateway eine der beiden `client_secret`-Methoden anhand dessen, was der IdP ankündigt. |
96| `client_assertion` | Mit `private_key_jwt` | Ein Block mit `private_key_pem` und `certificate_pem`: der private Schlüssel und das Zertifikat für [zertifikatbasierte Client-Authentifizierung](#certificate-client-authentication). Erfordert v2.1.284 oder später. |
95| `id_token_signed_response_alg` | Nein | Erwarteter id\_token-Signaturalgorithmus. Standard `RS256`. Setzen Sie für IdPs, die mit ES256, PS256 oder EdDSA signieren. |97| `id_token_signed_response_alg` | Nein | Erwarteter id\_token-Signaturalgorithmus. Standard `RS256`. Setzen Sie für IdPs, die mit ES256, PS256 oder EdDSA signieren. |
96| `additional_authorized_parties` | Nein | Zusätzliche `azp`-Werte, die neben `client_id` akzeptiert werden, für Keycloak-Broker und Token-Exchange-Flows |98| `additional_authorized_parties` | Nein | Zusätzliche `azp`-Werte, die neben `client_id` akzeptiert werden, für Keycloak-Broker und Token-Exchange-Flows |
97| `discovery_url` | Nein | Rufen Sie das Discovery-Dokument von dieser URL ab, anstatt es von `issuer` abzuleiten, für IdPs hinter einem Proxy, der den Aussteller-Host umschreibt. Der Pfad muss `/.well-known/` enthalten. |99| `discovery_url` | Nein | Rufen Sie das Discovery-Dokument von dieser URL ab, anstatt es von `issuer` abzuleiten, für IdPs hinter einem Proxy, der den Aussteller-Host umschreibt. Der Pfad muss `/.well-known/` enthalten. |
99| `form_action_origins` | Nein | Zusätzliche Ursprünge für die `Content-Security-Policy: form-action`-Direktive der `/device`-Seite. Das Gateway erlaubt bereits `'self'` und den erkannten `authorization_endpoint`-Ursprung, aber Chrome erzwingt `form-action` gegen die gesamte Umleitungskette. Wenn Ihr IdP durch einen zweiten Host umleitet, wie Azure AD, das zu ADFS verbunden ist, Hub-Spoke-Okta oder ein unternehmensweiter SSO-Interceptor, listen Sie jeden Ursprung auf, durch den die Autorisierungsanfrage umgeleitet werden kann. |101| `form_action_origins` | Nein | Zusätzliche Ursprünge für die `Content-Security-Policy: form-action`-Direktive der `/device`-Seite. Das Gateway erlaubt bereits `'self'` und den erkannten `authorization_endpoint`-Ursprung, aber Chrome erzwingt `form-action` gegen die gesamte Umleitungskette. Wenn Ihr IdP durch einen zweiten Host umleitet, wie Azure AD, das zu ADFS verbunden ist, Hub-Spoke-Okta oder ein unternehmensweiter SSO-Interceptor, listen Sie jeden Ursprung auf, durch den die Autorisierungsanfrage umgeleitet werden kann. |
100| `ca_cert_pem` | Nein | Das PEM-codierte CA-Zertifikat selbst, nicht ein Pfad zu einer Datei. Es ersetzt den System-Trust-Store nur für IdP-Anfragen. Um eine bereitgestellte Datei zu laden, schreiben Sie `${file:/etc/gateway/idp-ca.pem}`. Verwenden Sie für Keycloak oder Dex hinter unternehmensweiter PKI. |102| `ca_cert_pem` | Nein | Das PEM-codierte CA-Zertifikat selbst, nicht ein Pfad zu einer Datei. Es ersetzt den System-Trust-Store nur für IdP-Anfragen. Um eine bereitgestellte Datei zu laden, schreiben Sie `${file:/etc/gateway/idp-ca.pem}`. Verwenden Sie für Keycloak oder Dex hinter unternehmensweiter PKI. |
101 103
104<h4 id="certificate-client-authentication">
105 Zertifikatbasierte Client-Authentifizierung
106</h4>
107
108Wenn Ihr Identitätsanbieter OAuth-Clients mit einem Zertifikat statt mit einem Client-Secret authentifiziert, wie es Microsoft Entra mit Zertifikat-Anmeldedaten tut, setzen Sie `token_endpoint_auth_method: private_key_jwt`. Erfordert Claude Code v2.1.284 oder später auf dem Gateway-Server.
109
110Mit dieser Konfiguration sendet das Gateway kein Secret. Es authentifiziert sich beim Token-Endpunkt des IdP mit einem kurzlebigen JWT, das mit dem privaten Schlüssel des Zertifikats signiert ist, wenn sich ein Entwickler anmeldet und jedes Mal, wenn das Gateway dessen Sitzung aktualisiert. Das JWT wird mit RS256 signiert und identifiziert das Zertifikat über die Thumbprint-Header `x5t` und `x5t#S256` statt über eine `kid`. Ihr IdP muss das registrierte Zertifikat anhand des Thumbprints finden können.
111
112<Steps>
113 <Step title="Schlüssel und Zertifikat erstellen">
114 Erstellen Sie einen unverschlüsselten RSA-Privatschlüssel mit mindestens 2048 Bit im PEM-Format PKCS#8 oder PKCS#1 sowie ein Zertifikat dafür. Das Gateway weigert sich, mit einem Schlüssel zu starten, der diese Bedingungen nicht erfüllt. Dieser `openssl`-Befehl erstellt einen solchen Schlüssel mit einem selbstsignierten Zertifikat, das ein Jahr gültig ist:
115
116 ```bash theme={null}
117 openssl req -x509 -newkey rsa:2048 -nodes -keyout idp-client.key -out idp-client.crt -days 365 -subj "/CN=claude-gateway"
118 ```
119
120 Er schreibt `idp-client.key` und `idp-client.crt` in das aktuelle Verzeichnis. Kopieren oder mounten Sie beide Dateien an einen Ort, an dem das Gateway sie lesen kann. Das Beispiel in Schritt 3 verwendet `/etc/gateway/`.
121 </Step>
122
123 <Step title="Zertifikat beim IdP hochladen">
124 Laden Sie das Zertifikat, nicht den privaten Schlüssel, in die App-Registrierung des Gateways beim IdP hoch.
125 </Step>
126
127 <Step title="Schlüssel und Zertifikat zu gateway.yaml hinzufügen">
128 Übergeben Sie dem Gateway den privaten Schlüssel und das Zertifikat in einem `client_assertion`-Block. Lassen Sie `client_secret` weg, da sich das Gateway weigert zu starten, wenn es zusammen mit `private_key_jwt` gesetzt ist. Dieser `oidc`-Block authentifiziert das Gateway mit einem Zertifikat bei einem Microsoft Entra-Mandanten:
129
130 ```yaml theme={null}
131 oidc:
132 issuer: https://login.microsoftonline.com/<tenant-id>/v2.0
133 client_id: <application-id>
134 token_endpoint_auth_method: private_key_jwt
135 client_assertion:
136 private_key_pem: ${file:/etc/gateway/idp-client.key}
137 certificate_pem: ${file:/etc/gateway/idp-client.crt}
138 ```
139
140 Beide Werte sind die PEM-Inhalte, keine Dateipfade, laden Sie gemountete Dateien also wie im Beispiel mit `${file:/path}`. Das Gateway weigert sich zu starten, sofern `certificate_pem` nicht ein einzelnes PEM-Zertifikat ohne den Rest seiner Kette ist, dessen öffentlicher Schlüssel zu `private_key_pem` passt.
141 </Step>
142
143 <Step title="Gateway neu starten und Boot-Log prüfen">
144 Starten Sie das Gateway neu und suchen Sie diese Zeile im Boot-Log:
145
146 ```text theme={null}
147 [gateway] 2026-10-01T23:07:40.512Z info oidc: client authentication private_key_jwt; certificate CN=claude-gateway, SHA-1 thumbprint DE92821854EE8BAA1D98C758FAA04AABE80B9F57, expires Oct 1 23:07:31 2027 GMT
148 ```
149
150 Vergleichen Sie den SHA-1-Thumbprint mit dem, den der IdP für das hochgeladene Zertifikat anzeigt. Wenn das Zertifikat abgelaufen oder noch nicht gültig ist, startet das Gateway trotzdem, protokolliert aber eine Warnung, dass Anmeldungen und Aktualisierungen fehlschlagen, bis Sie es ersetzen. Um zu bestätigen, dass der IdP das Zertifikat akzeptiert, lassen Sie einen Entwickler sich über das Gateway anmelden.
151 </Step>
152</Steps>
153
154<h4 id="rotate-the-client-certificate">
155 Client-Zertifikat rotieren
156</h4>
157
158Das Gateway liest Schlüssel und Zertifikat einmal beim Start, eine geänderte Datei wird also erst nach einem Neustart wirksam. Rotieren Sie in dieser Reihenfolge, damit keine Token-Anfrage ein Zertifikat vorlegt, das dem IdP nicht vorliegt:
159
1601. Laden Sie das neue Zertifikat zusätzlich zum alten beim IdP hoch.
1612. Ersetzen Sie die Schlüssel- und Zertifikatsdateien, die `gateway.yaml` lädt, und starten Sie dann das Gateway neu.
1623. Entfernen Sie das alte Zertifikat beim IdP.
163
102<h4 id="idp-requests-through-a-forward-proxy">164<h4 id="idp-requests-through-a-forward-proxy">
103 IdP-Anfragen durch einen Forward-Proxy165 IdP-Anfragen durch einen Forward-Proxy
104</h4>166</h4>
