Usa WIF con Okta

Okta puede actuar como un proveedor de identidad de cargas de trabajo emitiendo tokens de acceso OIDC a una aplicación de servicio a través del flujo client_credentials de OAuth 2.0. Tu carga de trabajo se autentica ante Okta (normalmente con private_key_jwt, por lo que no se almacena ningún secreto compartido), recibe un "JSON Web Token" (token web JSON), o JWT, firmado, e intercambia ese JWT con Anthropic por un token de acceso de corta duración.

La URL del emisor del servidor de autorización de Okta tiene la forma https://<your-domain>.okta.com/oauth2/<auth-server-id>. Si usas el servidor predeterminado integrado, la ruta es /oauth2/default.

Hay muchas formas de configurar y autenticarse ante Okta que están fuera del alcance de esta documentación. Asegúrate de que tus mecanismos de configuración y autenticación sigan las directrices y prácticas de seguridad de tu empresa.



Requisitos previos

• Familiaridad con los conceptos de WIF: cuentas de servicio, emisores de federación y reglas de federación.
• Una organización de Okta con API Access Management habilitado (requerido para servidores de autorización personalizados).
• Permiso para crear cuentas de servicio, emisores de federación y reglas de federación en la Claude Console para tu organización de Anthropic.
• Una carga de trabajo que pueda solicitar un token desde el endpoint /v1/token de Okta y alcanzar api.anthropic.com.



Configura Okta

A alto nivel necesitas:

1. Crear una aplicación de servicio de Okta.
2. Configurar tu servidor de autorización predeterminado (o crear un nuevo servidor de autorización personalizado) con una audiencia, un scope, una política de acceso y cualquier claim personalizado sobre el que quieras hacer coincidencias.

La navegación exacta depende de la configuración de tu organización de Okta y de la versión de la consola de administración. Los siguientes pasos numerados recorren una ruta común:

1. Crea una integración de aplicación de servicio. En la Okta Admin Console, crea una nueva integración de aplicación de tipo API Services (OIDC, máquina a máquina). Anota el Client ID generado.
2. Configura la autenticación del cliente. Para una configuración sin claves, elige Public key / Private key (private_key_jwt) y registra la JWK pública de tu carga de trabajo. Alternativamente, usa un secreto de cliente si tu entorno puede almacenar uno de forma segura. Para el siguiente ejemplo puede que necesites deshabilitar el requisito de DPoP en la aplicación; asegúrate de que tu configuración de producción cumpla con los requisitos de seguridad de tu organización.
3. Establece la audiencia. En tu servidor de autorización personalizado, establece la audiencia en https://api.anthropic.com para que los tokens de acceso emitidos lleven ese claim aud. Anthropic valida aud contra este valor fijo.
4. Otorga un scope. En tu servidor de autorización personalizado, asegúrate de que exista al menos un scope que la aplicación de servicio tenga permitido solicitar (por ejemplo, anthropic.access). Okta rechaza las solicitudes de client_credentials que no incluyan un scope otorgado.
5. Crea una política de acceso. En tu servidor de autorización personalizado, crea una política de acceso con al menos una regla que permita a tu aplicación de servicio solicitar el scope que otorgaste en el paso 4.
6. (Opcional) Agrega claims personalizados. Si quieres hacer coincidencias sobre algo distinto al client ID, agrega un claim al token de acceso en la pestaña Claims de tu servidor de autorización.

Para una aplicación de servicio que usa client_credentials, Okta establece el claim sub del token de acceso emitido con el Client ID de la aplicación, e iss con la URL del emisor del servidor de autorización.



Configura Anthropic

En la Claude Console, abre Settings → Workload identity, haz clic en Connect workload y selecciona Custom OIDC. El asistente te guía a través del registro del emisor, la creación de una cuenta de servicio y la creación de una regla de federación.

El asistente crea estos recursos por ti. Usa los siguientes valores, ya sea que los ingreses en el asistente o los envíes a la Admin API:

Emisor de federación: Usa la URL de tu servidor de autorización personalizado de Okta y el modo de descubrimiento. Anthropic lee el documento de descubrimiento .well-known/openid-configuration de Okta y obtiene el JWKS desde el jwks_uri que este anuncia.

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

Regla de federación: Haz coincidencias sobre el claim sub de Okta, que es el Client ID de la aplicación de servicio. Si definiste claims personalizados en Okta, puedes hacer coincidencias sobre ellos en su lugar con el mapa claims o una condition de 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
}



Adquiere un token y llama a la API de Claude

A diferencia de los proveedores nativos de plataforma (AWS, Google Cloud, Kubernetes), que ponen un token a disposición dentro del entorno de ejecución de la carga de trabajo (a través de un archivo proyectado o un endpoint de metadatos local), Okta no lo hace. Tu carga de trabajo debe llamar al endpoint de tokens de Okta para obtener un JWT y luego pasar ese JWT al SDK de Anthropic como el token de identidad.

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",
            # Construye el JWT client_assertion de RFC 7523 firmado con la clave privada de tu aplicación de 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"))

Cada pestaña del SDK muestra el patrón invocable: el SDK de Anthropic llama a tu proveedor de tokens de identidad nuevamente cada vez que el token de acceso de Anthropic se acerca a su expiración, por lo que tu recuperador de Okta debería devolver un token nuevo en cada llamada en lugar de almacenar uno en caché indefinidamente. La CLI ant vuelve a leer ANTHROPIC_IDENTITY_TOKEN_FILE en cada intercambio, así que actualiza ese archivo con un temporizador para shells de larga duración.



Verifica la configuración

Un intercambio exitoso devuelve un access_token que comienza con sk-ant-oat01- y un valor expires_in en segundos. Ante un 400 invalid_grant, consulta Solucionar problemas de un intercambio fallido; la causa más común del lado de Okta es una discrepancia en issuer_url (debe incluir la ruta /oauth2/<auth-server-id>; el servidor de autorización de la organización de Okta no es utilizable).



Delimita el alcance de tu regla

Restringe el bloque match de la regla al alcance más estrecho que se ajuste a tu caso de uso:

• Fija el Client ID exacto: Establece subject_prefix con el Client ID completo de la aplicación de servicio sin un * al final.
• Fija la audiencia: Haz coincidir el valor de audience que configuraste en el servidor de autorización para que los tokens emitidos para una audiencia diferente sean rechazados.
• Haz coincidencias sobre claims personalizados: Para un alcance más granular, agrega claims en la pestaña Claims del servidor de autorización y haz coincidencias con el mapa claims de la regla o una condition de CEL.
• Usa una regla por aplicación de servicio: Crea una regla de federación separada para cada aplicación de servicio en lugar de compartir una regla entre aplicaciones.



Próximos pasos

• Revisa la referencia de WIF para conocer el orden completo de resolución de credenciales y la configuración de perfiles.
• Consulta la referencia de WIF para hacer coincidencias sobre claims personalizados de Okta con expresiones CEL.