Claude Platform Docs
AdministrationFournisseurs d'identité

Utiliser WIF avec Okta

Fédérez les identités d'applications de service Okta vers la Claude API avec Workload Identity Federation.

Okta peut agir en tant que fournisseur d'identité de charge de travail en émettant des jetons d'accès OIDC à une application de service via le flux OAuth 2.0 client_credentials. Votre charge de travail s'authentifie auprès d'Okta (généralement avec private_key_jwt, de sorte qu'aucun secret partagé n'est stocké), reçoit un « JSON Web Token » (jeton web JSON) signé, ou JWT, et échange ce JWT auprès d'Anthropic contre un jeton d'accès de courte durée.

L'URL d'émetteur du serveur d'autorisation Okta prend la forme https://<your-domain>.okta.com/oauth2/<auth-server-id>. Si vous utilisez le serveur par défaut intégré, le chemin est /oauth2/default.

Il existe de nombreuses façons de configurer Okta et de s'y authentifier qui sortent du cadre de cette documentation. Assurez-vous que vos mécanismes de configuration et d'authentification respectent les directives et les pratiques de sécurité de votre entreprise.

Prérequis

  • Une familiarité avec les concepts WIF : comptes de service, émetteurs de fédération et règles de fédération.
  • Une organisation Okta avec API Access Management activé (requis pour les serveurs d'autorisation personnalisés).
  • L'autorisation de créer des comptes de service, des émetteurs de fédération et des règles de fédération dans la Claude Console pour votre organisation Anthropic.
  • Une charge de travail capable de demander un jeton au point de terminaison /v1/token d'Okta et d'atteindre api.anthropic.com.

Configurer Okta

Dans les grandes lignes, vous devez :

  1. Créer une application de service Okta.
  2. Configurer votre serveur d'autorisation par défaut (ou créer un nouveau serveur d'autorisation personnalisé) avec une audience, une portée (scope), une politique d'accès et toutes les revendications (claims) personnalisées sur lesquelles vous souhaitez effectuer une correspondance.

La navigation exacte dépend de la configuration de votre organisation Okta et de la version de la console d'administration. Les étapes numérotées suivantes décrivent un parcours courant :

  1. Créez une intégration d'application de service. Dans la console d'administration Okta, créez une nouvelle intégration d'application de type API Services (OIDC, machine à machine). Notez le Client ID généré.
  2. Configurez l'authentification du client. Pour une configuration sans clé, choisissez Public key / Private key (private_key_jwt) et enregistrez la JWK publique de votre charge de travail. Vous pouvez également utiliser un secret client si votre environnement peut en stocker un de manière sécurisée. Pour l'exemple suivant, vous devrez peut-être désactiver l'exigence DPoP sur l'application ; assurez-vous que votre configuration de production respecte les exigences de sécurité de votre organisation.
  3. Définissez l'audience. Sur votre serveur d'autorisation personnalisé, définissez l'audience sur https://api.anthropic.com afin que les jetons d'accès émis portent cette revendication aud. Anthropic valide aud par rapport à cette valeur fixe.
  4. Accordez une portée. Sur votre serveur d'autorisation personnalisé, assurez-vous qu'il existe au moins une portée que l'application de service est autorisée à demander (par exemple, anthropic.access). Okta rejette les requêtes client_credentials qui n'incluent pas de portée accordée.
  5. Créez une politique d'accès. Sur votre serveur d'autorisation personnalisé, créez une politique d'accès comportant au moins une règle qui autorise votre application de service à demander la portée accordée à l'étape 4.
  6. (Facultatif) Ajoutez des revendications personnalisées. Si vous souhaitez effectuer une correspondance sur autre chose que l'identifiant client, ajoutez une revendication au jeton d'accès dans l'onglet Claims de votre serveur d'autorisation.

Pour une application de service utilisant client_credentials, Okta définit la revendication sub du jeton d'accès émis sur le Client ID de l'application, et iss sur l'URL d'émetteur du serveur d'autorisation.

Configurer Anthropic

