Okta for AI Agents : Patterns d'Accès

Choisir le Bon Pattern d’Accès

#

Dans mon article précédent sur l’Agentic Enterprise Blueprint, j’ai exploré comment Okta positionne les agents IA comme des identités de premier plan au sein du tissu de sécurité de l’entreprise. J’y examinais le cadre stratégique répondant à trois questions fondamentales : Où sont mes agents ? À quoi peuvent-ils se connecter ? Que peuvent-ils faire ?

Mais une stratégie sans exécution n’est que théorie. Je veux maintenant répondre à une question plus concrète : Comment les agents IA doivent-ils s’authentifier et autoriser leurs communications avec les ressources de l’entreprise ?

Ce guide est conçu pour aider les architectes, les équipes de sécurité et les ingénieurs solutions à évaluer les quatre patterns d’accès qu’Okta for AI Agents propose pour les intégrations d’agents IA. À la fin, vous comprendrez :

• Quel pattern correspond à vos exigences de sécurité (contexte utilisateur, réduction de portée, pistes d’audit)
• Quel pattern vos ressources supportent (ID-JAG, OAuth, clés API ou nom d’utilisateur/mot de passe)
• Comment comparer les niveaux de sécurité entre les patterns
• Quand migrer des patterns legacy vers des approches modernes

Cette question n’est pas académique. Le pattern d’accès choisi détermine :

• Si vos journaux d’audit capturent l’attribution utilisateur : Pouvez-vous retracer une action jusqu’à l’agent et l’utilisateur au nom duquel il a agi ?
• Si vous pouvez révoquer un accès chirurgicalement : Pouvez-vous désactiver l’accès d’un seul utilisateur à un agent sans affecter les autres ?
• Si votre architecture est conforme aux exigences réglementaires : Votre implémentation satisfait-elle aux mandats de traçabilité NIST SP 800-63-4¹, EU AI Act², NIS2³, DORA⁴ ?

Considérez ce scénario : votre équipe de sécurité enquête sur un incident d’accès aux données. Un agent IA a accédé à des enregistrements clients sensibles à 3h47 du matin. Avec le mauvais pattern d’accès, vos journaux d’audit pourraient n’afficher que service-account-agent accessed database. Avec le bon pattern, vous voyez sales-representative-agent, acting on behalf of john@example.com, accessed customer record #12847 with read scope, transaction ID jti-7z9x2q8. La différence est architecturale, pas fortuite.

Okta for AI Agents (O4AA) propose quatre patterns d’accès distincts, chacun optimisé pour différents modèles de sécurité, capacités de ressources et exigences de conformité⁵. Le choix n’est pas arbitraire : c’est une décision architecturale fondamentale qui façonne votre posture de sécurité pour les agents.

Examinons chaque pattern, comprenons quand l’utiliser, et voyons comment ils s’inscrivent dans une stratégie d’accès cohérente.

Les Patterns d’Accès en un Coup d’Œil

#

La plateforme Okta for AI Agents (O4AA) offre quatre façons pour un agent d’accéder à une ressource en aval. Chacune est configurée en tant que Managed Connection (Connexion Gérée) attachée au principal de charge de travail de l’agent dans Okta. Choisir le bon pattern repose sur trois facteurs :

1. Qu’est-ce que la ressource en aval supporte ? (XAA, ID-JAG, OAuth, clé API, nom d’utilisateur/mot de passe)
2. Un contexte au niveau utilisateur est-il requis ? (Attribution d’audit, réduction de portée par utilisateur)
3. Quelles sont vos exigences de sécurité et de gouvernance ? (Profil de conformité, granularité de révocation)

Les Quatre Patterns

#

Explorons chaque pattern en détail, comment ils fonctionnent, quand les utiliser, et examinons des cas d’usage concrets ainsi que des exemples de configuration pour vous aider à mettre en œuvre la bonne stratégie d’accès pour vos agents IA.

Cross App Access (XAA)

#

Cross App Access (XAA) est le pattern d’accès phare d’Okta for AI Agents. Il implémente un accès délégué par l’utilisateur et tenant compte du contexte utilisateur via l’Identity Assertion JWT Authorization Grant (ID-JAG), un standard IETF émergent pour la délégation sécurisée⁷.

Pourquoi XAA est Important

#

XAA est le premier pattern d’accès à intégrer le contexte d’identité complet à chaque étape d’un workflow d’agent. Chaque token contient à la fois :

• sub : L’identité utilisateur (qui a autorisé cette action)
• act.sub : L’identité de l’agent (quel agent agit en son nom)

Cette structure à double identité permet des capacités impossibles avec les comptes de service traditionnels :

