WIF mit Okta verwenden

Okta kann als Workload-Identitätsanbieter fungieren, indem es OIDC-Access-Tokens an eine Service-Anwendung über den OAuth 2.0 client_credentials-Grant ausstellt. Dein Workload authentifiziert sich bei Okta (typischerweise mit private_key_jwt, sodass kein gemeinsames Geheimnis gespeichert wird), erhält ein signiertes „JSON Web Token" (JSON-Web-Token), oder JWT, und tauscht dieses JWT bei Anthropic gegen ein kurzlebiges Access-Token ein.

Die Issuer-URL des Okta-Autorisierungsservers hat die Form https://<your-domain>.okta.com/oauth2/<auth-server-id>. Wenn du den integrierten Standardserver verwendest, lautet der Pfad /oauth2/default.

Es gibt viele Möglichkeiten, Okta zu konfigurieren und sich dort zu authentifizieren, die außerhalb des Umfangs dieser Dokumentation liegen. Stelle sicher, dass deine Konfiguration und Authentifizierungsmechanismen den Richtlinien und Sicherheitspraktiken deines Unternehmens entsprechen.

Voraussetzungen

• Vertrautheit mit WIF-Konzepten: Service-Accounts, Federation-Issuer und Federation-Regeln.
• Eine Okta-Organisation mit aktiviertem API Access Management (erforderlich für benutzerdefinierte Autorisierungsserver).
• Berechtigung zum Erstellen von Service-Accounts, Federation-Issuern und Federation-Regeln in der Claude Console für deine Anthropic-Organisation.
• Ein Workload, der ein Token vom Okta-Endpunkt /v1/token anfordern und api.anthropic.com erreichen kann.

Okta konfigurieren

Auf hoher Ebene musst du:

1. Eine Okta-Service-Anwendung erstellen.
2. Deinen Standard-Autorisierungsserver konfigurieren (oder einen neuen benutzerdefinierten Autorisierungsserver erstellen) mit einer Audience, einem Scope, einer Access-Policy und allen benutzerdefinierten Claims, auf die du matchen möchtest.

Die genaue Navigation hängt von deiner Okta-Org-Konfiguration und der Version der Admin-Konsole ab. Die nummerierten Schritte unten führen durch einen gängigen Pfad:

1. Erstelle eine Service-App-Integration. Erstelle in der Okta Admin Console eine neue App-Integration vom Typ API Services (OIDC, Machine-to-Machine). Notiere die generierte Client ID.
2. Konfiguriere die Client-Authentifizierung. Für ein schlüsselloses Setup wähle Public key / Private key (private_key_jwt) und registriere den öffentlichen JWK deines Workloads. Alternativ kannst du ein Client-Secret verwenden, wenn deine Umgebung eines sicher speichern kann. Für das folgende Beispiel musst du möglicherweise die DPoP-Anforderung für die Anwendung deaktivieren; stelle sicher, dass dein Produktions-Setup den Sicherheitsanforderungen deiner Organisation entspricht.
3. Lege die Audience fest. Setze auf deinem benutzerdefinierten Autorisierungsserver die Audience auf https://api.anthropic.com, damit ausgestellte Access-Tokens diesen aud-Claim enthalten. Anthropic validiert aud gegen diesen festen Wert.
4. Gewähre einen Scope. Stelle auf deinem benutzerdefinierten Autorisierungsserver sicher, dass mindestens ein Scope existiert, den die Service-App anfordern darf (zum Beispiel anthropic.access). Okta lehnt client_credentials-Anfragen ab, die keinen gewährten Scope enthalten.
5. Erstelle eine Access-Policy. Erstelle auf deinem benutzerdefinierten Autorisierungsserver eine Access-Policy mit mindestens einer Regel, die deiner Service-App erlaubt, den in Schritt 4 gewährten Scope anzufordern.
6. (Optional) Füge benutzerdefinierte Claims hinzu. Wenn du auf etwas anderes als die Client-ID matchen möchtest, füge im Claims-Tab deines Autorisierungsservers einen Claim zum Access-Token hinzu.

Für eine Service-App, die client_credentials verwendet, setzt Okta den sub-Claim des ausgestellten Access-Tokens auf die Client ID der Anwendung und iss auf die Issuer-URL des Autorisierungsservers.

Anthropic konfigurieren

Folge der Setup-Anleitung, um einen Federation-Issuer zu registrieren, einen Anthropic-Service-Account zu erstellen und eine Federation-Regel in der Claude Console anzulegen. Verwende diese Okta-spezifischen Werte.

Federation-Issuer: Verwende die URL deines benutzerdefinierten Okta-Autorisierungsservers und den Discovery-Modus. Anthropic liest Oktas .well-known/openid-configuration-Discovery-Dokument und ruft das JWKS von der dort angegebenen jwks_uri ab.

