Skip to main content
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.

​
So funktioniert es

  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.

​
Setup-Aktionen

Fügen Sie die passende Action zum Abschnitt initialize Ihres Environment-Blueprints hinzu:

​
Beispiel: AWS

Devin kann dann AWS-Befehle ohne gespeicherte Anmeldedaten ausführen:
Die vollständigen Voraussetzungen und Konfigurationsoptionen auf AWS-Seite finden Sie in der setup-aws-oidc-Dokumentation.

​
Beispiel: benutzerdefinierte Dienste

Verwenden Sie für eigene APIs und interne Dienste die Basis-CLI, um ein Token für jede von Ihrem Dienst akzeptierte Zielgruppe anzufordern:
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).

​
Token-Claims

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.

​
Sicherheitseigenschaften

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