• Attribution d’audit par utilisateur : Chaque action de l’agent est traçable jusqu’à l’utilisateur spécifique qui l’a autorisée
• Révocation chirurgicale : Désactiver l’accès d’un utilisateur à un agent sans affecter les autres utilisateurs ou agents
• Réduction de portée : Les permissions effectives du token correspondent à l’intersection la plus étroite de ce que l’agent est autorisé à faire, de ce à quoi l’utilisateur a droit, et de ce que la tâche spécifique requiert
• Conformité réglementaire : Pistes d’audit complètes satisfaisant aux exigences de traçabilité NIST SP 800-63-4¹, EU AI Act², NIS2³ et DORA⁴

Comment Fonctionne XAA : Le Flux ID-JAG

#

Le flux XAA implique une séquence d’échange de tokens où Okta garantit l’identité de l’utilisateur auprès du serveur d’autorisation de la ressource cible.

sequenceDiagram
    autonumber
    actor User
    participant Client as 🤖 Client
(AI Agent)
    box rgba(243, 242, 247,0.3) Okta Cloud
        participant IdP as 🔐 IdP AS
(Okta Org AS)
        participant AS as 🛡️ Resource AS
(Custom AS)
    end
    participant RS as 📦 Resource Server
(Protected API)

    Note over User, RS: Étape 1 : Authentification Utilisateur (SSO)
    User->>Client: Connexion via SSO (OIDC)
    Client->>IdP: Authentification OIDC
    IdP-->>Client: ID Token (sub: user@example.com)

    Note over User, RS: Étape 2 : Échange de Token (RFC 8693)
    Client->>IdP: Requête d'échange de token
    Note right of Client: grant_type:token-exchange
subject_token:ID_Token
requested_token_type:id-jag
audience:Resource AS
    IdP->>IdP: Valider l'ID Token
    Note right of IdP: private_key_jwt
politique de connexion gérée
    IdP->>IdP: Générer l'ID-JAG
    IdP-->>Client: ID-JAG (Identity Assertion)
    Note left of IdP: sub:user
aud:Resource AS
client_id:agent

    Note over User, RS: Étape 3 : JWT Bearer Grant (RFC 7523)
    Client->>AS: Requête JWT Bearer
    Note right of Client: grant_type:jwt-bearer
assertion:ID-JAG
scope:orders:read
    AS->>AS: Valider l'ID-JAG
    Note left of AS: correspondance aud
correspondance client_id
signature (JWKS)
    AS->>AS: Appliquer la politique d'autorisation
    AS-->>Client: Access Token
    Note left of AS: sub + act.sub + scope
éphémère

    Note over User, RS: Étape 4 : Appel API
    Client->>RS: Appel API (avec Access Token)
    RS->>RS: Valider le Token (JWKS)
    RS-->>Client: Données de réponse
    Client-->>User: Afficher les données

Décomposition étape par étape

#

1. L’utilisateur s’authentifie (SSO) : L’utilisateur se connecte via OIDC à travers l’agent IA. L’Okta Org AS émet un ID Token contenant l’identité de l’utilisateur (sub: user@example.com).
2. Échange de token chez Okta (RFC 8693) : L’agent s’authentifie avec ses propres identifiants de charge de travail (private_key_jwt) et demande un échange de token (grant_type: token-exchange, subject_token: ID Token, requested_token_type: id-jag, audience: Custom AS). Okta valide l’ID Token, vérifie la politique de connexion gérée, et génère un ID-JAG — un JWT signé contenant sub (utilisateur), aud (Custom AS) et client_id (agent).
3. JWT Bearer grant au Custom AS (RFC 7523) : L’agent présente l’ID-JAG au point de terminaison token du Custom AS (grant_type: jwt-bearer, assertion: ID-JAG, scope: orders:read). Le Custom AS valide la signature de l’ID-JAG via JWKS, confirme que aud et client_id correspondent, applique sa politique d’autorisation locale, et émet un token d’accès éphémère avec sub + act.sub.
4. Appel API : L’agent appelle la ressource protégée avec le token d’accès à portée limitée. La ressource valide le token via JWKS et retourne les données. La réponse remonte par l’agent jusqu’à l’utilisateur.

Le Standard ID-JAG

#

ID-JAG (Identity Assertion JWT Authorization Grant) est basé sur plusieurs standards IETF :

• RFC 8693 : OAuth 2.0 Token Exchange
• RFC 7523 : JWT Profile for OAuth 2.0 Client Authentication
• IETF draft-02 : Spécification Identity JWT Authorization Grant

Pour un aperçu complet de Cross App Access et de son intégration dans l’écosystème OAuth, consultez la référence Cross App Access sur OAuth.net.

L’innovation clé est la claim act, qui capture l’identité de l’acteur (agent) séparément de l’identité du sujet (utilisateur). Cela permet une séparation nette entre “pour qui est cette action” et “quel système exécute l’action.”

Structure du Token

#

Un token d’accès XAA typique contient :

