{"meta":{"title":"OpenID Connect-Referenz","intro":"Hier finden Sie Informationen zur Verwendung von OpenID Connect (OIDC), um Workflows bei Cloudanbietern zu authentifizieren GitHub Actions .","product":"GitHub Actions","breadcrumbs":[{"href":"/de/actions","title":"GitHub Actions"},{"href":"/de/actions/reference","title":"Verweis"},{"href":"/de/actions/reference/security","title":"Sicherheit"},{"href":"/de/actions/reference/security/oidc","title":"OIDC"}],"documentType":"article"},"body":"# OpenID Connect-Referenz\n\nHier finden Sie Informationen zur Verwendung von OpenID Connect (OIDC), um Workflows bei Cloudanbietern zu authentifizieren GitHub Actions .\n\n## OIDC-Tokenansprüche\n\nWenn Sie alle ansprüche anzeigen möchten, die vom GitHubOIDC-Anbieter unterstützt werden, überprüfen Sie die `claims_supported` Einträge unterhttps\\://token.actions.githubusercontent.com/.well-known/openid-configuration .\n\nDas OIDC-Token enthält die folgenden Ansprüche.\n\n### Standardzielgruppe, Aussteller und Betreffansprüche\n\n| Anspruch | Anspruchstyp        | BESCHREIBUNG                                                                                                                                                                                                                                                                   |\n| -------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| `aud`    | Zielgruppe          | Standardmäßig ist dies die URL des Repositorybesitzers, z. B. die Organisation, die das Repository besitzt. Du kannst eine benutzerdefinierte Zielgruppe mit einem Toolkitbefehl festlegen: [`core.getIDToken(audience)`](https://www.npmjs.com/package/@actions/core/v/1.6.0) |\n| `iss`    | Issuer (Aussteller) | Der Aussteller des OIDC-Tokens: `https://token.actions.githubusercontent.com`                                                                                                                                                                                                  |\n| `sub`    | Betreff             | Definiert den Antragstelleranspruch, der vom Cloudanbieter überprüft werden soll. Diese Einstellung ist wichtig, um sicherzustellen, dass Zugriffstoken nur auf vorhersehbare Weise zugewiesen werden.                                                                         |\n\n### Zusätzliche Standard-JOSE-Headerparameter und -Ansprüche\n\n| Header-Parameter | Parametertyp        | BESCHREIBUNG                                                |\n| ---------------- | ------------------- | ----------------------------------------------------------- |\n| `alg`            | Algorithmus         | Der Algorithmus, der vom OIDC-Anbieter verwendet wird       |\n| `kid`            | Schlüsselbezeichner | Eindeutiger Schlüssel des OIDC-Tokens                       |\n| `typ`            | Typ                 | Beschreibt den Tokentyp. Dies ist ein JSON Web Token (JWT). |\n\n| Anspruch | Anspruchstyp        | BESCHREIBUNG                                                  |\n| -------- | ------------------- | ------------------------------------------------------------- |\n| `exp`    | Läuft ab am         | Identifiziert die Ablaufzeit des JWT                          |\n| `iat`    | Ausgestellt um      | Der Zeitpunkt, zu dem das JWT ausgestellt wurde.              |\n| `jti`    | JWT-Tokenbezeichner | Eindeutiger Bezeichner des OIDC-Tokens                        |\n| `nbf`    | Nicht vor           | JWT ist vor diesem Zeitpunkt nicht gültig für die Verwendung. |\n\n### Benutzerdefinierte Ansprüche, bereitgestellt von GitHub\n\n| Anspruch           | BESCHREIBUNG                                                                                                                                                                                                                                                                                                                               |\n| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| `actor`            | Das persönliche Konto, das die Workflowausführung ausgelöst hat.                                                                                                                                                                                                                                                                           |\n| `actor_id`         | Die ID des persönlichen Kontos, das die Workflowausführung ausgelöst hat.                                                                                                                                                                                                                                                                  |\n| `base_ref`         | Der Zielbranch des Pull-Requests in einem Workflow-Durchlauf.                                                                                                                                                                                                                                                                              |\n|                    |                                                                                                                                                                                                                                                                                                                                            |\n| `check_run_id`     | Überprüfungsausführungs-ID des aktuellen Auftrags                                                                                                                                                                                                                                                                                          |\n|                    |                                                                                                                                                                                                                                                                                                                                            |\n|                    |                                                                                                                                                                                                                                                                                                                                            |\n|                    |                                                                                                                                                                                                                                                                                                                                            |\n| `environment`      | Der Name der vom Job verwendeten Umgebung. Wenn der `environment`-Anspruch enthalten ist (auch über `include_claim_keys`), ist eine Umgebung erforderlich und muss bereitgestellt werden.                                                                                                                                                  |\n| `event_name`       | Der Name des Ereignisses, das den Workflow-Lauf ausgelöst hat.                                                                                                                                                                                                                                                                             |\n| `head_ref`         | Der Quellbranch des Pull Requests in einem Workflow-Durchlauf.                                                                                                                                                                                                                                                                             |\n| `job_workflow_ref` | Bei Aufträgen, die einen wiederverwendbaren Workflow verwenden, ist dies der Verweispfad zum wiederverwendbaren Workflow. Weitere Informationen finden Sie unter [Verwenden von OpenID Connect mit wiederverwendbaren Workflows](/de/actions/deployment/security-hardening-your-deployments/using-openid-connect-with-reusable-workflows). |\n| `job_workflow_sha` | Bei Aufträgen, die einen wiederverwendbaren Workflow verwenden, wird der Commit-SHA für die wiederverwendbare Workflowdatei verwendet.                                                                                                                                                                                                     |\n| `ref`              |                                                                                                                                                                                                                                                                                                                                            |\n\n```\n          _(Referenz)_ Die Git-Ref, die die Workflowausführung ausgelöst hat.                   |\n```\n\n\\| `ref_type`| Der `ref`-Typ, z. B. „Branch“.                  |\n\\| `repository_visibility` | Die Sichtbarkeit des Repositorys, in dem der Workflow ausgeführt wird. Akzeptiert die folgenden Werte: `internal`, `private` oder `public`.                   |\n\\| `repository`| Das Repository, aus dem der Workflow ausgeführt wird.                   |\n\\| `repository_id`| Die ID des Repositorys, von dem der Workflow ausgeführt wird.  |\n\\| `repository_owner`| Der Name der Organisation, in der das `repository` gespeichert wird.                   |\n\\| `repository_owner_id`| Die ID der Organisation, in der das `repository` gespeichert wird.            |\n\\|  |\n\\| `repo_property_*`| Benutzerdefinierte Eigenschaften, die auf Organisations- oder Unternehmensebene definiert sind, als Claims im OIDC-Token enthalten sind und das Präfix `repo_property_` aufweisen. Weitere Informationen finden Sie unter [Einschließen von benutzerdefinierten Repositoryeigenschaften in OIDC-Token](#including-repository-custom-properties-in-oidc-tokens).                  |\n\\|  |\n\\| `run_id`| Die ID der Workflowausführung, die den Workflow ausgelöst hat.                   |\n\\| `run_number`| Die Angabe, wie oft dieser Workflow ausgeführt wurde.                   |\n\\| `run_attempt`| Die Angabe, wie oft diese Workflowausführung wiederholt wurde.                    |\n\\| `runner_environment`| Der vom Auftrag verwendete Runner-Typ. Akzeptiert die folgenden Werte: `github-hosted` oder `self-hosted`.                  |\n\\| `workflow`| Der Name des Workflows.                   |\n\\| `workflow_ref`| Der Verweispfad zum Workflow. Beispiel: `octocat/hello-world/.github/workflows/my-workflow.yml@refs/heads/my_branch`.                   |\n\\| `workflow_sha`| Der Commit-SHA für die Workflowdatei.                   |\n\n## OIDC-Ansprüche zum Definieren von Vertrauensbedingungen für Cloudrollen\n\nZielgruppenansprüche und Subjektansprüche werden in der Regel in Kombination verwendet, während Bedingungen für die Cloudrolle/-ressourcen festgelegt werden, um den Zugriff auf die GitHub Workflows einzuschränken.\n\n* **Zielgruppe**: Standardmäßig verwendet dieser Wert die URL der Organisation oder des Repositorybesitzers. Damit kann eine Bedingung festgelegt werden, nach der nur die Workflows in der bestimmten Organisation auf die Cloudrolle zugreifen können.\n* **Betreff:** Verfügt standardmäßig über ein vordefiniertes Format und ist eine Verkettung einiger der wichtigsten Metadaten zum Workflow, z. B. die Organisation, das GitHub Repository, die Verzweigung oder die zugehörige [`job`](/de/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idenvironment) Umgebung. Unter [Beispiele für Antragstelleransprüche](#example-subject-claims) wird dargestellt, wie der Antragstelleranspruch aus verketteten Metadaten zusammengefügt wird.\n\nWenn Sie detailliertere Vertrauensbedingungen benötigen, können Sie den Betreff (`sub`)  die im JWT enthalten sind. Weitere Informationen findest du unter [Anpassen der Tokenansprüche](#customizing-the-token-claims).\n\nEs gibt viele zusätzliche Ansprüche, die im OIDC-Token unterstützt werden und zum Festlegen dieser Bedingungen verwendet werden können. Darüber hinaus könnte dein Cloudanbieter zulassen, dass du den Zugriffstoken eine Rolle zuweist, sodass du noch genauere Berechtigungen angeben kannst.\n\n> \\[!NOTE]\n> Zur Steuerung, wie dein Cloud-Anbieter Zugriffs-Token ausgibt, **musst** du mindestens eine Bedingung definieren, damit nicht vertrauenswürdige Repositorys keine Zugriffs-Token für deine Cloud-Ressourcen anfordern können.\n\n## Beispiele für Ansprüche des Gegenstands\n\nDie folgenden Beispiele veranschaulichen, wie du „Antragsteller“ als Bedingung verwendest, und erläutern, wie „Antragsteller“ aus verketteten Metadaten zusammengefügt wird. Der [Antragsteller](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) verwendet Informationen aus dem [`job` Kontext](/de/actions/learn-github-actions/contexts#job-context) und weist deinen Cloudanbieter an, dass Zugriffstokenanforderungen nur für Anforderungen aus Workflows gewährt werden, die in bestimmten Branches und Umgebungen ausgeführt werden. In den folgenden Abschnitten werden einige allgemeine Themen beschrieben, die Sie verwenden können.\n\n### Filtern nach einer bestimmten Umgebung\n\nDer Antragstelleranspruch umfasst den Umgebungsnamen, wenn der Auftrag auf eine Umgebung verweist.\n\nDu kannst ein Thema konfigurieren, das nach einem bestimmten [Umgebungsnamen](/de/actions/deployment/targeting-different-environments/managing-environments-for-deployment) filtert. In diesem Beispiel muss die Workflowausführung aus einem Auftrag stammen, der eine Umgebung namens `Production` in einem Repository namens `octo-repo` hat, das der Organisation `octo-org`:\n\n* Syntax: `repo:ORG-NAME/REPO-NAME:environment:ENVIRONMENT-NAME`\n* Beispiel: `repo:octo-org/octo-repo:environment:Production`\n\n### Filtern nach `pull_request`-Ereignissen\n\nDer Betreffsanspruch enthält die Zeichenfolge `pull_request`, wenn der Workflow durch ein Pull Request-Ereignis ausgelöst wird, jedoch nur, wenn der Job nicht auf eine Umgebung verweist.\n\nDu kannst ein Subjekt konfigurieren, das nach dem [`pull_request`](/de/actions/using-workflows/events-that-trigger-workflows#pull_request)-Ereignis filtert. In diesem Beispiel muss die Workflowausführung durch ein `pull_request`-Ereignis in einem Repository namens `octo-repo` ausgelöst worden sein, das der Organisation `octo-org` gehört:\n\n* Syntax: `repo:ORG-NAME/REPO-NAME:pull_request`\n* Beispiel: `repo:octo-org/octo-repo:pull_request`\n\n### Filtern nach einem bestimmten Zweig\n\nDer Antragstelleranspruch enthält den Branchnamen des Workflows, aber nur, wenn der Auftrag nicht auf eine Umgebung verweist und wenn der Workflow nicht durch ein Pull Request-Ereignis ausgelöst wird.\n\nSie können ein Thema konfigurieren, das nach einem bestimmten Branchnamen filtert. In diesem Beispiel muss die Workflowausführung aus einem Branch namens `demo-branch` in einem Repository namens `octo-repo` ausgelöst worden sein, das der Organisation `octo-org` gehört:\n\n* Syntax: `repo:ORG-NAME/REPO-NAME:ref:refs/heads/BRANCH-NAME`\n* Beispiel: `repo:octo-org/octo-repo:ref:refs/heads/demo-branch`\n\n### Filtern nach einem bestimmten Tag\n\nDer Antragstelleranspruch enthält den Tagnamen des Workflows, aber nur, wenn der Auftrag nicht auf eine Umgebung verweist und wenn der Workflow nicht durch ein Pull Request-Ereignis ausgelöst wird.\n\nDu kannst ein Thema erstellen, das nach einem bestimmten Tag filtert. In diesem Beispiel muss die Workflowausführung mit einem Tag namens `demo-tag` in einem Repository namens `octo-repo` ausgelöst worden sein, das der Organisation `octo-org` gehört:\n\n* Syntax: `repo:ORG-NAME/REPO-NAME:ref:refs/tags/TAG-NAME`\n* Beispiel: `repo:octo-org/octo-repo:ref:refs/tags/demo-tag`\n\n### Filtern nach Metadaten, die enthalten `:`\n\nAlle `:` innerhalb der Metadatenwerte wird im Subjektanspruch durch `%3A` ersetzt.\n\nSie können einen Betreff konfigurieren, der Metadaten enthält, die Doppelpunkte enthalten. In diesem Beispiel muss die Workflowausführung aus einem Auftrag stammen, der eine Umgebung namens `Production:V1` in einem Repository namens `octo-repo` hat, das der Organisation `octo-org`:\n\n* Syntax: `repo:ORG-NAME/REPO-NAME:environment:ENVIRONMENT-NAME`\n* Beispiel: `repo:octo-org/octo-repo:environment:Production%3AV1`\n\n## Konfiguration des Subjekts bei deinem Cloudanbieter\n\nFür die Konfiguration des Antragstellers in der Vertrauensstellung deines Cloudanbieters musst du der vertrauenswürdigen Konfiguration die Antragstellerzeichenfolge hinzufügen. In den folgenden Beispielen wird demonstriert, wie verschiedene Cloud-Anbieter dasselbe `repo:octo-org/octo-repo:ref:refs/heads/demo-branch` Thema auf unterschiedliche Weise akzeptieren können.\n\n| Cloudanbieter         | Beispiel                                                                                          |\n| --------------------- | ------------------------------------------------------------------------------------------------- |\n| Amazon Web Services   | `\"token.actions.githubusercontent.com:sub\": \"repo:octo-org/octo-repo:ref:refs/heads/demo-branch\"` |\n| Azure                 | `repo:octo-org/octo-repo:ref:refs/heads/demo-branch`                                              |\n| Google Cloud Platform | `(assertion.sub=='repo:octo-org/octo-repo:ref:refs/heads/demo-branch')`                           |\n| HashiCorp Vault       | `bound_subject=\"repo:octo-org/octo-repo:ref:refs/heads/demo-branch\"`                              |\n\nWeitere Informationen zum Konfigurieren bestimmter Cloudanbieter findest du in den Anleitungen, die unter [Sicherheitshärtung deiner Bereitstellungen](/de/actions/how-tos/security-for-github-actions/security-hardening-your-deployments) aufgeführt sind.\n\n## Anpassen der Tokenansprüche\n\nDu kannst die Sicherheit deiner OIDC-Konfiguration verbessern, indem du die Ansprüche anpasst, die im JWT enthalten sind. Mit diesen Anpassungen kannst du detailliertere Vertrauensbedingungen für deine Cloudrollen definieren, wenn du deinen Workflows den Zugriff auf in der Cloud gehostete Ressourcen gestattest:\n\n* Sie können Werte für `audience` Ansprüche anpassen. Siehe [Anpassen des `audience` Werts](#customizing-the-audience-value).\n\n* Du kannst das Format deiner OIDC-Konfiguration anpassen, indem du Bedingungen für den Antragstelleranspruch (`sub`) festlegst, die erfordern, dass JWT-Token aus einem bestimmten Repository, einem wiederverwendbaren Workflow oder einer anderen Quelle stammen.\n\n* Du kannst detaillierte OIDC-Richtlinien definieren, indem du zusätzliche OIDC-Tokenansprüche wie z. B. `repository_id` und `repository_visibility` verwendest. Weitere Informationen findest du unter [OpenID Connect](/de/actions/concepts/security/openid-connect#understanding-the-oidc-token).\n\n* Sie können benutzerdefinierte Repositoryeigenschaften als Ansprüche in OIDC-Token einschließen und attributbasierte Zugriffssteuerungsrichtlinien aktivieren. Siehe [Einschließen von benutzerdefinierten Repositoryeigenschaften in OIDC-Token](#including-repository-custom-properties-in-oidc-tokens).\n\n### Anpassen des `audience`-Werts\n\nWenn Sie benutzerdefinierte Aktionen in Ihren Workflows verwenden, können diese Aktionen das GitHub Actions Toolkit verwenden, um Ihnen das Bereitstellen eines benutzerdefinierten Werts für den `audience` Anspruch zu ermöglichen. Einige Cloudanbieter verwenden dies auch in ihren offiziellen Anmeldeaktionen, um einen Standardwert für den `audience`-Anspruch zu erzwingen. Die [GitHub Action for Azure Login](https://github.com/Azure/login/blob/master/action.yml) stellt einen Standardwert von `aud``api://AzureADTokenExchange` bereit oder ermöglicht es Ihnen, in Ihren Workflows einen benutzerdefinierten Wert von `aud` festzulegen. Weitere Informationen zum GitHub Actions Toolkit finden Sie im Abschnitt [\"OIDC-Token](https://github.com/actions/toolkit/tree/main/packages/core#oidc-token) \" in der Dokumentation.\n\nWenn du den von einer Aktion angebotenen Standard-`aud`-Wert nicht verwenden möchtest, kannst du einen benutzerdefinierten Wert für den `audience`-Anspruch angeben. Damit kannst du eine Bedingung festlegen, nach der nur die Workflows in einem bestimmten Repository oder einer bestimmten Organisation auf die Cloudrolle zugreifen können. Wenn die von dir verwendete Aktion dies unterstützt, kannst du das `with`-Schlüsselwort in deinem Workflow verwenden, um einen benutzerdefinierten `aud`-Wert an die Aktion zu übergeben. Weitere Informationen finden Sie unter [Referenz zur Metadatensyntax](/de/actions/creating-actions/metadata-syntax-for-github-actions#inputs).\n\n### Einschließen von benutzerdefinierten Repositoryeigenschaften in OIDC-Token\n\nOrganisations- und Unternehmensadministratoren können benutzerdefinierte Repositoryeigenschaften auswählen, die als Ansprüche in GitHub Actions OIDC-Token eingeschlossen werden sollen. Sobald eine benutzerdefinierte Eigenschaft zur OIDC-Konfiguration hinzugefügt wurde, enthält jedes Repository in der Organisation oder im Unternehmen, das einen Wert für diese Eigenschaft festgelegt hat, diese automatisch in seine OIDC-Token ein. Der Eigenschaftenname wird im Token mit dem Präfix `repo_property_` angezeigt.\n\nAuf diese Weise können Sie attributbasierte Zugriffssteuerungsrichtlinien (ABAC) in Ihrem Cloudanbieter erstellen, die direkt an Ihre Repositorymetadaten gebunden sind, wodurch die Konfigurationsabweichung reduziert und die Notwendigkeit einer separaten Zugriffskonfiguration für jedes Repository vermieden werden muss.\n\n#### Anspruchsformat\n\nJede aktivierte benutzerdefinierte Eigenschaft wird als separater Anspruch im OIDC-Token angezeigt. Der Anspruchsname ist der Eigenschaftsname mit dem Präfix `repo_property_`.\n\n| Name der benutzerdefinierten Eigenschaft | Anspruchsname im OIDC-Token         |\n| ---------------------------------------- | ----------------------------------- |\n| `business_unit`                          | `repo_property_business_unit`       |\n| `workspace_id`                           | `repo_property_workspace_id`        |\n| `data_classification`                    | `repo_property_data_classification` |\n\n#### Unterstützte Eigenschaftentypen\n\nDie folgenden benutzerdefinierten Eigenschaftentypen werden als OIDC-Ansprüche unterstützt. Die Wertdarstellung im Token hängt vom Eigenschaftentyp ab.\n\n| Immobilientyp   | Beispielwert im OIDC-Token                       | Hinweise                                                                                                   |\n| --------------- | ------------------------------------------------ | ---------------------------------------------------------------------------------------------------------- |\n| String          | `\"repo_property_team\": \"platform-eng\"`           | Der Wert wird als einfache Zeichenfolge angezeigt.                                                         |\n| Einzelauswahl   | `\"repo_property_env_tier\": \"production\"`         | Die ausgewählte Option wird als einfache Zeichenfolge angezeigt.                                           |\n| Mehrfachauswahl | `\"repo_property_regions\": \"us-east-1,eu-west-1\"` | Mehrere ausgewählte Werte werden mit einer einzelnen durch Trennzeichen getrennten Zeichenfolge verknüpft. |\n| True/false      | `\"repo_property_pci_compliant\": \"true\"`          | Die Booleschen Werte werden als Zeichenfolge `\"true\"` oder `\"false\"` angezeigt.                            |\n\n#### Darstellung von Mehrfachauswahlwerten\n\nWenn ein Repository eine benutzerdefinierte Mehrfachauswahleigenschaft mit mehreren ausgewählten Werten aufweist, werden die Werte in eine einzelne durch Trennzeichen getrennte Zeichenfolge im OIDC-Token verknüpft. Wenn z. B. ein Repository eine `regions` Eigenschaft mit den Werten `us-east-1` und `eu-west-1` aufweist, wird der Anspruch wie folgt angezeigt:\n\n```json\n{\n  \"repo_property_regions\": \"us-east-1,eu-west-1\"\n} \n```\n\nVerwenden Sie beim Konfigurieren von Vertrauensrichtlinien in Ihrem Cloud-Provider den Zeichenfolgeabgleich oder Contains-Überprüfungen, um Mehrfachauswahlansprüche auszuwerten.\n\n#### Voraussetzungen für das Einschließen von benutzerdefinierten Eigenschaften\n\n* Benutzerdefinierte Eigenschaften müssen bereits auf der Organisation- oder Unternehmensebene definiert werden. Weitere Informationen finden Sie unter [Verwalten von benutzerdefinierten Eigenschaften für Repositorys in Ihrer Organisation](/de/organizations/managing-organization-settings/managing-custom-properties-for-repositories-in-your-organization).\n* Sie müssen ein Organisationsadministrator oder Unternehmensadministrator sein.\n* Nachdem Sie der OIDC-Konfiguration eine benutzerdefinierte Eigenschaft hinzugefügt haben, enthalten alle Repositorys in der Organisation oder im Unternehmen, die einen Wert für diese Eigenschaft festgelegt haben, sie automatisch in ihre OIDC-Token ein.\n\n#### Hinzufügen einer benutzerdefinierten Eigenschaft zu OIDC-Tokenansprüchen\n\nSie können mithilfe der Einstellungs-UI oder der REST-API verwalten, welche benutzerdefinierten Eigenschaften in OIDC-Token enthalten sind.\n\n* **Verwenden der Einstellungs-UI:**\n\n  Navigieren Sie zu den Aktionen-OIDC-Einstellungen Ihrer Organisation oder Ihres Unternehmens, um anzuzeigen und zu konfigurieren, welche benutzerdefinierten Eigenschaften in OIDC-Token enthalten sind.\n\n* **Mithilfe der REST API:**\n\n  Um den OIDC-Tokenansprüchen Ihrer Organisation eine benutzerdefinierte Eigenschaft hinzuzufügen, senden Sie eine `POST` Anforderung an den entsprechenden OIDC-Endpunkt für benutzerdefinierte Eigenschaften. Zum Beispiel:\n\n  * Für eine Organisation: `POST /orgs/{org}/actions/oidc/customization/properties/repo`\n  * Für ein Unternehmen: `POST /enterprises/{enterprise}/actions/oidc/customization/properties/repo` Anforderungsparameter und vollständige Details finden Sie in der REST-API-Dokumentation zum Verwalten von benutzerdefinierten OIDC-Eigenschaften: [REST-API-Endpunkte für GitHub Actions OIDC](/de/rest/actions/oidc).\n\n#### Beispieltoken mit benutzerdefinierten Eigenschaften\n\nNachdem der OIDC-Konfiguration eine benutzerdefinierte Eigenschaft hinzugefügt wurde, enthalten Repositorys mit einem Wert, der für diese Eigenschaft festgelegt ist, sie in ihre Token ein. Im folgenden Beispiel sind zwei benutzerdefinierte Eigenschaften (`business_unit` und `workspace_id`) im Token enthalten:\n\n```json\n{\n  \"sub\": \"repo:my-org/my-repo:ref:refs/heads/main\",\n  \"aud\": \"https://github.com/my-org\",\n  \"repository\": \"my-org/my-repo\",\n  \"repo_property_business_unit\": \"payments\",\n  \"repo_property_workspace_id\": \"ws-abc123\"\n}\n```\n\nSie können diese `repo_property_*` Ansprüche als Bedingungen in der Vertrauensrichtlinie Ihres Cloudanbieters verwenden. Ein Beispiel finden Sie unter [Beispiel: Filtern nach einer benutzerdefinierten Repositoryeigenschaft](#example-filtering-on-a-repository-custom-property).\n\n### Anpassen der Subjektansprüche für eine Organisation oder ein Repository\n\nUm Sicherheit, Compliance und Standardisierung zu verbessern, kannst du die Standardansprüche an deine erforderlichen Zugriffsbedingungen anpassen. Wenn dein Cloudanbieter Bedingungen für Antragstelleransprüche unterstützt, kannst du eine Bedingung erstellen, die überprüft, ob der `sub`-Wert dem Pfad des wiederverwendbaren Workflows entspricht, z. B. `\"job_workflow_ref:octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main\"`. Das genaue Format variiert je nach OIDC-Konfiguration deines Cloudanbieters. Um die Abgleichsbedingung auf GitHub zu konfigurieren, können Sie die REST-API verwenden, um festzulegen, dass der `sub`-Anspruch immer einen bestimmten benutzerdefinierten Anspruch enthalten muss, wie zum Beispiel `job_workflow_ref`. Du kannst mithilfe der REST-API eine Anpassungsvorlage auf den OIDC-Antragstelleranspruch anwenden. So kannst du beispielsweise festlegen, dass der `sub`-Anspruch innerhalb des OIDC-Tokens immer einen bestimmten benutzerdefinierten Anspruch (wie z. B. `job_workflow_ref`) enthalten muss. Weitere Informationen finden Sie unter [REST-API-Endpunkte für GitHub Actions OIDC](/de/rest/actions/oidc).\n\n> \\[!NOTE]\n> Wenn die Organisationsvorlage angewendet wird, wirkt sie sich nicht auf Workflows aus, die bereits OIDC nutzen, es sei denn, für das zugehörige Repository sind benutzerdefinierte Organisationsvorlagen aktiviert. Für alle vorhandenen und neuen Repositorys muss der Repositorybesitzer die REST-API auf Repositoryebene verwenden, um den Empfang dieser Konfiguration durch Einstellung von `use_default` auf `false` zu aktivieren. Alternativ können Repositorybesitzer\\*innen die REST-API verwenden, um eine andere Konfiguration speziell für das Repository anzuwenden. Weitere Informationen finden Sie unter [REST-API-Endpunkte für GitHub Actions OIDC](/de/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-a-repository).\n\nDas Anpassen der Ansprüche führt zu einem neuen Format für den gesamten `sub`-Anspruch, welches das vordefinierte `sub`-Standardformat in dem unter [Beispiele für Antragstelleransprüche](#example-subject-claims) beschriebenen Token ersetzt.\n\n> \\[!NOTE]\n> Der `sub`-Anspruch verwendet das gekürzte Formular `repo` (z. B `repo:ORG-NAME/REPO-NAME`) anstelle von `repository`, um auf das Repository zu verweisen.\n> Jeder `:` innerhalb des Kontextwerts wird durch `%3A` ersetzt.\n\nIn den folgenden Beispielvorlagen werden verschiedene Möglichkeiten zum Anpassen des Antragstelleranspruchs veranschaulicht. Um diese Einstellungen für GitHubzu konfigurieren, verwenden Administratoren die REST-API, um eine Liste von Ansprüchen anzugeben, die in den Antragstelleranspruch (`sub`) einbezogen werden müssen.\n\nUm diese Konfiguration anzuwenden, übermittle eine Anforderung an den API-Endpunkt, und schließe die erforderliche Konfiguration in den Anforderungstext ein. Informationen zu Organisationen findest du unter [REST-API-Endpunkte für GitHub Actions OIDC](/de/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-an-organization) und Informationen zu Repositorys unter [REST-API-Endpunkte für GitHub Actions OIDC](/de/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-a-repository).\n\nUm deine Antragstelleransprüche anzupassen, solltest du zuerst eine Vergleichsbedingung in der OIDC-Konfiguration deines Cloudanbieters erstellen, bevor du die Konfiguration mithilfe der REST-API anpasst. Sobald die Konfiguration abgeschlossen ist, folgt bei jeder Ausführung eines neuen Auftrags das während dieses Auftrags generierte OIDC-Token der neuen Anpassungsvorlage. Wenn die Vergleichsbedingung vor der Ausführung des Auftrags nicht in der OIDC-Konfiguration des Cloudanbieters vorhanden ist, wird das generierte Token möglicherweise nicht vom Cloudanbieter akzeptiert, weil die Cloudbedingungen möglicherweise nicht synchronisiert wurden.\n\n#### Beispiel: Zulassen des Repositorys basierend auf Sichtbarkeit und Besitzer\n\nIn dieser Beispielvorlage kann der `sub`-Anspruch ein neues Format aufweisen, das `repository_owner` und `repository_visibility` verwendet:\n\n```json\n{\n   \"include_claim_keys\": [\n       \"repository_owner\",\n       \"repository_visibility\"\n   ]\n}\n```\n\nKonfiguriere in der OIDC-Konfiguration deines Cloudanbieters die `sub`-Bedingung, um anzugeben, dass Ansprüche bestimmte Werte für `repository_owner` und `repository_visibility` aufweisen müssen. Beispiel: `\"sub\": \"repository_owner:monalisa:repository_visibility:private\"` Mit dem Ansatz kannst du den Cloudrollenzugriff auf private Repositorys innerhalb einer Organisation oder eines Unternehmens beschränken.\n\n#### Beispiel: Zulassen des Zugriffs auf alle Repositorys mit einem bestimmten Besitzer\n\nDurch diese Beispielvorlage kann der `sub`-Anspruch ein neues Format nur mit dem Wert von `repository_owner` aufweisen.\n\nUm diese Konfiguration anzuwenden, übermittle eine Anforderung an den API-Endpunkt, und schließe die erforderliche Konfiguration in den Anforderungstext ein. Informationen zu Organisationen findest du unter [REST-API-Endpunkte für GitHub Actions OIDC](/de/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-an-organization) und Informationen zu Repositorys unter [REST-API-Endpunkte für GitHub Actions OIDC](/de/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-a-repository).\n\n```json\n{\n   \"include_claim_keys\": [\n       \"repository_owner\"\n   ]\n}\n\n```\n\nKonfiguriere in der OIDC-Konfiguration deines Cloudanbieters die `sub`-Bedingung, um anzugeben, dass Ansprüche einen bestimmten Wert für `repository_owner` aufweisen müssen. Beispiel: `\"sub\": \"repository_owner:monalisa\"`\n\n#### Beispiel: Erfordern eines wiederverwendbaren Workflows\n\nIn dieser Beispielvorlage kann der `sub`-Anspruch ein neues Format aufweisen, das den Wert des `job_workflow_ref`-Anspruchs enthält. Dadurch kann ein Unternehmen wiederverwendbare Workflows verwenden, um konsistente Bereitstellungen in allen eigenen Organisationen und Repositorys zu erzwingen.\n\nUm diese Konfiguration anzuwenden, übermittle eine Anforderung an den API-Endpunkt, und schließe die erforderliche Konfiguration in den Anforderungstext ein. Informationen zu Organisationen findest du unter [REST-API-Endpunkte für GitHub Actions OIDC](/de/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-an-organization) und Informationen zu Repositorys unter [REST-API-Endpunkte für GitHub Actions OIDC](/de/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-a-repository).\n\n```json\n  {\n     \"include_claim_keys\": [\n         \"job_workflow_ref\"\n     ]\n  }\n```\n\nKonfiguriere in der OIDC-Konfiguration deines Cloudanbieters die `sub`-Bedingung, um anzugeben, dass Ansprüche einen bestimmten Wert für `job_workflow_ref` aufweisen müssen. Beispiel: `\"sub\": \"job_workflow_ref:octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main\"`\n\n#### Beispiel: Anfordern eines wiederverwendbaren Workflows und anderer Forderungen\n\nDie folgende Beispielvorlage kombiniert die Anforderung eines bestimmten wiederverwendbaren Workflows mit zusätzlichen Ansprüchen.\n\nUm diese Konfiguration anzuwenden, übermittle eine Anforderung an den API-Endpunkt, und schließe die erforderliche Konfiguration in den Anforderungstext ein. Informationen zu Organisationen findest du unter [REST-API-Endpunkte für GitHub Actions OIDC](/de/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-an-organization) und Informationen zu Repositorys unter [REST-API-Endpunkte für GitHub Actions OIDC](/de/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-a-repository).\n\nIn diesem Beispiel wird auch veranschaulicht, wie `\"context\"` zum Definieren deiner Bedingungen verwendet werden kann. Dies ist der Teil, der dem Repository im `sub`-Standardformat folgt. Wenn der Auftrag beispielsweise auf eine Umgebung verweist, enthält der Kontext Folgendes: `environment:ENVIRONMENT-NAME`.\n\n```json\n{\n   \"include_claim_keys\": [\n       \"repo\",\n       \"context\",\n       \"job_workflow_ref\"\n   ]\n}\n```\n\nKonfiguriere in der OIDC-Konfiguration deines Cloudanbieters die `sub`-Bedingung, um anzugeben, dass Ansprüche bestimmte Werte für `repo`, `context` und `job_workflow_ref` aufweisen müssen.\n\nDiese Anpassungsvorlage erfordert, dass `sub` das folgende Format verwendet: `repo:ORG-NAME/REPO-NAME:environment:ENVIRONMENT-NAME:job_workflow_ref:REUSABLE-WORKFLOW-PATH`.\nBeispiel: `\"sub\": \"repo:octo-org/octo-repo:environment:prod:job_workflow_ref:octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main\"`\n\n#### Beispiel: Gewähren des Zugriffs auf ein bestimmtes Repository\n\nIn dieser Beispielvorlage kannst du für alle Branches/Tags und Umgebungen cloudbasierten Zugriff auf alle Workflows in einem bestimmten Repository gewähren.\n\nUm diese Konfiguration anzuwenden, übermittle eine Anforderung an den API-Endpunkt, und schließe die erforderliche Konfiguration in den Anforderungstext ein. Informationen zu Organisationen findest du unter [REST-API-Endpunkte für GitHub Actions OIDC](/de/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-an-organization) und Informationen zu Repositorys unter [REST-API-Endpunkte für GitHub Actions OIDC](/de/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-a-repository).\n\n```json\n{\n   \"include_claim_keys\": [\n       \"repo\"\n   ]\n}\n```\n\nKonfiguriere in der OIDC-Konfiguration deines Cloudanbieters die `sub`-Bedingung, um einen `repo`-Anspruch zu verlangen, der dem erforderlichen Wert entspricht.\n\n#### Beispiel: Verwenden systemgenerierter GUIDs\n\nDiese Beispielvorlage ermöglicht vorhersagbare OIDC-Ansprüche mit systemgenerierten GUIDs, die bei der Umbenennung von Entitäten (z. B. beim Umbenennen eines Repositorys) unverändert bleiben.\n\nUm diese Konfiguration anzuwenden, übermittle eine Anforderung an den API-Endpunkt, und schließe die erforderliche Konfiguration in den Anforderungstext ein. Informationen zu Organisationen findest du unter [REST-API-Endpunkte für GitHub Actions OIDC](/de/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-an-organization) und Informationen zu Repositorys unter [REST-API-Endpunkte für GitHub Actions OIDC](/de/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-a-repository).\n\n```json\n  {\n     \"include_claim_keys\": [\n         \"repository_id\"\n     ]\n  }\n```\n\nKonfiguriere in der OIDC-Konfiguration deines Cloudanbieters die `sub`-Bedingung, um einen `repository_id`-Anspruch zu verlangen, der dem erforderlichen Wert entspricht.\n\noder:\n\n```json\n{\n   \"include_claim_keys\": [\n       \"repository_owner_id\"\n   ]\n}\n```\n\nKonfiguriere in der OIDC-Konfiguration deines Cloudanbieters die `sub`-Bedingung, um einen `repository_owner_id`-Anspruch zu verlangen, der dem erforderlichen Wert entspricht.\n\n#### Beispiel: Kontextwert mit `:`\n\nIn diesem Beispiel wird veranschaulicht, wie mit einem Kontextwert mit einem `:`-Zeichen umgegangen wird. Dies ist der Fall, wenn der Auftrag beispielsweise auf eine Umgebung namens `production:eastus` verweist.\n\nUm diese Konfiguration anzuwenden, übermittle eine Anforderung an den API-Endpunkt, und schließe die erforderliche Konfiguration in den Anforderungstext ein. Informationen zu Organisationen findest du unter [REST-API-Endpunkte für GitHub Actions OIDC](/de/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-an-organization) und Informationen zu Repositorys unter [REST-API-Endpunkte für GitHub Actions OIDC](/de/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-a-repository).\n\n```json\n{\n   \"include_claim_keys\": [\n       \"environment\",\n       \"repository_owner\"\n   ]\n}\n```\n\nKonfiguriere in der OIDC-Konfiguration deines Cloudanbieters die `sub`-Bedingung, um anzugeben, dass Ansprüche einen bestimmten Wert für `environment` und `repository_owner` aufweisen müssen. Beispiel: `\"sub\": \"environment:production%3Aeastus:repository_owner:octo-org\"`\n\n#### Beispiel: Filtern nach einer benutzerdefinierten Repositoryeigenschaft\n\nDiese Beispielvorlage ermöglicht es dem `sub`-Anspruch, einen benutzerdefinierten Anspruch auf Repository-Eigenschaften einzuschließen. Benutzerdefinierte Eigenschaften in OIDC-Tokens erscheinen mit `repo_property_` im Token präfixiert, aber der `include_claim_keys` Wert verwendet den vollständigen Claim-Namen, wie er im Token angezeigt wird.\n\nUm diese Konfiguration anzuwenden, übermittle eine Anforderung an den API-Endpunkt, und schließe die erforderliche Konfiguration in den Anforderungstext ein. Informationen zu Organisationen findest du unter [REST-API-Endpunkte für GitHub Actions OIDC](/de/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-an-organization) und Informationen zu Repositorys unter [REST-API-Endpunkte für GitHub Actions OIDC](/de/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-a-repository).\n\n```json\n{\n   \"include_claim_keys\": [\n       \"repo_property_workspace_id\"\n   ]\n}\n```\n\nKonfiguriere in der OIDC-Konfiguration deines Cloudanbieters die `sub`-Bedingung, um anzugeben, dass Ansprüche einen bestimmten Wert für `repo_property_workspace_id` aufweisen müssen. Beispiel: `\"sub\": \"repo_property_workspace_id:ws-abc123\"`\n\n#### Zurücksetzen der Anpassungen von Organisationsvorlagen\n\nIn dieser Beispielvorlage werden die Antragstelleransprüche auf das Standardformat zurückgesetzt. Mit dieser Vorlage werden alle Anpassungsrichtlinien auf Organisationsebene außer Kraft gesetzt.\n\nUm diese Konfiguration anzuwenden, übermittle eine Anforderung an den API-Endpunkt, und schließe die erforderliche Konfiguration in den Anforderungstext ein. Informationen zu Organisationen findest du unter [REST-API-Endpunkte für GitHub Actions OIDC](/de/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-an-organization) und Informationen zu Repositorys unter [REST-API-Endpunkte für GitHub Actions OIDC](/de/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-a-repository).\n\n```json\n{\n   \"include_claim_keys\": [\n       \"repo\",\n       \"context\"\n   ]\n}\n```\n\nKonfiguriere in der OIDC-Konfiguration deines Cloudanbieters die `sub`-Bedingung, um anzugeben, dass Ansprüche bestimmte Werte für `repo` und `context` aufweisen müssen.\n\n#### Zurücksetzen der Anpassungen von Repositoryvorlagen\n\nFür alle Repositorys in einer Organisation können angepasste `sub`-Claim-Vorlagen (auf Organisations- und Repositoryebene) aktiviert oder deaktiviert werden.\n\nUm das Abonnement eines Repositorys zu kündigen und auf das `sub`-Standardanspruchsformat zurückzusetzen, muss ein Repositoryadministrator den REST-API-Endpunkt unter [REST-API-Endpunkte für GitHub Actions OIDC](/de/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-a-repository) verwenden.\n\nUm Repositorys zur Verwendung des standardmäßigen Anspruchsformats `sub` zu konfigurieren, verwenden Sie den `PUT /repos/{owner}/{repo}/actions/oidc/customization/sub`-REST-API-Endpunkt mit dem folgenden Anforderungstext.\n\n```json\n{\n   \"use_default\": true\n}\n```\n\n#### Beispiel: Konfigurieren eines Repositorys für die Verwendung einer Organisationsvorlage\n\nSobald eine Organisation eine angepasste `sub`-Claim-Vorlage erstellt hat, kann die Vorlage mithilfe der REST-API programmgesteuert auf Repositorys in der Organisation angewendet werden. Ein Repositoryadministrator kann das Repository so konfigurieren, dass es die vom Administrator der Organisation erstellte Vorlage verwendet.\n\nUm das Repository zur Verwendung der Organisationsvorlage zu konfigurieren, muss ein*e Repositoryadministrator*in den `PUT /repos/{owner}/{repo}/actions/oidc/customization/sub`-REST-API-Endpunkt mit folgendem Anforderungstext verwenden. Weitere Informationen finden Sie unter [REST-API-Endpunkte für GitHub Actions OIDC](/de/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-a-repository).\n\n```json\n{\n   \"use_default\": false\n}\n```\n\n## Fehlerbehebung Ihrer OIDC-Claims\n\nSie können die [`github/actions-oidc-debugger`](https://github.com/github/actions-oidc-debugger)-Aktion verwenden, um die Ansprüche zu visualisieren, die gesendet würden, bevor Sie mit einem Cloudanbieter integrieren. Diese Aktion fordert ein JWT an und zeigt die Ansprüche, die im JWT enthalten sind und von GitHub Actions kommen.\n\n## Workflowberechtigungen für das Anfordern des OIDC-Token\n\n### Erforderliche Berechtigung\n\n* Der Auftrag oder Workflow muss [`id-token: write`](/de/actions/reference/workflow-syntax-for-github-actions#permissions) die Berechtigung erteilenGitHub, damit der OIDC-Anbieter ein JSON Web Token (JWT) erstellen kann.\n\n  ```yaml\n  permissions:\n    id-token: write\n  ```\n\n* Ohne `id-token: write` kann das OIDC JWT ID-Token nicht angefordert werden. Diese Einstellung aktiviert nur das Abrufen und Festlegen des OIDC-Tokens. es gewährt keinen Schreibzugriff auf andere Ressourcen.\n\n### Festlegen von Berechtigungen\n\n* Um ein OIDC-Token für einen Workflow abzurufen, lege die Berechtigung auf Workflowebene fest:\n\n  ```yaml\n  permissions:\n    id-token: write # This is required for requesting the JWT\n    contents: read # This is required for actions/checkout\n  ```\n\n* Um ein OIDC-Token für einen einzelnen Auftrag abzurufen, lege die Berechtigung innerhalb dieses Auftrags fest:\n\n  ```yaml\n  permissions:\n    id-token: write # This is required for requesting the JWT\n  ```\n\n* Je nach Workflowanforderungen sind möglicherweise zusätzliche Berechtigungen erforderlich.\n\n### Wiederverwendbare Workflows\n\n* Für wiederverwendbare Workflows, die sich im Besitz desselben Benutzers, derselben Organisation oder desselben Unternehmens wie der Aufrufer befinden, kann aus dem Kontext des Aufrufers auf das im wiederverwendbaren Workflow generierte OIDC-Token zugegriffen werden.\n* Lege für wiederverwendbare Workflows außerhalb deines Unternehmens oder deiner Organisation die Einstellung `permissions` für `id-token` auf `write` explizit auf Anruferworkflow- oder Auftragsebene fest. Dadurch wird sichergestellt, dass das OIDC-Token nur für beabsichtigte Aufruferworkflows verfügbar ist.\n\n## Methoden zum Anfordern des OIDC-Tokens\n\nBenutzerdefinierte Aktionen können das OIDC-Token wie folgt anfordern:\n\n* Die `getIDToken()`-Methode aus dem Toolkit für Aktionen Weitere Informationen findest du unter [OIDC Token](https://www.npmjs.com/package/@actions/core/v/1.6.0#oidc-token) in der Dokumentation für das npm-Paket.\n* Die folgenden Umgebungsvariablen auf dem Runner\n\n  | Variable                         | BESCHREIBUNG                                       |\n  | -------------------------------- | -------------------------------------------------- |\n  | `ACTIONS_ID_TOKEN_REQUEST_URL`   | Die URL für GitHub des OIDC-Anbieters.             |\n  | `ACTIONS_ID_TOKEN_REQUEST_TOKEN` | Bearer-Token für die Anfrage an den OIDC-Anbieter. |\n\n  Zum Beispiel:\n\n  ```shell copy\n  curl -H \"Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN\" \"$ACTIONS_ID_TOKEN_REQUEST_URL&audience=api://AzureADTokenExchange\"\n  ```"}