Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Cette page rassemble les surfaces de configuration, les contraintes de validation et les correspondances d'erreurs pour Workload Identity Federation. Pour les guides de configuration pas à pas, consultez les guides des fournisseurs.
POST /v1/oauth/token accepte un corps JSON utilisant le grant jwt-bearer de la RFC 7523. Les SDK construisent cette requête pour vous à partir des variables d'environnement ; les exemples cURL de chaque guide de fournisseur montrent le corps brut.
| Champ | Requis | Description |
|---|---|---|
grant_type | Oui | Toujours urn:ietf:params:oauth:grant-type:jwt-bearer. |
assertion | Oui | Le JWT OIDC émis par votre fournisseur d'identité. |
federation_rule_id | Oui | ID étiqueté (fdrl_...) de la règle de fédération à évaluer. |
organization_id | Oui | UUID de votre organisation Anthropic. |
service_account_id | Oui | ID étiqueté (svac_...) du compte de service cible. |
workspace_id | Conditionnel | ID étiqueté (wrkspc_...) de l'espace de travail auquel limiter le jeton émis, ou le littéral default pour l'espace de travail par défaut de l'organisation. Requis lorsque la règle est activée pour plus d'un espace de travail. Lorsqu'il est omis, le serveur sélectionne le seul espace de travail activé de la règle. |
POST /v1/oauth/token renvoie une réponse de jeton OAuth 2.0 standard (RFC 6749 §5.1) :
| Champ | Type | Description |
|---|---|---|
access_token | string | Le jeton Anthropic de courte durée, préfixé sk-ant-oat01-.... Transmettez-le sous la forme Authorization: Bearer <token>. |
token_type | string | Toujours Bearer. |
expires_in | integer | Secondes avant l'expiration du jeton. |
scope | string | Le scope OAuth accordé par la règle correspondante. |
Le SDK lit ces variables pour effectuer un échange de jeton fédéré sans arguments de constructeur.
| Variable | Requis | Description | Exemple |
|---|---|---|---|
ANTHROPIC_FEDERATION_RULE_ID | Oui | ID étiqueté de la règle de fédération à évaluer. | fdrl_... |
ANTHROPIC_ORGANIZATION_ID | Oui | UUID de votre organisation Anthropic. Vous le trouverez dans la Claude Console sous Settings > Organization. | 00000000-0000-0000-0000-000000000000 |
ANTHROPIC_IDENTITY_TOKEN_FILE | L'un de _TOKEN_FILE ou _TOKEN | Chemin du système de fichiers vers le JWT émis par votre « identity provider » (fournisseur d'identité), ou IdP. Le SDK relit ce fichier à chaque échange afin que les jetons projetés qui tournent sur le disque soient toujours à jour. | /var/run/secrets/anthropic.com/token |
ANTHROPIC_IDENTITY_TOKEN | L'un de _TOKEN_FILE ou _TOKEN | Le JWT littéral sous forme de chaîne. À utiliser lorsque votre plateforme injecte le jeton en tant que variable d'environnement plutôt que sous forme de fichier. | eyJhbGciOiJSUzI1NiIs... |
ANTHROPIC_SERVICE_ACCOUNT_ID | Oui | ID étiqueté du compte de service Anthropic cible au nom duquel agit le jeton d'accès émis. | svac_... |
ANTHROPIC_WORKSPACE_ID | Conditionnel | ID étiqueté de l'espace de travail auquel limiter le jeton émis, ou le littéral default. Requis lorsque la règle de fédération est activée pour plus d'un espace de travail ; facultatif lorsque la règle est liée à un seul espace de travail. Le jeton émis est limité à cet espace de travail au moment de l'échange, donc changer d'espace de travail nécessite un nouvel échange. | wrkspc_... |
ANTHROPIC_PROFILE | Non | Nom d'un profil de configuration à charger. Prend le pas sur les variables d'environnement de fédération de ce tableau. | staging-profile |
Le chemin de fédération direct par variables d'environnement ne s'active que lorsque ANTHROPIC_FEDERATION_RULE_ID, ANTHROPIC_ORGANIZATION_ID, ANTHROPIC_SERVICE_ACCOUNT_ID, et l'une de ANTHROPIC_IDENTITY_TOKEN_FILE ou ANTHROPIC_IDENTITY_TOKEN sont toutes définies. ANTHROPIC_WORKSPACE_ID est lue en parallèle mais ne conditionne pas l'activation.
Une variable définie sur une chaîne vide occupe toujours sa place dans la chaîne de priorité des identifiants. Si ANTHROPIC_API_KEY="" est exportée, le SDK sélectionne le chemin de la clé API avec une clé vide au lieu de passer à la fédération. Supprimez les variables d'identifiants inutilisées plutôt que de les vider.
Le SDK résout les identifiants dans cet ordre. La première source qui fournit un identifiant l'emporte.
| Ordre | Source | Remarques |
|---|---|---|
| 1 | Argument de constructeur (api_key=, auth_token=, credentials=) | Prend toujours le pas sur tout le reste. |
| 2 | ANTHROPIC_API_KEY ou ANTHROPIC_AUTH_TOKEN | Masque entièrement la fédération. Supprimez ces variables lors de la migration depuis les clés API. |
| 3 | ANTHROPIC_PROFILE | Charge <config_dir>/configs/<name>.json. Un profil nommé manquant est une erreur, pas un passage à la source suivante. |
| 4 | Variables d'environnement de fédération | ANTHROPIC_FEDERATION_RULE_ID + ANTHROPIC_ORGANIZATION_ID + ANTHROPIC_SERVICE_ACCOUNT_ID + ANTHROPIC_IDENTITY_TOKEN[_FILE]. |
| 5 | Profil actif | Résolu à partir de <config_dir>/active_config, avec repli sur un profil nommé default. |
Lorsqu'un profil est chargé, les variables d'environnement remplissent les champs que le profil omet mais ne remplacent jamais les champs que le profil définit explicitement. Par exemple, ANTHROPIC_WORKSPACE_ID remplit workspace_id uniquement lorsque le profil actif ne le définit pas.
Un profil est un fichier de configuration nommé que le SDK et la CLI ant lisent tous deux. Les profils vous permettent de livrer les paramètres de fédération avec votre image de conteneur ou de basculer entre les environnements sans modifier le code.
Le SDK localise le répertoire de configuration dans cet ordre :
$ANTHROPIC_CONFIG_DIR~/.config/anthropic sous Linux et macOS%APPDATA%\Anthropic sous WindowsLe nom du profil actif est résolu dans cet ordre :
$ANTHROPIC_PROFILE<config_dir>/active_config (un fichier d'une ligne écrit par ant profile activate <name>)defaultClaude Code et le Claude Agent SDK respectent ce même ordre de résolution, donc un profil de fédération configuré ici authentifie également ces outils sans configuration supplémentaire.
| Chemin | Contenu | Sensibilité |
|---|---|---|
<config_dir>/configs/<profile>.json | version, le bloc authentication, organization_id, workspace_id et base_url. | Non secret. Peut être commité ou intégré dans une image en toute sécurité. |
<config_dir>/credentials/<profile>.json | version, l'access_token mis en cache, expires_at et (pour la connexion interactive) refresh_token. | Secret. Écrit par le SDK avec le mode 0600. |
Le fichier de configuration et le fichier d'identifiants comportent tous deux un champ de chaîne de premier niveau version au format major.minor (actuellement "1.0"). Le SDK écrit ce champ automatiquement afin que les versions futures puissent détecter et migrer les formats plus anciens ; omettez-le lorsque vous rédigez une configuration à la main et le SDK traitera le fichier comme étant de la version actuelle.
{
"version": "1.0",
"authentication": {
"type": "oidc_federation",
"federation_rule_id": "fdrl_...",
"service_account_id": "svac_...",
"identity_token": {
"source": "file",
"path": "/var/run/secrets/anthropic.com/token"
}
},
"organization_id": "00000000-0000-0000-0000-000000000000",
"workspace_id": "wrkspc_...",
"base_url": "https://api.anthropic.com"
}Si authentication.identity_token est omis, le SDK se rabat sur ANTHROPIC_IDENTITY_TOKEN_FILE ou ANTHROPIC_IDENTITY_TOKEN depuis l'environnement.
Le oauth_scope que vous définissez sur une règle de fédération détermine quels points de terminaison de l'API Claude le jeton d'accès émis peut appeler.
| Scope | Accorde l'accès à |
|---|---|
workspace:developer | Tous les points de terminaison non administratifs de l'API Claude dans l'espace de travail de la règle : Messages (y compris le streaming et le comptage de tokens), Models, Managed Agents et leurs sessions, Files et Skills. Cela correspond à l'accès dont dispose une clé API émise pour le même espace de travail. |
workspace:inference | Les points de terminaison d'inférence dans l'espace de travail de la règle : Messages (y compris le streaming et le comptage de tokens), Models et le point de terminaison de chat compatible OpenAI. Utilisez-le pour les charges de travail qui n'ont besoin que d'appeler Claude et n'ont jamais besoin de gérer des Files, des Skills ou d'autres ressources. |
workspace:manage_tunnels | L'API des tunnels MCP : créer, lister et obtenir des tunnels, enregistrer et archiver des certificats CA, révéler et faire tourner le jeton de tunnel, et archiver des tunnels. La fenêtre modale de création de tunnel de la Console verrouille ce scope lorsque vous créez une règle depuis celle-ci. |
org:admin | Accès complet à l'Admin API (membres de l'organisation, invitations, espaces de travail, clés API, et le reste). Un jeton OAuth org:admin ne peut créer ou modifier que des règles limitées à workspace:developer ou workspace:inference, et ne peut pas mettre à jour un émetteur qui sous-tend une règle avec tout autre scope ; consultez les contraintes. |
Une requête vers un point de terminaison en dehors du scope du jeton renvoie HTTP 403. Des scopes plus granulaires (par ressource, ou lecture versus écriture) ne sont pas disponibles actuellement.
Le oauth_scope d'une règle de fédération est un plafond : le jeton émis ne peut jamais le dépasser. Le organization_role du compte de service cible (developer ou admin) détermine quels scopes peuvent être accordés, donc une règle qui accorde org:admin doit cibler un compte de service avec organization_role=admin. Les permissions effectives sont l'intersection du scope de la règle et du rôle du compte de service.
oauth_scope de la règle | organization_role du compte de service | Permissions effectives |
|---|---|---|
workspace:developer | admin | Accès à l'API Claude dans l'espace de travail de la règle uniquement. Le scope plafonne le jeton en dessous du rôle. |
org:admin | admin | Accès complet à l'Admin API (membres de l'organisation, invitations, espaces de travail, clés API, et le reste), moins les exclusions propres aux appelants OAuth ; consultez les contraintes. |
Anthropic applique ces contraintes lorsque vous créez ou mettez à jour des émetteurs et des règles, et lors de la vérification d'un JWT entrant au moment de l'échange.
Pour les détails complets des paramètres et les schémas de réponse, consultez la référence de l'API des comptes de service, la référence de l'API des émetteurs de fédération et la référence de l'API des règles de fédération.
| Champ | Contrainte |
|---|---|
name de l'émetteur, de la règle et du compte de service | Doit correspondre à ^[a-z0-9-]+$, longueur de 1 à 255 caractères. |
workspace_id | Requis à la création sauf si applies_to_all_workspaces est true. L'espace de travail (wrkspc_...) dont le quota, la facturation et les limites de débit s'appliquent aux jetons émis sous cette règle. Doit être un espace de travail de la même organisation, et le compte de service cible doit être membre de cet espace de travail. |
applies_to_all_workspaces | Booléen. Définissez true pour activer la règle dans chaque espace de travail de l'organisation au lieu d'en nommer un ; soit ce champ, soit workspace_id est requis à la création. |
token_lifetime_seconds | Entier entre 60 et 86400 (1 minute à 24 heures). Par défaut 3600. Les valeurs en dehors de cette plage sont rejetées au moment de la requête. Consultez Durée de vie et renouvellement des jetons. |
Les champs issuer_url, jwks.discovery_base et jwks.url sont validés :
| Contrainte | Détail |
|---|---|
| Schéma | Doit être https. |
| Port | Doit être 443 (explicite ou par défaut). |
| Hôte | Doit être un nom d'hôte DNS public pour votre fournisseur OIDC. Doit se résoudre en adresses IP publiques ; les littéraux IP ne sont pas acceptés. |
Les échecs de validation d'URL renvoient 400 invalid_request_error avec le nom du champ en préfixe du message d'erreur (par exemple, issuer_url: url must use https scheme).
Les contraintes d'URL ne s'appliquent qu'aux URL qu'Anthropic contacte. Dans les modes JWKS explicit_url et inline, et dans le mode discovery lorsque jwks.discovery_base est défini, l'issuer_url est comparée à la revendication iss du JWT en tant que chaîne et n'est jamais récupérée, elle peut donc référencer un nom d'hôte interne ou un port non standard.
| Contrainte | Détail |
|---|---|
| Taille maximale | Le JWT assertion doit faire au plus 16 Kio. |
| Algorithme de signature | Seuls les algorithmes asymétriques (familles RSA et ECDSA : ES256, ES384, ES512, RS256, RS384, RS512, PS256, PS384, PS512) sont acceptés. HMAC (HS256, HS384, HS512) et none sont rejetés. |
| ID de clé | L'en-tête du JWT doit comporter un kid qui correspond à une clé dans le JWKS de l'émetteur. Les jetons sans kid sont rejetés. |
| Revendications requises | sub doit être présent. iat doit être présent et ne pas être dans le futur. exp doit être présent et dans le futur. |
| Durée de vie maximale | La durée de vie du jeton (exp moins iat) ne doit pas dépasser le maximum configuré de l'émetteur (1 heure par défaut, configurable pour chaque émetteur dans la Claude Console). |
| Décalage d'horloge | Une tolérance de 30 secondes est appliquée à exp, nbf et iat. |
Le bloc match d'une règle de fédération détermine si un JWT entrant est accepté. Tous les champs renseignés sont évalués avec une sémantique AND : le JWT doit satisfaire chaque correspondance renseignée. Au moins l'un de subject_prefix, claims ou condition doit être défini ; un bloc match qui ne contient que audience (ou aucune correspondance du tout) est rejeté. Cela protège contre les règles qui accepteraient tous les jetons d'un émetteur.
| Correspondance | Type | Sémantique |
|---|---|---|
subject_prefix | string | Correspondance exacte avec la revendication sub du JWT. Un * final en fait une correspondance de préfixe (la valeur de sub doit commencer par les caractères précédant le *). Sensible à la casse. |
audience | string | La revendication aud du JWT doit contenir cette chaîne exacte. Lorsque aud est un tableau, tout élément correspondant exactement satisfait la vérification. |
claims | map<string, string> | Chaque clé est un nom de revendication de premier niveau et chaque valeur est la valeur de chaîne exacte requise. Pour les revendications imbriquées, numériques, booléennes ou complexes comme les listes et les maps, utilisez plutôt condition avec une expression CEL. |
condition | string (CEL) | Une expression CEL qui doit s'évaluer à true. |
L'expression condition a accès à une seule variable :
| Variable | Type | Contenu |
|---|---|---|
claims | map | L'ensemble complet des revendications JWT décodées. Les objets imbriqués sont accessibles en tant que maps imbriquées. |
Exemple :
claims.sub.startsWith("repo:acme-corp/") && claims.ref in ["refs/heads/main", "refs/heads/release"]Les conditions CEL sont des frontières de sécurité. Une expression qui s'évalue à true pour plus d'entrées que prévu accorde un accès plus large que prévu. Préférez les correspondances statiques lorsqu'elles expriment votre contrainte.
POST /v1/oauth/token renvoie les erreurs dans le format d'erreur standard de l'API. Le SDK encapsule les échecs d'échange dans une erreur typée FederationExchangeError (ou l'équivalent dans le langage) qui expose le statut HTTP, le corps de la réponse et le request_id.
| Statut | Erreur | Cause | Résolution |
|---|---|---|---|
| 400 | invalid_request | federation_rule_id est mal formé ou un champ requis de la requête est manquant. | Vérifiez l'ID fdrl_ et que le corps de la requête inclut tous les champs requis. |
| 400 | invalid_request | workspace_id_required : la règle de fédération est activée pour plus d'un espace de travail et la requête omet workspace_id. | Définissez ANTHROPIC_WORKSPACE_ID (ou le champ de corps workspace_id sur une requête brute) sur l'ID wrkspc_... auquel vous voulez limiter le jeton. Consultez Requête d'échange de jeton. |
| 400 | invalid_grant | La revendication iss du JWT n'est pas exactement égale à l'issuer_url enregistrée. | Comparez octet par octet, y compris les barres obliques finales et le schéma : jq -rR 'split(".")[1] | gsub("-";"+") | gsub("_";"/") | @base64d | fromjson | .iss' <<< "$JWT". |
| 400 | invalid_grant | La récupération du JWKS a échoué, le JWKS est obsolète, ou le JWT a été signé avec une clé absente du JWKS. | Pour le mode inline, mettez à jour l'émetteur avec les clés renouvelées. Pour discovery et explicit_url, confirmez que le point de terminaison JWKS est joignable sur le port 443 ; si l'émetteur a récemment fait tourner sa clé de signature, consultez Rotation des clés et mise en cache. |
| 400 | invalid_grant | La revendication exp du JWT est dans le passé (au-delà de la fenêtre de tolérance de 30 secondes). | Confirmez que votre fournisseur d'identité projette un jeton frais et que le SDK relit le fichier de jeton. |
| 400 | invalid_grant | Le JWT a été vérifié mais ses revendications ne satisfont pas le bloc match de la règle. | Décodez le JWT et comparez chaque revendication avec la règle. subject_prefix est sensible à la casse. audience nécessite une correspondance exacte d'élément. |
| 400 | invalid_grant | Le federation_rule_id n'existe pas, est archivé, ou le JWT n'est pas autorisé pour celui-ci (consolidé pour empêcher l'énumération). | Confirmez l'ID de la règle dans la Claude Console et que la règle n'a pas été archivée. |
Tous les échecs invalid_grant renvoient HTTP 400 ; la cause spécifique est journalisée uniquement côté serveur et n'est pas exposée dans la réponse.
| Symptôme | Cause | Résolution |
|---|---|---|
| Le SDK signale « no credentials » au lieu d'effectuer l'échange | L'une de ANTHROPIC_FEDERATION_RULE_ID, ANTHROPIC_ORGANIZATION_ID, ANTHROPIC_SERVICE_ACCOUNT_ID ou ANTHROPIC_IDENTITY_TOKEN[_FILE] n'est pas définie et aucun profil n'est actif. | Définissez les quatre variables, ou configurez un profil. |
| Le SDK s'authentifie avec une clé API au lieu de fédérer | ANTHROPIC_API_KEY ou ANTHROPIC_AUTH_TOKEN est définie et l'emporte en priorité. | Supprimez la variable de clé ou de jeton. |
FileNotFoundError à la première requête | Le chemin dans ANTHROPIC_IDENTITY_TOKEN_FILE n'existe pas. Le SDK ouvre le fichier de manière paresseuse au moment de l'échange. | Confirmez que le volume de jeton projeté est monté et que le chemin correspond. |
| L'échange de jeton réussit mais une requête à l'API Claude renvoie 403 | Le scope du jeton émis n'accorde pas l'accès à ce point de terminaison. | Vérifiez le oauth_scope de la règle par rapport aux scopes OAuth. |
| L'authentification échoue avec un identifiant vide | Une variable d'environnement d'identifiant est exportée mais définie sur une chaîne vide. Les valeurs vides conservent leur place dans l'ordre de priorité. | Supprimez la variable avec unset VAR plutôt que VAR="". |
Une réponse 400 invalid_grant est intentionnellement opaque ; la cause spécifique est journalisée uniquement côté serveur.
Commencez par la page d'historique d'authentification dans la Claude Console. Les tentatives d'échange récentes font apparaître l'émetteur et la règle qui ont été évalués, les revendications JWT qui ont été inspectées, et quelle étape de validation a échoué, ce qui court-circuite généralement les vérifications suivantes.
Si vous devez encore déboguer à partir du JWT lui-même, effectuez ces vérifications dans l'ordre :
Décoder le JWT
Décodez l'assertion que vous avez envoyée afin de pouvoir comparer chaque revendication avec la configuration de votre émetteur et de votre règle :
jq -rR 'split(".")[1] | gsub("-";"+") | gsub("_";"/") | @base64d | fromjson' <<< "$JWT"Vérifier que iss correspond à l'émetteur
La revendication iss décodée doit être égale à l'issuer_url enregistrée octet par octet, y compris le schéma, le port et toute barre oblique finale. Une différence d'un seul caractère fait échouer la vérification.
Vérifier que aud correspond à la règle
La revendication aud décodée doit contenir la valeur audience de la règle en correspondance exacte. Lorsque aud est un tableau, un élément doit correspondre exactement.
Vérifier sub et chaque entrée de claims
Comparez sub avec le subject_prefix de la règle (sensible à la casse ; un * final est une correspondance de préfixe, tout le reste est exact). Comparez chaque clé de la map claims de la règle avec la revendication de premier niveau du même nom.
Vérifier exp, nbf et iat
exp doit être dans le futur et nbf/iat doivent être dans le passé, dans la fenêtre de tolérance de 30 secondes. Si l'horloge de l'hôte de la charge de travail a dérivé, un jeton par ailleurs valide est rejeté.
Vérifier l'accessibilité du JWKS
Pour le mode discovery, récupérez <jwks.discovery_base or issuer_url>/.well-known/openid-configuration via HTTPS public sur le port 443 et confirmez que jwks_uri se résout. Pour explicit_url, récupérez directement l'URL du JWKS. Pour inline, confirmez que la clé de signature de l'émetteur n'a pas tourné depuis que vous avez enregistré les clés.
Si l'émetteur a fait tourner sa clé de signature et a immédiatement commencé à signer avec, les échanges peuvent échouer pendant jusqu'à une minute le temps que le cache JWKS d'Anthropic se rafraîchisse. Consultez Rotation des clés et mise en cache.
Lorsque vous enregistrez un émetteur de fédération, le champ jwks contrôle la manière dont Anthropic obtient les clés publiques utilisées pour vérifier les signatures JWT de cet émetteur. Il s'agit d'une union discriminée basée sur type :
jwks.type | Forme de jwks | Comportement | À utiliser quand |
|---|---|---|---|
discovery (par défaut) | { "type": "discovery", "discovery_base": "https://..." } (discovery_base est facultatif ; définissez-le lorsque l'URL de découverte diffère de issuer_url) | Anthropic récupère <discovery_base or issuer_url>/.well-known/openid-configuration, lit jwks_uri dans le document de découverte, et récupère le JWKS à partir de là. | Votre IdP sert un document de découverte OIDC standard sur l'internet public. La plupart des fournisseurs gérés (EKS, GKE, Cloud Run, GitHub Actions, Entra ID) le prennent en charge. |
explicit_url | { "type": "explicit_url", "url": "https://..." } | Anthropic récupère le JWKS directement depuis url. L'issuer_url n'est utilisée que pour la comparaison de chaîne avec la revendication iss du JWT et n'est jamais contactée. | Votre IdP ne sert pas de document de découverte, ou la découverte est uniquement interne mais le JWKS est accessible publiquement. |
inline | { "type": "inline", "keys": [...] } | Vous fournissez le tableau d'objets JWK en ligne (le tableau keys du document JWKS, pas l'objet enveloppant). Anthropic n'effectue aucune requête sortante. L'issuer_url n'est utilisée que pour la comparaison iss. | Environnements isolés (air-gapped), clusters Kubernetes autogérés avec des URL d'émetteur internes au cluster, ou lorsque vous voulez un contrôle explicite sur la rotation des clés. |
L'union discriminée rend les champs associés mutuellement exclusifs par construction. discovery et explicit_url acceptent également une chaîne facultative ca_cert_pem pour les émetteurs qui servent TLS depuis une CA privée.
Dans les modes discovery et explicit_url, Anthropic met en cache le JWKS récupéré. Si votre fournisseur d'identité publie une nouvelle clé de signature et commence immédiatement à signer des jetons avec celle-ci, les échanges qui présentent ces jetons peuvent échouer avec une erreur de signature pendant jusqu'à 1 minute le temps que le cache se rafraîchisse.
Pour éviter cette fenêtre, publiez une nouvelle clé de signature dans le JWKS au moins 15 minutes avant que votre fournisseur d'identité ne commence à signer des jetons avec celle-ci, et conservez la clé remplacée dans le JWKS jusqu'à ce que les jetons qu'elle a signés aient expiré. Les fournisseurs d'identité gérés suivent généralement cette discipline d'eux-mêmes. Si vous exploitez votre propre émetteur (un cluster Kubernetes autogéré, un fournisseur de découverte OIDC SPIRE, ou un serveur d'autorisation personnalisé Okta avec une cadence de rotation configurée), confirmez que votre politique de rotation publie les nouvelles clés avant leur première utilisation.
En mode inline, il n'y a pas de rafraîchissement automatique des clés. Lorsque votre fournisseur d'identité fait tourner ses clés de signature, vous devez mettre à jour la configuration de l'émetteur avec le nouveau JWKS, sinon tous les échanges de jetons échoueront à la vérification de signature.
Was this page helpful?