{
  "sub": "john@example.com",
  "act": {
    "sub": "sales-representative-agent",
    "aud": "okta.com"
  },
  "aud": "crm-orders-api",
  "scope": "orders:read accounts:read",
  "jti": "s2r3d4x3m6a0q1l",
  "iat": 1735571312,
  "nbf": 1735571312,
  "exp": 1735571468
}

Bénéfices pour l’Audit et la Conformité

#

Avec XAA, les journaux système d’Okta capturent un contexte riche pour chaque événement d’accès, incluant les identités utilisateur et agent, les portées demandées, la ressource cible et un ID de transaction unique pour la corrélation. L’EventType app.oauth2.token.grant.id_jag indique spécifiquement quand un échange ID-JAG a eu lieu, fournissant une piste d’audit claire pour les actions des agents.

Voici un exemple d’une entrée de journal d’événements XAA réelle provenant des journaux système d’Okta :

{
  "actor": {
    "id": "wlpxnnu00000B6vxs1d7",
    "type": "PublicClientApp",
    "alternateId": "unknown",
    "displayName": "Pricing Agent",
    "detailEntry": null
  },
  "client": {
    "userAgent": {
      "rawUserAgent": "python-requests/2.33.1",
      "os": "Unknown",
      "browser": "UNKNOWN"
    },
    "zone": "null",
    "device": "Unknown",
    "id": null,
    "ipAddress": "x.x.x.x",
    "geographicalContext": {
      "city": "Ashburn",
      "state": "Virginia",
      "country": "United States",
      "postalCode": "20149",
      "geolocation": {
        "lat": 39.0469,
        "lon": -77.4903
      }
    }
  },
  "displayMessage": "OAuth 2.0 Identity Assertion Authorization Grant is granted",
  "eventType": "app.oauth2.token.grant.id_jag",
  "outcome": {
    "result": "SUCCESS",
    "reason": null
  },
  "published": "2026-04-16T19:27:49.919Z",
  "securityContext": {
    "asNumber": 14618,
    "asOrg": "amazon.com  inc.",
    "isp": "amazon.com  inc.",
    "domain": "amazonaws.com",
    "isProxy": false,
    "ipDetails": {
      "asNumber": 14618,
      "asOrg": "amazon.com  inc.",
      "isp": "amazon.com  inc.",
      "domain": "amazonaws.com"
    }
  },
  "severity": "INFO",
  "debugContext": {
    "debugData": {
      "clientAuthType": "private_key_jwt",
      "grantedScopes": "pricing:margin",
      "subjectTokenIssuer": "https://xxx.oktapreview.com",
      "subjectTokenType": "urn:ietf:params:oauth:token-type:id_token",
      "clientId": "wlpxnnu00000B6vxs1d7",
      "responseTime": "213",
      "requestedTokenType": "urn:ietf:params:oauth:token-type:id-jag",
      "authorizationServerAudience": "https://xxx.oktapreview.com/oauth2/ausxnnacdm60nV7vv1d7",
      "requestUri": "/oauth2/v1/token",
      "requestedScopes": "pricing:margin",
      "tokenExchangeType": "Agent ID Assertion",
      "url": "/oauth2/v1/token?",
      "managedConnectionId": "mcnxnodu9t2FRZO5R1d7",
      "subjectTokenId": "ID.kiJ9Ch3aBer2ftX2CobkLuSSPqBMdMsZaxwRMZQjr44",
      "subjectTokenClientId": "0oaxnnekviMmWpyBK2d3",
      "requestId": "5eaf3d96ff3dbb684e1099bf8cecdd53",
      "dtHash": "96dec87ffaebc55e64ab62eca30303c555d589e0f9686d55827963c51032ef7f",
      "threatSuspected": "false",
      "grantType": "urn:ietf:params:oauth:grant-type:token-exchange"
    }
  },
  "legacyEventType": null,
  "transaction": {
    "type": "WEB",
    "id": "5eaf3d96ff3dbb684e1099bf8cecdd53",
    "detail": {}
  },
  "uuid": "5b10a39b-39ca-11f1-bbfb-f341db467931",
  "version": "0",
  "request": {
    "ipChain": [
      {
        "ip": "x.x.x.x",
        "geographicalContext": {
          "city": "Ashburn",
          "state": "Virginia",
          "country": "United States",
          "postalCode": "20149",
          "geolocation": {
            "lat": 39.0469,
            "lon": -77.4903
          }
        },
        "version": "V4",
        "source": null,
        "ipDetails": {
          "asNumber": 14618,
          "asOrg": "amazon.com  inc.",
          "isp": "amazon.com  inc.",
          "domain": "amazonaws.com"
        }
      }
    ]
  },
  "target": [
    {
      "id": "ID.kiJ9Ch3aBer2ftX2CobkLuSSPqBMdMsZaxwRMZQjr44",
      "type": "id_token",
      "alternateId": null,
      "displayName": "ID Token",
      "detailEntry": {
        "audience": "0oaxnnekviMmWpyBK2d3",
        "expires": "2026-04-16T20:07:29.000Z",
        "subject": "00uxnn7b13YEcYj2V6a7",
        "hash": "iMQM1uCzsH07nFhkRPUNvg"
      }
    },
    {
      "id": "00uxnn7b13YEcYj2V6a7",
      "type": "User",
      "alternateId": "fabio.grasso@example.com",
      "displayName": "Fabio Grasso",
      "detailEntry": null
    },
    {
      "id": "IDAAG.5ZazR5P-fmm8zuG1CwuqT3EenUx1pFfN00jToEE0s6A",
      "type": "id_jag",
      "alternateId": null,
      "displayName": "Identity Assertion JWT Authorization Grant",
      "detailEntry": {
        "audience": "https://xxx.oktapreview.com/oauth2/ausxnnacdm60nV7vv1d7",
        "expires": "2026-04-16T19:32:49.000Z",
        "subject": "00uxnn7b13YEcYj2V6a7",
        "scope": "pricing:margin",
        "hash": "Tq7wccRtqpRvZvEXKYK9nA"
      }
    }
  ]
}

