À mesure que les applications d'IA générative passent du stade de prototypes à celui de solutions d'entreprise, la sécurité devient incontournable. Ces applications interagissent souvent avec des données utilisateur sensibles, des bases de données internes et des logiques décisionnelles qui doivent être protégées contre tout accès non autorisé. Streamlit, bien qu'il soit idéal pour développer rapidement des interfaces IA interactives, ne dispose pas de mécanismes de contrôle d'accès intégrés. les workflows donc essentiel d'intégrer les workflows d'authentification et d'autorisation robustes pour protéger à la fois l'interface utilisateur et les API backend.
Présentation de l'architecture AgentCreator Streamlit
Ce guide se concentre sur la sécurisation d'une application d'agent commercial générative alimentée par l'IA, créée avec SnapLogic AgentCreator et déployée via Streamlit. L'application intègre Salesforce OAuth 2.0 en tant que fournisseur d'identité et sécurise ses API backend à l'aide de SnapLogic API Management. Grâce à cette configuration, seuls les utilisateurs Salesforce autorisés provenant d'un domaine de confiance peuvent accéder à l'application, ce qui garantit une sécurité de bout en bout pour le frontend et le backend.
Comprendre la pile d'applications
Rôle de AgentCreator de SnapLogic
Le SnapLogic AgentCreator permet aux développeurs et aux ingénieurs commerciaux de créer des agents sophistiqués basés sur l'IA sans avoir à gérer une infrastructure complexe. Ces agents fonctionnent dans les pipelines SnapLogic, ce qui facilite l'intégration de la logique métier, des intégrations API et du traitement des données de manière modulaire. Par exemple, un assistant commercial créé avec AgentCreator exposé sous forme d'API à l'aide de tâches déclenchées peut extraire des données CRM en temps réel, générer des réponses intelligentes et les renvoyer via une interface web épurée.
Streamlit comme interface utilisateur
Au niveau du front-end, Streamlit est utilisé pour créer une interface web simple et interactive permettant aux utilisateurs d'interroger l'agent commercial.
Importance de la gestion des API dans les workflows d'IA
Une fois ces agents exposés via des API HTTP, il est essentiel de gérer qui y accède et comment. C'est là qu'intervient SnapLogic API Management. Il fournit des outils de niveau entreprise pour la publication d'API, la sécurisation des points de terminaison, l'application de contrôles d'accès basés sur les rôles et la surveillance du trafic. Ces fonctionnalités garantissent que seuls les utilisateurs et clients vérifiés peuvent interagir avec vos API, réduisant ainsi le risque d'accès non autorisé aux données ou d'abus.
Cependant, le véritable défi consiste à sécuriser les deux extrémités :
- L'interface utilisateur Streamlit, qui doit restreindre l'accès aux utilisateurs autorisés.
- Les API SnapLogic, exposant les AgentCreator qui doivent valider et autoriser chaque requête entrante.
Authentification OAuth 2.0 : principes fondamentaux et avantages
Qu'est-ce que OAuth 2.0 ?
OAuth 2.0 est un protocole standard ouvert conçu pour sécuriser l'accès délégué. Au lieu de partager directement leurs identifiants, les utilisateurs accordent aux applications l'accès à leurs ressources à l'aide de jetons d'accès. Ce modèle est particulièrement utile dans les environnements d'entreprise, où la gestion centralisée des identités est cruciale. Grâce à OAuth 2.0, les applications peuvent authentifier les utilisateurs via des fournisseurs d'identité (IDP) de confiance tout en maintenant une séparation entre l'authentification, l'autorisation et la logique applicative.
Pourquoi utiliser Salesforce comme fournisseur d'identité (IDP) ?
Salesforce est un fournisseur d'identité robuste auquel de nombreuses organisations font déjà confiance pour la gestion de la relation client (CRM), la gestion des utilisateurs et la sécurité. L'utilisation de Salesforce pour l'authentification OAuth 2.0 permet aux développeurs d'exploiter une base d'utilisateurs préexistante et un cadre de confiance organisationnel. Dans ce tutoriel, Salesforce est utilisé pour gérer la connexion et l'émission de jetons, garantissant ainsi que seuls les utilisateurs Salesforce autorisés peuvent accéder à l'application Streamlit. Cette intégration simplifie également la conformité aux politiques d'identité d'entreprise telles que l'authentification unique (SSO), l'authentification multifactorielle (MFA) et les restrictions basées sur le domaine.
Pour relever le défi de l'authentification, nous utilisons le flux de code d'autorisation OAuth 2.0, Salesforce agissant à la fois comme fournisseur d'identité et fournisseur de jetons.
Voici la documentation officielle de Salesforce sur les points de terminaison OAuth, qui vous aidera à configurer votre application connectée.
Remarque: bien que Salesforce soit un choix logique pour cet exemple, puisque l'agent commercial interagit avec les données Salesforce,tout fournisseur d'identité (IDP) compatible OAuth2, tel que Google, Okta ou Microsoft Entra ID (anciennement Azure AD), peut être utilisé. Le flux d'authentification de base reste le même, les variations portant principalement sur les points de terminaison OAuth et les étapes d'enregistrement des applications.
Présentation de l'architecture et objectifs de sécurité
Frontend (Streamlit) vs Backend (API SnapLogic)
L'architecture de l'application sépare l'interface frontale et la logique dorsale. L'interface frontale est construite à l'aide de Streamlit, qui permet aux utilisateurs d'interagir avec un tableau de bord visuellement intuitif. Elle gère la connexion, affiche les réponses générées par l'IA et capture les entrées des utilisateurs. La dorsale, alimentée par AgentCreator de SnapLogic, héberge la logique métier centrale dans des pipelines qui sont exposés sous forme d'API. Cette séparation garantit la flexibilité et le développement modulaire, mais elle pose également le défi de sécuriser les deux composants de manière indépendante tout en assurant leur cohésion.
Modèle de menace et objectifs de sécurité
Les principales menaces pour la sécurité dans un tel système comprennent l'accès non autorisé à l'interface utilisateur, les fuites de données via des API non sécurisées et l'utilisation abusive des jetons. Afin d'atténuer ces risques, les objectifs de sécurité suivants ont été définis :
- Authentification : assurez-vous que seuls les utilisateurs légitimes provenant d'un fournisseur d'identité de confiance (Salesforce) peuvent se connecter.
- Autorisation : accorder l'accès à l'API en fonction des rôles et des domaines des utilisateurs, vérifiés via les politiques APIM de SnapLogic.
- Intégrité des jetons : validez et inspectez les jetons d'accès avant d'autoriser la communication backend avec les politiques SnapLogic APIM.
- Gestion des secrets : stockez vos identifiants sensibles (tels que l'ID client et le secret) en toute sécurité à l'aide des fonctionnalités de gestion des secrets de Streamlit.
Cette approche par couches s'aligne sur les normes de sécurité des entreprises et fournit un modèle évolutif pour les futures applications d'IA générative.
Flux d'authentification et d'autorisation
Voici comment nous gérons l'accès en toute sécurité :
1. Connexion via Salesforce:
- Les utilisateurs sont redirigés vers l'écran de connexion de Salesforce.

Redirection vers la page de connexion Saleforce
- Une fois la connexion établie, Salesforce redirige vers l'application avec un jeton d'accès.
- Le jeton et les informations d'identité de l'utilisateur sont stockés dans l'état de session de Streamlit.
2. Appel des API SnapLogic:
- Le frontend envoie des requêtes aux API de tâches déclenchées de SnapLogic, en joignant le jeton d'accès Salesforce dans l'en-tête HTTP d'autorisation.
3. Sécurisation des API via les politiques SnapLogic:
- Politique d'authentification par appel: valide le jeton en l'envoyant au point de terminaison de validation des jetons de Salesforce, car les jetons Salesforce sont opaques et ne sont pas autonomes comme les JWT.
- Politique AuthorizeByRole: après avoir extrait l'adresse e-mail de l'utilisateur, cette politique vérifie si le domaine (par exemple, @snaplogic.com) est autorisé. Si c'est le cas, l'accès est accordé.
Vous trouverez ci-dessous le flux complet du code d'autorisation OAuth 2 amélioré avec l'introspection des jetons.

Flux d'authentification et d'autorisation
Cette configuration garantitune sécurité de bout en bout, combinant l'authentification basée sur OAuth avec les capacités de gestion des API de niveau entreprise de SnapLogic. Dans les sections suivantes, nous vous expliquerons comment mettre en œuvre chaque élément, de la configuration de l'application connectée Salesforce à la configuration des politiques dans SnapLogic, afin que vous puissiez reproduire ou adapter ce modèle à vos propres applications d'IA générative.
Étape 1 : Configurer l'application connectée à Salesforce
Accédez à la console développeur Salesforce.
Pour lancer le flux d'authentification OAuth 2.0, vous devez enregistrer votre application en tant qu'application connectée dans Salesforce. Commencez par vous connecter à votre compte développeur ou administrateur Salesforce. À partir de l'icône en forme d'engrenage en haut à droite, accédez à Configuration → Gestionnaire d'applications. Cliquez sur « Nouvelle application connectée » pour créer un nouveau profil d'application compatible OAuth.
Définir les URL de rappel OAuth et les champs d'application
Dans le nouveau formulaire Connected App, définissez les champs suivants dans la section API (Activer les paramètres OAuth):
- URL de rappel : il doit s'agir de l'URL de votre application Streamlit (par exemple, https://snaplogic-genai-builder.streamlit.app/Sales_Agent).
- Portées OAuth sélectionnées : incluez au moins openid, email et profile. Vous pouvez également inclure des portées supplémentaires en fonction du niveau d'accès requis.
Assurez-vous que la case « Activer les paramètres OAuth » est cochée pour rendre cette application compatible avec OAuth.
Récupérer l'ID client et la clé secrète client
Après avoir enregistré la configuration de l'application, Salesforce générera une clé consommateur (ID client) et un secret consommateur. Ceux-ci sont essentiels pour l'échange OAuth et doivent être stockés en toute sécurité. Vous utiliserez ces valeurs ultérieurement lors de la configuration de l'intégration OAuth Streamlit et des paramètres environnementaux. Ne divulguez pas ces secrets dans votre base de code ou votre contrôle de version.
Pour plus d'informations sur les points de terminaison OAuth Salesforce, consultez : Documentation sur les points de terminaison OAuth Salesforce
Étape 2 : Intégrer OAuth à Streamlit à l'aide de streamlit-oauth
Installer et configurer le paquet streamlit-oauth
Pour intégrer l'authentification OAuth 2.0 dans votre application Streamlit, vous pouvez utiliser le package tiers streamlit-oauth (streamlit-oauth). Ce package résume le flux OAuth et simplifie l'intégration avec les fournisseurs d'identité populaires tels que Salesforce. Pour l'installer, exécutez la commande suivante dans votre terminal :
pip install streamlit-oauth
Après l'installation, vous configurerez le composant OAuth2Component pour lancer le processus de connexion et gérer la réception des jetons une fois l'authentification réussie.
Traiter les identifiants ClientID et ClientSecret de manière sécurisée
Une fois que les utilisateurs se connectent via Salesforce, l'application reçoit un jeton d'accès et un jeton d'identification. Ces jetons ne doivent jamais être exposés dans l'interface utilisateur ni enregistrés publiquement. Ils doivent plutôt être stockés en toute sécurité dans st.session_state, le système de gestion de session natif de Streamlit. Cela garantit que les jetons sont liés à la session de l'utilisateur et peuvent être consultés pour les appels API ultérieurs dans le flux.
Stocker les identifiants via la gestion des secrets Streamlit
Le stockage de secrets tels que CLIENT_ID et CLIENT_SECRET directement dans votre code source représente un risque pour la sécurité. Streamlit fournit un système intégré de gestion des secrets qui vous permet de stocker des informations sensibles dans un fichier .streamlit/secrets.toml, qui doit être exclu du contrôle de version.
Exemple :
# .streamlit/secrets.toml
SF_CLIENT_ID = "your_client_id"
SF_CLIENT_SECRET = "your_client_secret"
Dans votre code, vous pouvez y accéder en toute sécurité :
CLIENT_ID = st.secrets["SF_CLIENT_ID"]
CLIENT_SECRET = st.secrets["SF_CLIENT_SECRET"]
Étape 3 : Gérer les paramètres d'environnement avec python-dotenv
Pourquoi les variables d'environnement sont importantes
La gestion des configurations spécifiques à l'environnement est essentielle pour maintenir des applications sécurisées et évolutives. En plus de stocker les informations d'identification sensibles à l'aide de la gestion des secrets de Streamlit, le stockage des paramètres OAuth dynamiques tels que les URL, les champs d'application et les URI de redirection dans un fichier d'environnement (par exemple, .env) vous permet de garder un code propre et une configuration flexible. Cela est particulièrement utile si vous prévoyez de déployer sur plusieurs environnements (développement, mise en scène, production) avec des paramètres différents.
Stocker les points de terminaison OAuth dans des fichiers .env
Pour gérer les paramètres d'environnement, utilisez le package python-dotenv (python-dotenv), qui charge les variables d'environnement d'un fichier .env dans votre application Python. Commencez par installer la bibliothèque :
pip install python-dotenv
Créez un fichier .env dans le répertoire de votre projet avec le format suivant :
SF_AUTHORIZE_URL=https://login.salesforce.com/services/oauth2/authorize
SF_TOKEN_URL=https://login.salesforce.com/services/oauth2/token
SF_REVOKE_TOKEN_URL=https://login.salesforce.com/services/oauth2/revoke
SF_REDIRECT_URI=https://your-streamlit-app-url
SF_SCOPE=id openid email profile
Ensuite, utilisez la fonction dotenv_values pour charger les variables dans votre script :
from dotenv import dotenv_values
env = dotenv_values(".env")
AUTHORIZE_URL = env["SF_AUTHORIZE_URL"]
TOKEN_URL = env["SF_TOKEN_URL"]
REVOKE_TOKEN_URL = env["SF_REVOKE_TOKEN_URL"]
REDIRECT_URI = env["SF_REDIRECT_URI"]
SCOPE = env["SF_SCOPE"]
Cette approche garantit que vos données sensibles et spécifiques à l'environnement sont dissociées du code source, ce qui améliore la maintenabilité et la sécurité.
Étape 4 : Configurer le flux OAuth dans Streamlit
Définir le composant OAuth2 et la logique de redirection
Une fois vos variables d'environnement et vos secrets en place, il est temps de configurer le flux OAuth dans Streamlit à l'aide du composant OAuth2Component du package streamlit-oauth. Ce composant gère la redirection des utilisateurs vers la page de connexion Salesforce, la récupération des jetons et l'analyse des réponses lors du retour vers votre application.
from streamlit_oauth import OAuth2Component
oauth2 = OAuth2Component(
client_id=CLIENT_ID,
client_secret=CLIENT_SECRET,
authorize_url=AUTHORIZE_URL,
token_url=TOKEN_URL,
redirect_uri=REDIRECT_URI
)
# create a button to start the OAuth2 flow
result = oauth2.authorize_button(
name="Log in",
icon="https://www.salesforce.com/etc/designs/sfdc-www/en_us/favicon.ico",
redirect_uri=REDIRECT_URI,
scope=SCOPE,
use_container_width=False
)
Ce bouton lance le flux OAuth2 et gère la redirection de manière transparente. Une fois que l'utilisateur s'est connecté avec succès, Salesforce le redirige vers l'application avec un jeton valide.
Gérer l'état de session pour les jetons et les données utilisateur
Après authentification, les jetons renvoyés sont stockés dans st.session_state afin de maintenir un contexte sécurisé pour chaque utilisateur. Voici comment décoder le jeton et extraire les informations d'identité de l'utilisateur :
if result:
#decode the id_token and get the user's email address
id_token = result["token"]["id_token"]
access_token = result["token"]["access_token"]
# verify the signature is an optional step for security
payload = id_token.split(".")[1]
# add padding to the payload if needed
payload += "=" * (-len(payload) % 4)
payload = json.loads(base64.b64decode(payload))
email = payload["email"]
username = payload["name"]
#storing token and its parts in session state
st.session_state["SF_token"] = result["token"]
st.session_state["SF_user"] = username
st.session_state["SF_auth"] = email
st.session_state["SF_access_token"]=access_token
st.session_state["SF_id_token"]=id_token
st.rerun()
else:
st.write(f"Congrats **{st.session_state.SF_user}**, you are logged in now!")
if st.button("Log out"):
cleartoken()
st.rerun()
Ce mécanisme garantit que le contexte utilisateur authentifié est préservé tout au long des interactions et que les jetons sensibles restent protégés pendant toute la durée de la session.
Le nom d'utilisateur s'affiche dans l'interface utilisateur après une connexion réussie.

Étape 5 : Créer et exposer la tâche déclenchée par SnapLogic
Construisez une logique backend avec AgentCreator
Une fois l'authentification des utilisateurs gérée sur le front-end, l'étape suivante consiste à créer la logique métier du back-end à l'aide de SnapLogic AgentCreator. Cette boîte à outils vous permet de concevoir des pipelines alimentés par l'IA qui s'intègrent aux sources de données, effectuent un traitement intelligent et renvoient des réponses contextuelles. Vous pouvez utiliser des Snaps (connecteurs SnapLogic) pré-intégrés pour Salesforce, OpenAI et d'autres services afin d'assembler votre pipeline d'agents commerciaux.
Générer l'URL de déclenchement pour l'accès à l'API
Une fois votre pipeline testé et opérationnel, exposez-le en tant qu'API à l'aide d'une tâche déclenchée:
- Dans SnapLogic Designer, ouvrez votre pipeline Sales Agent.
- Cliquez sur « Créer une tâche » et sélectionnez « Tâche déclenchée ».
- Donnez un nom significatif et définissez les paramètres d'exécution si nécessaire.
- Après avoir enregistré, notez l'URL de déclenchementgénérée. Celle-ci sert de point de terminaison backend auquel l'application Streamlit enverra les requêtes.
Cette URL sert de passerelle entre votre interface authentifiée et la logique IA sécurisée de plateforme SnapLogic. Cependant, avant de la connecter à Streamlit, vous devrez la protéger à l'aide de SnapLogic API Management, que nous aborderons dans la section suivante.
Étape 6 : Sécurisez l'API avec SnapLogic API Manager
Introduction aux politiques API : authentification et autorisation
Pour empêcher tout accès non autorisé à votre backend, vous devez sécuriser le point de terminaison Triggered Task à l'aide de SnapLogic API Management. SnapLogic permet une sécurité basée sur des politiques, vous permettant d'appliquer l'authentification et l'autorisation à l'aide de jetons émis par Salesforce. Deux politiques principales seront appliquées : Callout Authenticator et Authorize By Role.

Ajouter une stratégie d'authentification par appel
Cette stratégie valide le jeton d'accès reçu de Salesforce. Les jetons Salesforce étant opaques (ils ne sont pas autonomes comme les JWT), la stratégie Callout Authenticator envoie le jeton au point de terminaison d'introspection de Salesforce pour validation. Si le jeton est actif, Salesforce renvoie les métadonnées de l'utilisateur (adresse e-mail, portée, ID client, etc.).
Exemple de réponse d'introspection de jeton valide :
{
"active": true,
"scope": "id refresh_token openid",
"client_id": "3MVG9C...",
"username": "[email protected]",
"sub": "https://login.salesforce.com/id/...",
"token_type": "access_token",
"exp": 1743708730,
"iat": 1743701530,
"nbf": 1743701530
}
Si le jeton n'est pas valide ou a expiré, la réponse affichera simplement :
{
"active": false
}
Vous trouverez ci-dessous la configuration de la stratégie d'authentification des appels :


Ajouter la stratégie AuthorizeByRole
Une fois le jeton validé, la stratégie Autoriser par rôle inspecte le nom d'utilisateur (adresse e-mail) renvoyé par Salesforce. Vous pouvez configurer cette stratégie pour n'autoriser l'accès qu'aux utilisateurs d'un domaine de confiance (par exemple, @snaplogic.com), afin de garantir que les utilisateurs externes ne puissent pas exploiter votre API.
Par exemple, vous pouvez configurer la politique pour vérifier la présence de « snaplogic » dans la partie domaine de l'adresse e-mail. Cela ajoute un deuxième niveau de sécurité après la vérification du jeton et prend en charge les modèles d'accès interne uniquement.

Étape 7 : Connectez l'interface Streamlit à l'API sécurisée
Transmettre les jetons d'accès dans l'en-tête d'autorisation HTTP
Une fois que l'utilisateur s'est connecté avec succès et que le jeton d'accès est stocké dans st.session_state, vous pouvez utiliser ce jeton pour communiquer en toute sécurité avec votre point de terminaison SnapLogic Triggered Task. Le jeton d'accès doit être inclus dans l'en-tête Authorization de la requête HTTP à l'aide du schéma de jeton Bearer.
headers = {
'Authorization': f'Bearer {st.session_state["SF_access_token"]}'
}
Cela garantit que SnapLogic API Manager peut valider la requête et appliquer les politiques d'authentification et d'autorisation avant d'exécuter la logique backend.
Afficher les réponses API dans l'interface utilisateur Streamlit
Pour rendre l'interaction fluide, vous pouvez capturer les données saisies par l'utilisateur, les envoyer à l'API sécurisée et afficher la réponse directement dans l'application Streamlit. Voici un exemple de ce à quoi pourrait ressembler cette interaction :
import requests
import streamlit as st
prompt = st.text_input("Ask the Sales Agent something:")
if st.button("Submit"):
with st.spinner("Working..."):
data = {"prompt": prompt}
headers = {
'Authorization': f'Bearer {st.session_state["SF_access_token"]}'
}
response = requests.post(
url="https://your-trigger-url-from-snaplogic",
data=data,
headers=headers,
timeout=10,
verify=False # Only disable in development
)
if response.status_code == 200:
st.success("Response received:")
st.write(response.text)
else:
st.error(f"Error: {response.status_code}")
Cela connecte entièrement l'interface utilisateur au backend sécurisé, permettant ainsi des interactions sécurisées et en temps réel avec votre agent IA génératif.
Pièges courants et dépannage
Gestion des jetons expirés ou invalides
L'un des problèmes les plus courants dans les applications sécurisées par OAuth est la gestion des jetons expirés ou invalides. Les jetons d'accès Salesforce ayant une durée de vie limitée, les utilisateurs qui restent inactifs pendant un certain temps peuvent voir leur session invalidée. Pour remédier à cela :
- Vérifiez toujours la validité du jeton avant d'effectuer des appels API.
- Gérer avec élégance les réponses 401 Non autorisé en invitant l'utilisateur à se reconnecter.
- Mettez en place un mécanisme d'actualisation des jetons si votre application prend en charge les sessions de longue durée (nécessite la configuration des jetons d'actualisation dans Salesforce).
En gérant de manière proactive le cycle de vie des jetons, vous évitez toute perturbation de l'expérience utilisateur et sécurisez les communications API.
Débogage des erreurs de redirection OAuth
Les erreurs de configuration de la redirection OAuth peuvent bloquer le flux d'authentification. Voici les problèmes courants et leurs solutions :
- URL de rappel incorrecte : assurez-vous que la valeur SF_REDIRECT_URI dans votre fichier .env correspond exactement à celle définie dans les paramètres de l'application connectée Salesforce.
- Portées manquantes : si le jeton ne contient pas les champs d'identité attendus (comme l'adresse e-mail), vérifiez que toutes les portées requises (openid, email, profile) sont incluses à la fois dans la configuration de l'application et dans la requête OAuth.
- Restrictions de domaine : si l'accès est refusé même après une connexion réussie, vérifiez que le domaine de messagerie de l'utilisateur correspond à la politique définie dans SnapLogic API Manager.
Enregistrer les messages d'erreur renvoyés et utiliser les outils de développement du navigateur peut vous aider à identifier le problème lors des étapes de redirection et de rappel.
Meilleures pratiques pour un déploiement sécurisé des applications d'IA
Faites tourner régulièrement les secrets
Pour réduire le risque de fuite de secrets et d'exploitation potentielle, il est essentiel de faire tourner régulièrement les identifiants sensibles, tels que CLIENT_ID et CLIENT_SECRET. Même si la gestion des secrets de Streamlit stocke ces valeurs en toute sécurité, une rotation périodique garantit une résilience contre les expositions accidentelles, les menaces internes ou les erreurs de configuration du référentiel.
Pour rationaliser ce processus, configurez des rappels dans votre calendrier ou utilisez des pipelines DevSecOps automatisés qui remplacent les secrets et mettent à jour les fichiers d'environnement ou les magasins de secrets en conséquence.
Surveiller les journaux API et les échecs d'authentification
La sécurité ne s'arrête pas à la mise en œuvre. Une surveillance continue est essentielle pour identifier les tentatives d'utilisation abusive ou d'intrusion. L'interface de gestion des API de SnapLogic fournit des mesures détaillées qui peuvent vous aider à :
- Suivez l'utilisation de l'API par utilisateur ou par adresse IP.
- Identifiez les échecs d'autorisation répétés ou les erreurs d'inspection des jetons.
- Repérez les anomalies telles que les volumes d'appels inattendus ou les requêtes mal formées.

