Authentification des utilisateurs finaux avec votre propre fournisseur d’identité authentication

Par défaut, chaque action de votre application est publique : toute plateforme LLM disposant de votre URL de serveur MCP peut l’appeler et votre gestionnaire ne peut pas identifier l’utilisateur final.

Activez l’authentification lorsqu’une action doit savoir quel utilisateur final demande, par exemple, de renvoyer ses commandes, ses droits ou les détails de son compte. La plateforme LLM connecte l’utilisateur avec votre fournisseur d’identité (IdP), envoie le jeton d’accès résultant avec chaque appel et votre gestionnaire reçoit l’identité vérifiée.

Parcours : copiez l’identifiant de ressource → configurez votre fournisseur d’identité → activez l’authentification → définissez un mode d’authentification pour chaque action → déployer → lire l’identité dans votre gestionnaire → tester l’application protégée.

Il s’agit d’une branche avancée, qui ne fait pas partie du parcours de première exécution. Terminez Créer automatiquement votre première application et Déployer votre application d’abord.

Fonctionnement

Vous apportez votre propre fournisseur d’identité. L’application déployée n’est qu’un serveur de ressources OAuth 2.1, qui vérifie les jetons émis par le serveur d’autorisation. Il n’émet jamais de jetons et Adobe ne stocke jamais votre identifiant ou secret client.

┌── Your identity provider ───────────────────────────────────────────────┐
│  Authorization server — you own it                                      │
│  Issues access tokens, holds the user directory, defines the scopes     │
└─────────────────────────────────────────────────────────────────────────┘
        ▲  2  user signs in, platform gets an access token
        │                                    │
        │  1  platform discovers your        │  3  every tools/call carries
        │     authorization server from      │     Authorization: Bearer <token>
        │     your app's metadata            ▼
┌── LLM platform (ChatGPT, Claude, …) ────────────────────────────────────┐
└─────────────────────────────────────────────────────────────────────────┘
                                             │
                                             ▼
┌── Your LLM App on Adobe I/O Runtime ────────────────────────────────────┐
│  Resource server — verifies the token's signature, issuer, audience,    │
│  and expiry, then enforces the auth mode you set for each action        │
│                                                                         │
│  Your handler reads the verified identity from its second argument      │
└─────────────────────────────────────────────────────────────────────────┘

L’authentification est configurée par environnement. Évaluation et Production contiennent des paramètres indépendants afin que vous puissiez vérifier la configuration par rapport à un client IdP de développement avant de l’activer sur Production.

Avant de commencer

Copier l’identifiant de la ressource

L’identifiant de ressource de votre application est son URL de serveur MCP. Chaque jeton d’accès émis par votre fournisseur d’identité pour cette application doit nommer cette URL exacte comme audience. Cette liaison empêche la relecture d’un jeton émis pour un autre service sur votre application.

Conservez cette valeur : vous en aurez besoin dans votre fournisseur d’identité à l’étape suivante. Collez l’URL copiée plutôt que de la saisir à nouveau. La vérification de l’audience correspond exactement aux chaînes, y compris à tout composant de chemin d’accès. Par conséquent, une seule différence de caractère entraîne l’échec de la validation de chaque jeton.

Configuration de votre fournisseur d’identité

Les étapes exactes diffèrent selon le fournisseur, mais chaque fournisseur a besoin des mêmes quatre choses.

Activer l’authentification

Pour connaître les éléments acceptés par chaque champ, voir Paramètres d’authentification.

Choisir un mode d’authentification pour chaque action

Lorsque vous activez Activer l’authentification, chaque action actuellement définie sur Aucune devient Obligatoire. Sous Configuration par action, vérifiez cette affectation et définissez le mode dont chaque action a besoin :

Les actions déjà définies sur Obligatoire ou Facultatif conservent leur mode existant.

Pour une action Obligatoire ou Facultatif, ajoutez les Portées dont elle a besoin. Chaque portée doit déjà apparaître dans les Portées prises en charge ci-dessus. Sinon, l’application nécessiterait une autorisation qu’elle ne communique pas aux plateformes LLM. L’enregistrement est bloqué jusqu’à ce que la correspondance soit résolue.

Portées prises en charge est l’autorité pour cette liste. Si vous supprimez une portée, celle-ci est supprimée de chaque action qui l’exigeait dès que vous apportez la modification. Ajoutez donc d’abord une portée, puis affectez-la à une action.

Exiger une authentification pour toutes les actions définit chaque action sur Obligatoire. L’effacement renvoie chaque action à Aucune.

Sélectionnez Enregistrer lorsque vous avez terminé. Les modifications du mode d’authentification et de l’étendue sont enregistrées avec les paramètres au niveau de l’application.

Les modes mixtes dans une application (certaines actions sont publiques, d’autres sont bloquées) sont pris en charge et ChatGPT applique individuellement le mode de chaque action : seules les actions bloquées invitent l’utilisateur à se connecter.