Comme vous pouvez le voir, non seulement l’agent ayant effectué la requête (Pricing Agent) mais aussi l’utilisateur ayant autorisé l’action (fabio.grasso@example.com) sont journalisés. Le champ grantedScopes indique les permissions effectives accordées à l’agent pour cette requête, soit l’intersection de ce que l’agent peut faire et de ce à quoi l’utilisateur a droit. La claim jti du token devient le transaction.id dans les journaux, vous permettant de corréler cet événement avec des événements en aval dans les journaux de votre ressource, si celle-ci journalise également l’ID de transaction.

Cas d’Usage XAA

#

Voici quelques exemples concrets de l’utilisation de XAA pour sécuriser différents types de ressources :

1. API interne via MCP Server — Un agent de support client doit accéder à la base de données interne des commandes pour répondre aux demandes clients.
   • Agent enregistré dans l’Okta Universal Directory
   • MCP Server protégé par un Okta Custom Authorization Server
   • Flux XAA : l’agent échange l’ID Token de l’utilisateur contre un accès limité à orders:read
   • Audit : chaque requête journalisée avec l’ID utilisateur, l’ID agent et l’ID de transaction
2. SaaS First-Party (ISV-Enabled) — Un agent assistant commercial accédant aux opportunités Salesforce au nom d’un commercial.
   • Salesforce implémente la validation ID-JAG
   • L’agent présente l’ID-JAG au point de terminaison d’autorisation Salesforce
   • Salesforce émet un token à portée limitée pour les données de l’utilisateur uniquement
   • Pas d’identifiants statiques ; pas de comptes de service partagés
3. Workflows d’agents multi-étapes — Un agent financier exécute un workflow d’approbation :
   • Étape 1 : Lire la note de frais (portée read:expenses)
   • Étape 2 : Vérifier la disponibilité budgétaire (portée read:budgets)
   • Étape 3 : Soumettre l’approbation (portée write:approvals)
   • Chaque étape peut demander des portées différentes. Si l’agent est compromis en cours de workflow, la révocation arrête uniquement la session de cet utilisateur sans affecter les autres.

Tester XAA : Le Playground xaa.dev

#

Okta propose un environnement de test interactif sur xaa.dev où vous pouvez expérimenter les flux XAA sans infrastructure à configurer⁸.

Fonctionnalités :

• Tests dans le navigateur (pas de Docker ni de configuration locale)
• Composants préconfigurés : Requesting App, Resource App, IdP
• Démarrage en moins de 60 secondes
• Enregistrement de vos propres clients personnalisés pour les tests

Le playground inclut un exemple de flux où « Bob Tables » crée et gère des tâches via un agent IA, illustrant l’échange ID-JAG complet.

ID-JAG et XAA : Une Note sur la Terminologie

#

Vous avez probablement croisé les deux termes — « ID-JAG » et « XAA » — utilisés de façon quasi interchangeable dans la documentation, les articles de blog et les conférences. Ils sont étroitement liés, mais pas identiques.

Imaginez que l’on appelle n’importe quel essuie-tout « Sopalin » quelle que soit la marque : le produit dominant finit par désigner toute la catégorie. C’est un peu ce qui se passe ici.

ID-JAG (Identity Assertion JWT Authorization Grant) est l’extension OAuth en cours de standardisation à l’IETF. Elle définit précisément comment les fournisseurs d’identité émettent des tokens d’assertion que les applications peuvent échanger contre des tokens d’accès. N’importe quel IdP peut implémenter ID-JAG — c’est un standard ouvert, et la spécification appartient à toute l’industrie.

