> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Cloud-Authentifizierung mit OIDC

> Gewähren Sie Devin über OpenID Connect kurzlebigen, schlüssellosen Zugriff auf Ihre Cloud-Dienste

Devin kann sich bei Cloud-Diensten über die Workload-Identity-Föderation von OpenID Connect (OIDC) statt mit langlebigen Anmeldedaten authentifizieren. Jede Devin-Sitzung erhält ein von Devin ausgestelltes, kurzlebiges Identitätstoken, das Ihr Cloud-Anbieter überprüft und gegen temporäre Anmeldedaten austauscht. In Devin müssen keine statischen API-Schlüssel oder Secrets gespeichert werden.

<div id="how-it-works">
  ## So funktioniert es
</div>

1. Jede Devin-Sitzung erhält automatisch ein kurzlebiges, von Devin signiertes **Identitätstoken**, das während der gesamten Sitzung erneuert wird.
2. Ihr Cloud-Anbieter überprüft das Token anhand des öffentlichen OIDC-Issuers von Devin und gewährt temporären Zugriff mit begrenztem Geltungsbereich.

Tokens identifizieren die Sitzung anhand von claims wie `org_id`, `devin_id` und `requesting_user_email`. So können Sie Vertrauensrichtlinien erstellen, die Ihrer Organisation oder bestimmten Sitzungen oder Nutzern Zugriff gewähren. Tokens laufen automatisch ab – es gibt nichts zu rotieren oder zu widerrufen.

<div id="setup-actions">
  ## Setup-Aktionen
</div>

Fügen Sie die passende Action zum Abschnitt `initialize` Ihres [Environment-Blueprints](/de/onboard-devin/environment/blueprints) hinzu:

| Action                                                                                  | Zweck                                                                                     |
| --------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| [`setup-aws-oidc`](https://github.com/CognitionAI/actions/tree/main/setup-aws-oidc)     | Authentifizierung für AWS CLI und SDK über IAM `AssumeRoleWithWebIdentity`                |
| [`setup-gcp-oidc`](https://github.com/CognitionAI/actions/tree/main/setup-gcp-oidc)     | Authentifizierung für gcloud und Google Cloud SDK über Workload Identity Federation       |
| [`setup-vault-oidc`](https://github.com/CognitionAI/actions/tree/main/setup-vault-oidc) | Authentifizierung für die HashiCorp Vault CLI über die JWT/OIDC-Authentifizierungsmethode |
| [`setup-jfrog-oidc`](https://github.com/CognitionAI/actions/tree/main/setup-jfrog-oidc) | Authentifizierung für die JFrog CLI über den OIDC-Token-Austausch von JFrog               |
| [`setup-devin-oidc`](https://github.com/CognitionAI/actions/tree/main/setup-devin-oidc) | Basis-CLI `devin-oidc` für Dienste, die Devin als Identity Provider vertrauen             |

<div id="example-aws">
  ### Beispiel: AWS
</div>

```yaml theme={null}
initialize:
  - uses: github.com/CognitionAI/actions/setup-aws-oidc@main
    with:
      role-arn: "arn:aws:iam::123456789012:role/devin-sessions"
      region: "us-east-1"
```

Devin kann dann AWS-Befehle ohne gespeicherte Anmeldedaten ausführen:

```bash theme={null}
aws sts get-caller-identity
```

Die vollständigen Voraussetzungen und Konfigurationsoptionen auf AWS-Seite finden Sie in der [`setup-aws-oidc`-Dokumentation](https://github.com/CognitionAI/actions/tree/main/setup-aws-oidc).

<div id="example-custom-services">
  ### Beispiel: benutzerdefinierte Dienste
</div>

Verwenden Sie für eigene APIs und interne Dienste die Basis-CLI, um ein Token für jede von Ihrem Dienst akzeptierte Zielgruppe anzufordern:

```bash theme={null}
devin-oidc token --audience my-api --subject-keys "org_id"
```

Konfigurieren Sie Ihren Service so, dass er dem OIDC-Issuer von Devin vertraut und Tokens anhand des veröffentlichten JWKS unter `/.well-known/jwks.json` überprüft. Der Issuer ist der Ursprung Ihrer Devin-Webapp – `https://app.devin.ai` bzw. bei Enterprise-Bereitstellungen Ihre eigene Domain (z. B. `https://yourdomain.devinenterprise.com`).

<div id="token-claims">
  ## Token-Claims
</div>

Token enthalten die folgenden Identitäts-Claims, auf die Sie in Vertrauensrichtlinien verweisen und die Sie zum Zusammensetzen des Token-Subjekts über `subject-keys` verwenden können. Das Subjekt wird aus `key:value`-Paaren der ausgewählten Claims erstellt — zum Beispiel erzeugt `--subject-keys "org_id"` (der Standardwert) ein Subjekt wie `org_id:a67b8de8-9483-4a9c-9662-51c3d2a45e88`.

| Claim                                          | Beschreibung                                            |
| ---------------------------------------------- | ------------------------------------------------------- |
| `org_id`                                       | Organisation, in der die Sitzung gestartet wurde        |
| `account_id`                                   | Account-ID (Enterprise- oder Einzelorganisationskunde)  |
| `devin_id`                                     | ID der Devin-Sitzung                                    |
| `devin_trigger`                                | Art des Sitzungsstarts (z. B. `webapp`, `slack`, `api`) |
| `requesting_user_id` / `requesting_user_email` | Nutzer, der die Sitzung gestartet hat                   |
| `service_user_id`                              | Service-Benutzer für über die API initiierte Sitzungen  |

<div id="security-properties">
  ## Sicherheitseigenschaften
</div>

* **Keine langlebigen Anmeldedaten**: Tokens sind kurzlebig und werden automatisch erneuert; nach Ende einer Sitzung muss nichts rotiert oder widerrufen werden.
* **Zugriff mit eingeschränktem Geltungsbereich**: Auf eine Zielgruppe beschränkte Tokens sind nur für den jeweiligen Dienst gültig, für den sie angefordert wurden. Ihre Vertrauensrichtlinien legen genau fest, welchen Identitäten Zugriff gewährt werden kann.
* **Nachvollziehbare Identität**: Tokens enthalten die Sitzung, die Organisation und den anfragenden Nutzer, sodass cloudseitige Audit-Logs jede Aktion einer bestimmten Devin-Sitzung zuordnen.

<Note>
  Enterprise-Bereitstellungen mit benutzerdefinierten Domains verfügen über einen dedizierten Signaturschlüssel pro Account. Der Token-Issuer ist Ihre benutzerdefinierte Devin-URL. Wenden Sie sich an Ihren Devin-Administrator oder den Cognition-Support, um Ihre Issuer-URL und Organisations-ID zu erhalten.
</Note>