Dans la Claude Console, ouvrez Settings → Workload identity, cliquez sur Connect workload et sélectionnez Custom OIDC. L'assistant vous guide dans l'enregistrement de l'émetteur, la création d'un compte de service et la création d'une règle de fédération.

L'assistant crée ces ressources pour vous. Utilisez les valeurs suivantes, que vous les saisissiez dans l'assistant ou que vous les envoyiez à l'Admin API :

Émetteur de fédération : utilisez l'URL de votre serveur d'autorisation personnalisé Okta et le mode de découverte. Anthropic lit le document de découverte .well-known/openid-configuration d'Okta et récupère le JWKS à partir du jwks_uri qu'il annonce.

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

Règle de fédération : effectuez la correspondance sur la revendication sub d'Okta, qui correspond au Client ID de l'application de service. Si vous avez défini des revendications personnalisées dans Okta, vous pouvez effectuer la correspondance sur celles-ci à la place avec la map claims ou une condition CEL.

{
  "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
}

Obtenir un jeton et appeler la Claude API

Contrairement aux fournisseurs natifs de plateforme (AWS, Google Cloud, Kubernetes), qui mettent un jeton à disposition dans l'environnement d'exécution de la charge de travail (via un fichier projeté ou un point de terminaison de métadonnées local), Okta ne le fait pas. Votre charge de travail doit appeler le point de terminaison de jeton d'Okta pour obtenir un JWT, puis transmettre ce JWT au SDK Anthropic en tant que jeton d'identité.

import os
import httpx2
import anthropic
from anthropic import WorkloadIdentityCredentials


def fetch_okta_token() -> str:
    response = httpx2.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",
            # Construire le JWT client_assertion RFC 7523 signé avec la clé privée de votre application Okta
            "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-opus-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello, Claude"}],
)
print(next(block.text for block in message.content if block.type == "text"))

Chaque onglet de SDK illustre le modèle basé sur un appelable : le SDK Anthropic appelle à nouveau votre fournisseur de jeton d'identité chaque fois que le jeton d'accès Anthropic approche de son expiration ; votre récupérateur Okta doit donc renvoyer un jeton frais à chaque appel plutôt que d'en mettre un en cache indéfiniment. La CLI ant relit ANTHROPIC_IDENTITY_TOKEN_FILE à chaque échange ; actualisez donc ce fichier à intervalles réguliers pour les shells de longue durée.

Vérifier la configuration

Un échange réussi renvoie un access_token commençant par sk-ant-oat01- et une valeur expires_in en secondes. Si l'échange échoue avec la réponse opaque 401 authentication_error (message Authentication failed), consultez la page d'historique d'authentification pour connaître le motif du refus et reportez-vous à Dépanner un échange en échec ; la cause la plus fréquente côté Okta est une non-concordance de issuer_url (elle doit inclure le chemin /oauth2/<auth-server-id> ; le serveur d'autorisation d'organisation Okta n'est pas utilisable).

Restreindre la portée de votre règle

Verrouillez le bloc match de la règle sur la portée la plus étroite adaptée à votre cas d'usage :

  • Épinglez le Client ID exact : définissez subject_prefix sur le Client ID complet de l'application de service, sans * final.
  • Épinglez l'audience : faites correspondre la valeur audience que vous avez configurée sur le serveur d'autorisation afin que les jetons émis pour une audience différente soient rejetés.
  • Effectuez la correspondance sur des revendications personnalisées : pour une restriction plus fine, ajoutez des revendications dans l'onglet Claims du serveur d'autorisation et faites-les correspondre avec la map claims de la règle ou une condition CEL.
  • Utilisez une règle par application de service : créez une règle de fédération distincte pour chaque application de service plutôt que de partager une seule règle entre plusieurs applications.

Étapes suivantes

  • Consultez la référence WIF pour connaître l'ordre complet de résolution des identifiants et la configuration des profils.
  • Consultez la référence WIF pour effectuer une correspondance sur des revendications Okta personnalisées avec des expressions CEL.

Was this page helpful?