XAA (Cross-App Access) est le nom commercial d’Okta pour leur implémentation d’ID-JAG. Okta a été un moteur clé à la fois de l’effort de standardisation IETF et de l’adoption précoce dans l’industrie — leur investissement en ingénierie et leur advocacy pour les développeurs ont fait de « XAA » le terme que beaucoup rencontrent en premier, et celui qui tend à s’imposer comme raccourci pour l’extension elle-même.

La distinction pratique compte : XAA est une implémentation d’un standard ouvert. Lorsque vous lisez la documentation Okta, « XAA » désigne spécifiquement le produit Okta. Lorsque vous lisez un draft IETF ou un guide d’intégration tiers, « ID-JAG » désigne la spécification sous-jacente que toute organisation peut implémenter.

Limitations de XAA

#

• Adoption ISV en cours : XAA est GA côté Okta, mais les intégrations SaaS tierces nécessitent le support des ISVs. Les principaux fournisseurs implémentent activement ID-JAG ; construire sur XAA maintenant garantit que vous serez prêt quand ils livreront.

• Durée de vie du token vs. sessions longues : Les tokens sont éphémères et expirent en quelques minutes, nécessitant de nouveaux échanges pour chaque requête. C’est délibéré (limite le rayon d’explosion) mais peut affecter les agents qui mettent des identifiants en cache.

• Non adapté pour : Les agents qui doivent fonctionner hors ligne ou mettre des identifiants en cache indéfiniment. Pour ces scénarios, envisagez STS avec une gestion attentive du cycle de vie des identifiants.

Secure Token Service (STS)

#

Secure Token Service (STS) permet aux agents d’accéder aux applications SaaS tierces qui supportent OAuth mais n’ont pas encore adopté XAA. Okta agit comme un courtier sécurisé, stockant en coffre-fort les tokens consentis par l’utilisateur et fournissant un accès fédéré à courte durée au moment de l’exécution.

Dans la console d’administration Okta, vous configurez STS en créant une connexion gérée avec le type de ressource “Application”, en sélectionnant une intégration OIN app ou un serveur de ressources personnalisé⁹. Okta fait alors office de courtier pour l’échange de tokens OAuth entre l’agent et le service tiers.

Quand Utiliser STS

#

• SaaS tiers avec support OAuth mais sans support ID-JAG (par exemple aujourd’hui : GitHub, Google Workspace, Slack)
• Le contexte au niveau utilisateur est requis pour l’audit et la conformité

Comment Fonctionne STS

#

sequenceDiagram
    autonumber
    actor User
    participant Okta as Okta (Token Broker)
    participant ThirdParty as Third-Party SaaS
    participant Agent as AI Agent

    rect rgb(240, 248, 255)
        Note over User,ThirdParty: Flux de Consentement Unique
        User->>Okta: Authenticate
        Okta->>ThirdParty: OAuth Authorization Request
        ThirdParty-->>User: Consent Screen
        User-->>ThirdParty: Approve access
        ThirdParty-->>Okta: Authorization Code
        Okta->>ThirdParty: Exchange for tokens
        ThirdParty-->>Okta: Access + Refresh Tokens
        Okta->>Okta: Vault tokens (Privileged Access)
    end

    rect rgb(255, 248, 240)
        Note over Agent,ThirdParty: Accès Agent au Moment de l'Exécution
        Agent->>Okta: Request access (workload identity)
        Okta->>Okta: Validate managed connection policy
        Okta-->>Agent: Short-lived federated token
        Agent->>ThirdParty: API call with token
        ThirdParty-->>Agent: Response
    end

Décomposition étape par étape

#

1. Consentement unique : L’utilisateur s’authentifie et consent au service tiers
2. Mise en coffre-fort des tokens : Okta sécurise les tokens d’accès et de rafraîchissement dans Okta Privileged Access
3. Accès au moment de l’exécution : L’agent s’authentifie à Okta avec son principal de charge de travail
4. Échange de token : Okta émet un token fédéré à courte durée pour le service en aval
5. Accès API : L’agent appelle l’API tierce avec le token à courte durée ; de façon cruciale, les identifiants utilisateur ne touchent jamais l’agent

Cas d’Usage STS

#

1. GitHub — Un agent assistant de développement lit des dépôts et crée des pull requests au nom des développeurs. Le développeur consent une fois via l’écran OAuth de GitHub ; Okta met en coffre-fort les tokens résultants. Au moment de l’exécution, l’agent reçoit un token fédéré à courte durée pour appeler l’API GitHub — il ne détient jamais d’identifiants GitHub à longue durée.
2. Google Workspace — Un agent de planification gère des événements de calendrier et rédige des emails pour un utilisateur. Le contexte utilisateur est préservé grâce au flux de consentement, de sorte que les journaux d’audit de Google capturent quel utilisateur a autorisé les actions de l’agent.
3. Jira/Confluence — Un agent de gestion de projet crée des tickets à partir de conversations Slack et met à jour des pages de documentation. L’agent s’authentifie via le token courtisé par Okta, sans jamais stocker directement des identifiants Atlassian.