Déployer la modification

Les modifications d’authentification prennent effet lors du prochain déploiement de cette application. Déployez à nouveau l’application dans l’environnement que vous avez configuré. Voir Déployer votre application.

L’URL de votre serveur MCP ne change pas. Par conséquent, tout plug-in ou connecteur que vous avez déjà créé continue à fonctionner. Elle est désormais fermée, de sorte que ses utilisateurs sont invités à se connecter la prochaine fois qu’ils l’utiliseront.

Lire l’identité dans votre gestionnaire

Une identité vérifiée atteint votre gestionnaire en tant que deuxième argument. Elle est présente chaque fois que l’appelant a envoyé un jeton valide, quel que soit le mode d’authentification de l’action. Une action facultative peut donc personnaliser son résultat lorsqu’un jeton est présent et renvoyer un résultat lorsqu’il ne l’est pas.

Utilisez getAuthenticatedUser pour lire l’utilisateur connecté :

const { getAuthenticatedUser } = require('@adobe/llm-apps-runtime');

module.exports = async ({ orderId }, extra) => {
  const userId = getAuthenticatedUser(extra);

  if (!userId) {
    return { content: [{ type: 'text', text: 'Sign in to see your orders.' }] };
  }

  const order = await fetchOrderForUser(userId, orderId);

  return {
    content: [{ type: 'text', text: `Order ${order.id} is ${order.status}.` }],
    structuredContent: order
  };
};

Vous n’avez pas besoin de vérifier le jeton vous-même. Pour une action Obligatoire, l’exécution bloque chaque appel auquel il manque un jeton valide portant les portées que vous avez répertoriées. De ce fait, le gestionnaire ne s’exécute que pour un appelant autorisé. Utilisez hasScope lorsque vous souhaitez créer une branche sur une autorisation plutôt que de dépendre du point de contrôle, par exemple, dans une action facultative.

Une action facultative peut demander à l’utilisateur de se connecter en cours de conversation en renvoyant la extra.challengeAuth(). Cette option est disponible uniquement sur les actions facultatives :

module.exports = async ({ signIn }, extra) => {
  if (signIn && !extra.authInfo) {
    return extra.challengeAuth({
      error: 'invalid_token',
      errorDescription: 'Sign in to see member pricing.'
    });
  }

  return {
    content: [{
      type: 'text',
      text: extra.authInfo ? await memberDeals() : await publicDeals()
    }]
  };
};

Décidez s’il faut réaffecter à partir d’un paramètre d’entrée explicite, comme signIn le fait ici, plutôt que d’examiner le libellé de l’utilisateur ou de l’utilisatrice.

Définissez error pour correspondre à la condition que vous signalez. Utilisez invalid_token lorsque l’appelant ne dispose d’aucune session valide et doit se connecter, comme dans l’exemple ci-dessus, et insufficient_scope lorsque l’appelant est déjà connecté mais que l’action n’a pas de portée nécessaire. La plateforme LLM choisit le libellé de l’invite que l’utilisateur voit et la mesure dans laquelle ce libellé varie en fonction de cette valeur. Envoyez donc le code qui décrit la condition avec précision.

Ne défiez que lorsque l’identité dont vous avez besoin est réellement manquante, comme le fait ici le contrôle de !extra.authInfo. Un gestionnaire qui défie inconditionnellement ne peut pas être satisfait en se connectant. L’utilisateur est donc invité à s’authentifier à nouveau à chaque appel.

Conserver l’identité côté serveur. Transmettez uniquement ce dont le widget a besoin dans structuredContent, et n’y placez jamais le jeton d’accès. Voir ​ Personnaliser un gestionnaire généré.

Pour le contrat complet, voir API d’authentification de gestionnaire.

Tester l’application protégée

Votre plug-in ou connecteur existant récupère la modification après le déploiement. Pour en configurer un à partir de zéro :

ChatGPT

Dans la boîte de dialogue Nouveau plug-in, définissez Authentification pour correspondre à la manière dont vous avez configuré les actions de l’application :

Une action facultative accepte toujours les appels anonymes, de sorte qu’une application qui en contient un n’est jamais complètement fermée ; choisissez Mixte même si chaque action est définie sur Facultative. Seul Obligatoire refuse les appelants non authentifiés.

Voir Tester le plug-in ChatGPT pour la suite de la boîte de dialogue.

Claude

Ajoutez le connecteur personnalisé, puis sélectionnez Se connecter et effectuez la connexion présentée par votre fournisseur d’identité. Aucun choix d’authentification à effectuer : Claude ouvre l’ensemble du connecteur chaque fois qu’une action est fermée. Voir Test du connecteur Claude.

Vérifier

Si la connexion ne démarre pas ou si un jeton est rejeté, voir Dépannage.

Conseils de sécurité

Prochaines étapes