Extension de l'architecture
Prise en charge d'autres fournisseurs OAuth (Google, Okta, Entra ID)
Bien que ce tutoriel se concentre sur Salesforce en tant que fournisseur d'identité OAuth 2.0, la même architecture de sécurité peut être étendue pour prendre en charge d'autres fournisseurs populaires tels que Google, Okta et Microsoft Entra ID (anciennement Azure AD). Ces fournisseurs sont entièrement compatibles avec OAuth et proposent généralement des points de terminaison similaires pour l'autorisation, l'échange de jetons et l'introspection des utilisateurs.
Pour changer de fournisseur, mettez à jour les éléments suivants dans votre fichier .env :
- SF_AUTHORIZE_URL
- SF_TOKEN_URL
- SF_SCOPE (selon la documentation du fournisseur)
Assurez-vous également que votre application est enregistrée dans le portail développeur du fournisseur concerné et configurée avec l'URI de redirection et les champs d'application corrects.
Ajout de contrôles d'accès basés sur les rôles
Pour les déploiements à plus grande échelle, un simple filtrage basé sur le domaine peut s'avérer insuffisant. Vous pouvez étendre la logique d'autorisation en intégrant des contrôles d'accès basés sur les rôles (RBAC). Pour ce faire, vous pouvez :
- Inclusion de rôles personnalisés dans la charge utile du jeton OAuth (par exemple, via des revendications personnalisées).
- Analyse de ces rôles dans la politique AuthorizeByRole de SnapLogic.
- Restriction de l'accès à certaines API ou fonctionnalités en fonction des rôles des utilisateurs (par exemple, administrateur, analyste, lecteur).
Le RBAC vous permet de créer des applications à plusieurs niveaux avec des autorisations différenciées tout en maintenant une gouvernance de sécurité rigoureuse.
Conclusions finales sur le déploiement sécurisé d'applications d'IA
La sécurisation de vos applications d'IA générative n'est plus facultative, en particulier lorsqu'elles sont conçues pour des cas d'utilisation en entreprise impliquant des données sensibles, des interactions avec les clients et l'automatisation des décisions. Ce tutoriel a présenté un modèle de sécurité complet utilisantSnapLogic AgentCreator et Streamlit, authentifié via Salesforce OAuth 2.0 et protégé par SnapLogic API Management.
En suivant cette approche étape par étape, vous vous assurez que seuls les utilisateurs vérifiés peuvent accéder à votre application et que les API backend sont protégées par une authentification à plusieurs niveaux et des politiques d'autorisation basées sur les rôles. La même architecture peut facilement être étendue à d'autres fournisseurs ou adaptée à plusieurs les workflows d'IA les workflows votre organisation.
Ressources pour approfondir vos connaissances
- Ressources et cas d'utilisation SnapLogic
- Documentation pour les développeurs Salesforce
- Documentation Streamlit
- Spécification officielle OAuth 2.0
Grâce à une base solide, vous êtes désormais en mesure de créer et de développer en toute confiance des applications d'IA puissantes et adaptées aux entreprises.