Différence Clé avec XAA

#

• Flux de consentement : STS requiert que l’utilisateur passe par l’écran de consentement OAuth du tiers ; Okta stocke et gère ensuite ces tokens au nom de l’agent. XAA contourne entièrement l’écran de consentement. La délégation se fait au moment de l’enregistrement de l’agent dans Okta.
• Piste d’audit : STS capture le consentement utilisateur et l’accès agent dans les journaux Okta, mais le service tiers ne voit peut-être que l’identité de l’agent. XAA fournit le contexte utilisateur+agent complet à la ressource.
• Durée de vie du token : Le token fédéré émis à l’agent est à courte durée (minutes) pour limiter le risque, mais les tokens d’accès/rafraîchissement sous-jacents dans Okta peuvent avoir des durées de vie plus longues selon les politiques du service tiers.
• Révocation : Révoquer l’accès nécessite de supprimer l’entrée du coffre-fort dans Okta, ce qui peut affecter tous les agents utilisant cette connexion. Pas de révocation par utilisateur au sein du service tiers.
• Réduction de portée : L’agent reçoit les portées auxquelles l’utilisateur a consenti lors du flux OAuth. Okta ne peut pas réduire dynamiquement les portées par requête comme XAA.

Pre-Shared Key (PSK) ou Secret en Coffre-Fort

#

Pre-Shared Key (PSK) stocke des identifiants statiques (clés API, tokens bearer, secrets webhook) dans Okta Privileged Access (OPA). L’agent récupère les secrets au moment de l’exécution plutôt que de les intégrer dans le code ou la configuration.

Quand Utiliser Pre-Shared Key

#

• APIs REST legacy ne supportant que l’authentification par clé API
• Points de terminaison webhook nécessitant des tokens bearer
• Intégrations tierces avec authentification par token statique
• Services en phase initiale qui ajouteront éventuellement OAuth

Comment Fonctionne Pre-Shared Key

#

sequenceDiagram
    autonumber
    participant Admin as Admin
    participant Okta as Okta (Privileged Access)
    participant Agent as AI Agent
    participant Resource as Protected Resource

    rect rgb(240, 255, 240)
        Note over Admin,Okta: Phase de Configuration
        Admin->>Okta: Create & vault secret (API key)
        Admin->>Okta: Create managed connection on agent
    end

    rect rgb(255, 248, 240)
        Note over Agent,Resource: Accès au Moment de l'Exécution
        Agent->>Okta: Authenticate (workload principal)
        Okta->>Okta: Validate managed connection policy
        Okta-->>Agent: Release secret
        Agent->>Resource: API call with secret
        Resource-->>Agent: Response
    end

Décomposition étape par étape

#

1. L’administrateur met le secret en coffre-fort : Un administrateur stocke la clé API ou le token bearer dans Okta Privileged Access et crée une connexion gérée sur l’agent (type : Secret)
2. L’agent s’authentifie : Au moment de l’exécution, l’agent s’authentifie à Okta avec son identité de principal de charge de travail
3. Vérification de politique : Okta valide l’identité de l’agent et vérifie la politique de connexion gérée
4. Secret libéré : Okta libère l’identifiant mis en coffre-fort à l’agent
5. Accès direct à la ressource : L’agent utilise l’identifiant statique pour appeler la ressource en aval directement — sans échange de token, sans contexte utilisateur

Limitations de Pre-Shared Key

#

• Pas de contexte utilisateur : La ressource ne voit que l’identité de l’agent, pas l’utilisateur
• Pas de réduction de portée : L’agent dispose de l’accès complet accordé à l’identifiant
• Piste d’audit limitée : Les journaux montrent l’accès de l’agent, sans attribution utilisateur

Service Account

#

Service Account utilise des identifiants nom d’utilisateur et mot de passe liés à une identité de service partagée. C’est le pattern legacy dont Okta recommande explicitement de migrer.

Comment Fonctionne Service Account

#

sequenceDiagram
    autonumber
    participant Admin as Admin
    participant Okta as Okta (Privileged Access)
    participant AgentA as Agent A
    participant AgentB as Agent B
    participant Resource as Protected Resource

    Admin->>Okta: Create service account (svc_agent@example)
    Admin->>AgentA: Register with managed connection
    Admin->>AgentB: Register with managed connection

    AgentA->>Okta: Request credentials
    AgentB->>Okta: Request credentials
    Okta-->>AgentA: Username/Password
    Okta-->>AgentB: Username/Password

    AgentA->>Resource: Authenticate as svc_agent@example
    AgentB->>Resource: Authenticate as svc_agent@example

    Note over Resource: Les deux apparaissent avec la même identité !

Décomposition étape par étape

#