{
  "name": "okta-prod",
  "issuer_url": "https://acme.okta.com/oauth2/aus1a2b3c4d5e6f7g8h9",
  "jwks_source": "discovery"
}

Federation-Regel: Matche auf den Okta-sub-Claim, der die Client-ID der Service-App ist. Wenn du benutzerdefinierte Claims in Okta definiert hast, kannst du stattdessen mit der claims-Map oder einer CEL-condition auf diese matchen.

{
  "name": "okta-pipeline",
  "issuer_id": "fdis_...",
  "match": {
    "subject_prefix": "0oa1b2c3d4e5f6g7h8i9",
    "audience": "https://api.anthropic.com"
  },
  "target": { "type": "service_account", "service_account_id": "svac_..." },
  "workspace_id": "wrkspc_...",
  "oauth_scope": "workspace:developer",
  "token_lifetime_seconds": 600
}

Ein Token abrufen und die Claude API aufrufen

Im Gegensatz zu plattformnativen Anbietern (AWS, Google Cloud, Kubernetes), die ein Token innerhalb der Laufzeitumgebung des Workloads verfügbar machen (über eine projizierte Datei oder einen lokalen Metadaten-Endpunkt), tut Okta dies nicht. Dein Workload muss den Token-Endpunkt von Okta aufrufen, um ein JWT zu erhalten, und dieses JWT dann als Identitäts-Token an das Anthropic-SDK übergeben.

import os
import httpx
import anthropic
from anthropic import WorkloadIdentityCredentials


def fetch_okta_token() -> str:
    response = httpx.post(
        f"{os.environ['OKTA_ISSUER']}/v1/token",
        data={
            "grant_type": "client_credentials",
            "scope": "anthropic.access",
            "client_assertion_type": "urn:ietf:params:oauth:client-assertion-type:jwt-bearer",
            # Erstelle das RFC 7523 client_assertion JWT, signiert mit dem privaten Schlüssel deiner Okta-App
            "client_assertion": build_signed_client_assertion(),
        },
    )
    response.raise_for_status()
    return response.json()["access_token"]


client = anthropic.Anthropic(
    credentials=WorkloadIdentityCredentials(
        identity_token_provider=fetch_okta_token,
        federation_rule_id=os.environ["ANTHROPIC_FEDERATION_RULE_ID"],
        organization_id=os.environ["ANTHROPIC_ORGANIZATION_ID"],
        service_account_id=os.environ["ANTHROPIC_SERVICE_ACCOUNT_ID"],
        workspace_id=os.environ.get("ANTHROPIC_WORKSPACE_ID"),
    ),
)

message = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello, Claude"}],
)
print(message.content[0].text)

Jeder SDK-Tab zeigt das Callable-Muster: Das Anthropic-SDK ruft deinen Identitäts-Token-Provider erneut auf, sobald das Anthropic-Access-Token sich dem Ablauf nähert. Dein Okta-Fetcher sollte daher bei jedem Aufruf ein frisches Token zurückgeben, anstatt eines unbegrenzt zu cachen. Die ant-CLI liest ANTHROPIC_IDENTITY_TOKEN_FILE bei jedem Austausch neu ein, aktualisiere diese Datei also per Timer für langlaufende Shells.

Das Setup überprüfen

Ein erfolgreicher Austausch gibt ein access_token zurück, das mit sk-ant-oat01- beginnt, sowie einen expires_in-Wert in Sekunden. Bei 400 invalid_grant siehe Fehlerbehebung bei einem fehlgeschlagenen Austausch; die häufigste Okta-seitige Ursache ist eine nicht übereinstimmende issuer_url (sie muss den Pfad /oauth2/<auth-server-id> enthalten; der Okta-Org-Autorisierungsserver ist nicht verwendbar).

Deine Regel eingrenzen

Beschränke den match-Block der Regel auf den engsten Scope, der zu deinem Anwendungsfall passt:

• Pinne die exakte Client-ID: Setze subject_prefix auf die vollständige Client-ID der Service-App ohne abschließendes *.
• Pinne die Audience: Matche den audience-Wert, den du auf dem Autorisierungsserver konfiguriert hast, damit Tokens, die für eine andere Audience ausgestellt wurden, abgelehnt werden.
• Matche auf benutzerdefinierte Claims: Für eine feinere Eingrenzung füge Claims im Claims-Tab des Autorisierungsservers hinzu und matche sie mit der claims-Map der Regel oder einer CEL-condition.
• Verwende eine Regel pro Service-App: Erstelle für jede Service-App eine separate Federation-Regel, anstatt eine Regel über mehrere Apps hinweg zu teilen.

Nächste Schritte

• Sieh dir die WIF-Referenz für die vollständige Reihenfolge der Credential-Auflösung und Profilkonfiguration an.
• Siehe die WIF-Referenz, um mit CEL-Ausdrücken auf benutzerdefinierte Okta-Claims zu matchen.