1. L’administrateur provisionne le compte de service : Un administrateur configure un compte de service dans Okta Privileged Access et crée des connexions gérées sur un ou plusieurs agents
2. L’agent demande des identifiants : Au moment de l’exécution, chaque agent s’authentifie à Okta et demande les identifiants du compte de service
3. Okta libère le nom d’utilisateur/mot de passe : Okta valide l’identité de l’agent, vérifie la politique et transmet les identifiants partagés
4. L’agent s’authentifie à la ressource : L’agent se connecte à la ressource en aval en tant que compte de service — indiscernable de tout autre agent utilisant les mêmes identifiants

Limitations des Service Accounts

#

Les Service Accounts présentent quatre lacunes de sécurité critiques :

1. Agents invisibles : Plusieurs agents partagent une identité unique, rendant impossible de savoir lequel a effectué une action
2. Permissions excessives : Les comptes de service portent généralement des privilèges larges et statiques qui dépassent largement ce qu’une tâche unique nécessite
3. Attribution utilisateur manquante : Les audits de conformité ne peuvent pas répondre à « quel utilisateur a déclenché cet accès aux données ? »
4. Révocation tout ou rien : Désactiver le compte de service coupe l’accès à tous les agents et systèmes qui en dépendent

Quand Service Account est Inévitable

#

• Systèmes legacy nécessitant une authentification nom d’utilisateur/mot de passe (bases de données on-prem, mainframes, services LDAP)
• Traitements par lots sans contexte utilisateur final
• Systèmes n’ayant pas adopté de méthode d’authentification moderne

Service Account n’est acceptable que pour les processus batch sans contexte utilisateur, avec un plan de fin de vie documenté.

Recommandations Stratégiques

#

Matrice de Comparaison des Patterns

#

Sélection du Pattern par Profil de Conformité

#

Framework de Décision

#

Le framework classe les patterns par posture de sécurité : XAA offre les garanties les plus solides, tandis que Service Account représente la plus faible (et doit être traité comme temporaire).

---
config:
  layout: dagre
---
flowchart TB
    A["La ressource supporte-t-elle ID-JAG ?"] -- Oui --> XAA["✅ Utiliser XAA
Délégué utilisateur, audit complet,
révocation chirurgicale"]
    A -- Non --> B["La ressource supporte-t-elle OAuth 2.0 ?"]
    B -- Oui --> STS["🔄 Utiliser STS
Courtage de tokens avec consentement utilisateur"]
    B -- Non --> C["La ressource supporte-t-elle les clés API ?"]
    C -- Oui --> PSK["⚠️ Utiliser PSK
Secret en coffre-fort"]
    C -- Non --> SA["🚫 Service Account
Seule option — planifier la migration immédiatement"]

    A@{ shape: hex}
    B@{ shape: hex}
    C@{ shape: hex}
    style XAA fill:#d4edda,stroke:#28a745
    style STS fill:#E1BEE7,stroke:#0d6efd
    style PSK fill:#fff3cd,stroke:#ffc107
    style SA fill:#f8d7da,stroke:#dc3545

Séquençage de l’Implémentation

#

Voici une feuille de route recommandée pour la transition vers XAA tout en maintenant la sécurité et la conformité :

• Phase 1 : Auditer les intégrations existantes
  • Cartographier toutes les connexions d’agents sur l’un des quatre patterns
  • Identifier les comptes de service et les pre-shared keys
• Phase 2 : Les nouvelles intégrations adoptent XAA par défaut
  • Utiliser STS uniquement quand XAA n’est pas supporté
  • Utiliser Service Account ou Pre-Shared Key uniquement quand c’est absolument nécessaire
  • Documenter le rationnel pour les choix non-XAA
• Phase 3 : Surveiller les roadmaps ISV
  • Dès que les ISVs adoptent ID-JAG, migrer les connexions STS vers XAA
  • Suivre les annonces d’adoption
• Phase 4 : Fin de vie de Service Account et Pre-Shared Key
  • Établir un calendrier formel de dépréciation
  • Migrer vers STS comme étape intermédiaire
  • Objectif : zéro compte de service pour les charges de travail avec contexte utilisateur

De la Théorie à la Pratique : Configurer les Patterns d’Accès dans Okta

#

Dans l’Okta Universal Directory, vous pouvez enregistrer des agents IA comme identités de charge de travail et créer des Managed Connections qui définissent comment ils accèdent aux ressources en aval. Chaque type de connexion correspond à l’un des patterns d’accès abordés ci-dessus.

Liste des Agents IA	Détail d’un Agent IA

Quand vous créez une connexion gérée, vous verrez cinq types de ressources. Ils correspondent aux quatre patterns d’accès couverts dans cet article :

Aperçu de la Configuration XAA

#

Implémenter XAA nécessite :

1. Enregistrer l’agent dans l’Okta Universal Directory comme principal de charge de travail
2. Créer une Managed Connection et sélectionner “Authorization Server” (pour les APIs personnalisées) ou “MCP Server” (pour les points de terminaison MCP). Les deux utilisent le même échange ID-JAG en interne.
3. Configurer le Custom Authorization Server protégeant votre ressource
4. Définir des politiques RBAC qui évaluent à la fois les attributs utilisateur et agent

Exemple de logique de politique, pour s’assurer que l’agent ne peut accéder aux données de vente que quand l’utilisateur est membre de l’équipe commerciale :

IF (act.sub == "sales-representative-agent")
AND (sub IN groups["sales-team"])
AND (requested_scope IN ["sales:read", "accounts:read"])
THEN issue_token_with_scope
ELSE deny

Il s’agit d’un exemple en pseudo-code. Dans la console d’administration Okta, les politiques d’accès du Custom Authorization Server utilisent un modèle politique + règle — pas un langage de script. Pour suivre l’exemple, vous pouvez :

1. Créer une Politique d’Accès assignée à l’agent IA (c’est-à-dire sales-representative-agent). Cela limite implicitement la politique à cet agent spécifique (act.sub).
2. Créer une Règle dans cette politique :
   • Type de grant : JWT Bearer (le grant d’échange ID-JAG)
   • Éligibilité utilisateur : Utilisateurs membres du groupe : sales-team — cela garantit que seuls les membres de l’équipe commerciale peuvent déléguer l’accès via cet agent
   • Portées : Liste blanche de orders:read et accounts:read — l’agent ne peut pas demander des portées plus larges même si l’utilisateur en dispose
   • Durée de vie du token : 5 minutes (éphémère)
   • Évaluation : Les politiques et règles sont évaluées par ordre de priorité. La première correspondance gagne. Si aucune règle ne correspond (par exemple, un utilisateur hors sales-team tente d’utiliser cet agent), la requête est refusée.

Le résultat : l’agent ne peut accéder aux données de vente que quand l’utilisateur derrière la requête est membre de l’équipe commerciale. Les permissions effectives sont l’intersection de la liste blanche de portées de la politique, de l’appartenance au groupe de l’utilisateur, et de la connexion gérée de l’agent.

Conclusions

#

Le choix du pattern d’accès n’est pas un détail technique : c’est une décision architecturale qui façonne la posture de sécurité de vos agents IA pour les années à venir.

Points clés à retenir :

1. XAA est l’avenir : Délégué utilisateur, auditable, conforme. Investir dans XAA maintenant signifie que votre architecture est prête pour MCP Server et la prise en charge Agent-to-Agent dès leur disponibilité.

2. STS comble le fossé : Pour les SaaS tiers qui supportent OAuth mais pas ID-JAG, STS fournit le contexte utilisateur pendant que vous attendez l’adoption ISV.

3. Pre-Shared Key est acceptable pour le legacy : Les services ne supportant que les clés API nécessitent des secrets en coffre-fort, mais planifiez la migration à mesure que les ressources se modernisent.

4. Service Account est une dette technique : Chaque compte de service est un écart de conformité qui attend de se manifester lors d’un audit. Commencez à planifier votre sortie.

Le parcours de Service Account → Pre-Shared Key → STS → XAA représente une progression de maturité en sécurité. Chaque montée d’échelon ajoute du contexte utilisateur, de la réduction de portée et de la granularité d’audit.

XAA sera également la base pour les capacités futures comme Agent-to-Agent Access (A2A), Kill Switch (révocation globale de tokens), les workflows Human-in-the-Loop (HITL). Commencer avec XAA signifie que vous ne sécurisez pas seulement les intégrations d’aujourd’hui, mais que vous préparez également l’avenir pour les innovations de demain.

Pour Commencer

#

Tester XAA Aujourd’hui

#

Explorez le playground XAA interactif sur xaa.dev, sans configuration requise. Découvrez le flux ID-JAG complet dans votre navigateur.

En Savoir Plus

#

• Okta for AI Agents : Aperçu de la plateforme
• Cross App Access Solution : Page de la solution XAA
• Cross App Access Documentation : Guide de configuration officiel
• XAA.dev Documentation : Documentation du playground interactif
• Cross App Access Introduction : Plongée technique approfondie
• XAA Developer Playground : Tutoriel pratique
• Building Resource Apps : Guide d’implémentation
• Agentic Enterprise Blueprint : Cadre de gouvernance stratégique
• Demo Interactive : Securing the Autonomous Enterprise : Démonstration

Rejoignez la Discussion

#

Quelles intégrations dans votre environnement utilisent encore des comptes de service ? Avez-vous commencé à cartographier vos connexions d’agents sur ces patterns d’accès ? Où en êtes-vous dans ce parcours ?

Partagez votre expérience dans les commentaires ci-dessous ou connectez-vous avec moi sur LinkedIn pour continuer la discussion.