LinkedIn
Instagram
WhatsApp
Telegram
Google Agenda
Rejoindre la communauté SlackAPI OAuth par e-mail : Authentifier les boîtes aux lettres des utilisateurs la bonne façon
Arrêtez de stocker des mots de passe. Une API d'e-mail OAuth permet à votre application d'accéder de manière sécurisée aux boîtes de réception des utilisateurs - en utilisant des jetons révocables et à portée limitée de Gmail, Outlook et des fournisseurs IMAP. Ce guide couvre tous les flux OAuth, toutes les étendues, tous les pièges et comment expédier en 5 minutes avec une couche d'authentification unifiée hébergée.
// Connecter n'importe quelle boîte aux lettres utilisateur via OAuth - 1 appel API
const response = await fetch(
'https://api6.unipile.com:13226/api/v1/hosted/accounts/link',
{
method: POST,
headers: {
'X-API-KEY': 'VOTRE_CLÉ_API',
'Content-Type': 'application/json'
},
body: JSON.stringify({
type : 'Google', // ou MICROSOFT, IMAP
nom : 'utilisateur_123'
})
}
);
const { url } = await réponse.json();
// Rediriger l'utilisateur vers l'URL - OAuth géré par Unipile
Qu'est-ce qu'une API email OAuth ?
Un API de messagerie OAuth est une interface programmatique qui accorde à votre application l'accès aux boîtes aux lettres des utilisateurs à l'aide de jetons OAuth 2.0, sans jamais manipuler ni stocker le mot de passe de l'utilisateur. Au lieu de demander des identifiants aux utilisateurs, vous les redirigez vers l'écran de consentement du fournisseur, recevez un jeton d'accès de courte durée et l'utilisez pour lire, envoyer ou synchroniser des e-mails en leur nom. La distinction est importante : il s'agit d'accéder boîtes aux lettres appartenant à des utilisateurs (Gmail, Outlook, e-mail personnel), ne pas envoyer d'e-mails transactionnels via des services de relais SMTP tels que SendGrid.
Un API de messagerie OAuth est une combinaison d'un flux d'autorisation OAuth 2.0 (pour authentifier un utilisateur et obtenir un accès délégué) et d'une API d'e-mail (pour lire, envoyer, rechercher ou synchroniser la boîte aux lettres de cet utilisateur). La couche OAuth génère un jeton d'accès révocable, limité en portée et signé cryptographiquement. L'API d'e-mail consomme ce jeton pour interagir avec Gmail, Outlook ou toute boîte aux lettres compatible IMAP, le tout sans jamais connaître le mot de passe de l'utilisateur.
- Stocke les mots de passe en texte brut ou chiffrés dans votre base de données
- Accès complet à la boîte aux lettres - aucun contrôle de portée
- Bloqué par Google/Microsoft depuis 2026
- Responsabilité RGPD/SOC2 pour le stockage des identifiants
- Stockage de mot de passe nul - jetons de courte durée uniquement
- Portées granulaires - lecture seule, envoi uniquement ou complète
- Révocable à tout moment par l'utilisateur
- Conforme au RGPD, SOC2
Pourquoi OAuth a remplacé l'accès par e-mail basé sur mot de passe
Utiliser IMAP avec un nom d'utilisateur et un mot de passe était autrefois la méthode standard pour accéder programmatiquement aux e-mails des utilisateurs. Cette époque est révolue. Google a déprécié l'authentification de base pour Gmail en 2022, et Microsoft a achevé la désactivation de l'authentification de base pour Exchange Online en octobre 2022, avec un dernier nettoyage pour les protocoles restants prévu pour 2026. Si votre application dépend toujours de l'accès IMAP basé sur un mot de passe, elle est déjà cassée ou le sera bientôt.
Les jetons OAuth ont une durée de vie courte (généralement 1 heure) et sont limités en portée. Même s'ils sont divulgués, ils ne peuvent pas être utilisés pour se connecter en tant qu'utilisateur, changer son mot de passe ou accéder à d'autres services. Vous n'utilisez jamais les identifiants de l'utilisateur.
Microsoft a terminé le retrait de l'authentification de base pour Exchange Online et les anciens protocoles IMAP en 2026. Toute application utilisant encore un nom d'utilisateur + mot de passe pour accéder aux boîtes aux lettres Outlook ou Microsoft 365 recevra des erreurs 401 Unauthorized.
Le stockage des mots de passe utilisateur - même hachés - crée une responsabilité en matière de conformité. Le principe de minimisation des données du RGPD exige de ne pas collecter ce dont vous n'avez pas besoin. Les auditeurs SOC2 signalent le stockage des identifiants.
Critique Les mots de passe d'application Google et les protocoles hérités de Microsoft ne sont plus suffisants pour les applications de production. Si vous créez un produit qui accède aux boîtes aux lettres des utilisateurs, un API de messagerie OAuth n'est pas optionnel – c'est la seule voie conforme en 2026.
Comment OAuth fonctionne pour les API de messagerie (étape par étape)
Le flux d'autorisation par code est le flux OAuth 2.0 standard pour les applications côté serveur qui ont besoin d'accéder à l'e-mail de l'utilisateur. Le comprendre de bout en bout vous aide à le mettre en œuvre correctement, à déboguer les échecs de jetons et à expliquer le flux à votre équipe de sécurité.
Vous construisez une URL avec votre client_id, une uri_de_redirection, la, la ci-jointe portée, un aléatoire état paramètre (protection CSRF), et type_de_réponse=code. L'utilisateur est redirigé vers l'écran de consentement de Google ou de Microsoft.
L'écran de consentement affiche le nom de votre application, son logo et les autorisations exactes que vous avez demandées. L'utilisateur approuve (accorde le consentement) ou refuse. Demander trop de scopes à cette étape est la cause la plus fréquente de rejet du consentement.
Après consentement, le fournisseur redirige vers votre uri_de_redirection avec un destin éphémère code paramètre (valide pendant ~10 minutes). Vérifier le état le paramètre correspond à ce que vous avez envoyé pour empêcher les attaques CSRF.
POST serveur à serveur au point de terminaison de jeton avec votre client_id, secret_client, le code, ou encore type_octroi=code_autorisation. Vous recevez un access_token et (si vous avez demandé l'accès hors connexion) un token_rafraîchissement.
Passez le jeton d'accès dans la Autorisation : Support en-tête sur chaque requête API. Lorsqu'il expire (généralement après 1 heure), utilisez le jeton de rafraîchissement pour obtenir un nouveau jeton d'accès sans interaction de l'utilisateur.
Tokens d'accès vs tokens de rafraîchissement : cycle de vie
Valide pendant 1 heure (Google) ou 1 heure (Microsoft). Transmis dans l'en-tête Autorisation à chaque appel d'API. Lorsqu'il expire, votre appel d'API OAuth par e-mail renvoie une erreur 401 - le signal de rafraîchissement.
Valide jusqu'à révocation (Google) ou 90 jours d'inactivité (Microsoft). Jamais envoyé aux points d'API - utilisé uniquement de serveur à serveur pour obtenir de nouveaux jetons d'accès. Doit être chiffré au repos.
Créez un flux OAuth unifié en quelques minutes
Éliminez la plomberie d'autorisation par fournisseur. Un seul appel à l'API Unipile remplace trois intégrations OAuth.
Flux OAuth par fournisseur : Google et Microsoft
Google et Microsoft implémentent chacun OAuth 2.0 différemment - points d'accès d'autorisation différents, scopes différents, points d'accès de jeton différents et processus de vérification différents. IMAP est le recours de secours basé sur les identifiants pour les fournisseurs sans OAuth standardisé. Voici ce que vous devez savoir pour chaque cas.
L'implémentation OAuth de Google utilise le flux standard du code d'autorisation. Le point de terminaison du jeton est https://oauth2.googleapis.com/token. La complexité critique est Google CASA (Cloud Application Security Assessment) : dès que votre application dépasse 100 utilisateurs, vous devez passer un examen de sécurité. Pour des scopes sensibles comme gmail.modifier ou gmail.lecture seule, une vérification de l'application est requise avant son utilisation en production. Pour une vérification complète Intégration approfondie de l'API Gmail, consultez notre guide dédié. Les détails d'implémentation se trouvent dans le Documentation Google OAuth Unipile.
Code d'autorisation Exchange # pour l'accès à Gmail + jetons d'actualisation
curl -X POST https://oauth2.googleapis.com/token \
-d "code=CODE_AUTORISATION" \
-d "client_id=VOTRE_CLIENT_ID" \
-d "client_secret=VOTRE_CLIENT_SECRET" \
-d "redirect_uri=https://yourapp.com/callback" \
-d "grant_type=authorization_code"
Réponse # : { "access_token": "...", "refresh_token": "...", "expires_in": 3600 }
Microsoft utilise sa plateforme d'identité (anciennement Azure AD v2). Le point de terminaison de jeton est https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token. La vérification de l'éditeur est requise avant que votre application API Oauth pour les e-mails puisse demander des étendues d'e-mail sensibles en production. Microsoft a déprécié l'authentification de base pour tous les protocoles Exchange Online - OAuth est obligatoire. Voir notre guide complet de Microsoft Graph pour le courrier électronique pour plus de détails, et le Documentation Microsoft OAuth Unipile pour référence de mise en œuvre.
Code d'échange # pour les jetons OAuth Microsoft
curl -X POST https://login.microsoftonline.com/common/oauth2/v2.0/token \
-d "code=CODE_AUTORISATION" \
-d "client_id=VOTRE_CLIENT_ID" \
-d "client_secret=VOTRE_CLIENT_SECRET" \
-d "redirect_uri=https://yourapp.com/callback" \
-d "grant_type=authorization_code" \
-d "scope=https://graph.microsoft.com/Mail.Read offline_access"
Réponse # : { "access_token": "...", "refresh_token": "...", "expires_in": 3600 }
IMAP n'est pas un fournisseur OAuth : c'est un protocole qui s'authentifie avec un nom d'utilisateur/mot de passe, ou des mots de passe d'application (tels qu'un mot de passe d'application Google ou un mot de passe généré par iCloud). C'est la solution de repli pour les serveurs de messagerie personnalisés, les domaines d'entreprise non hébergés sur Microsoft 365, et tout fournisseur sans flux OAuth standardisé. XOAUTH2 existait en tant qu'extension SASL IMAP pour un petit nombre de fournisseurs, mais il a été largement abandonné – Yahoo a cessé son implémentation propriétaire en 2022. Pour la plupart des déploiements IMAP, Unipile s'authentifie directement avec les identifiants. Voir le Guide d'intégration IMAP pour la configuration du serveur et les détails d'authentification.
import base64, imaplib
# Créer une chaîne XOAUTH2 à partir d'un jeton d'accès OAuth
déf construire_xoauth2(adresse_electronique_utilisateur, jeton_acces)
auth_str = utilisateur={user_email}\x01auth=Bearer {access_token}\x01\x01"
return base64.b64encode(auth_str.encode()).decode()
# : connexion via IMAP avec XOAUTH2
conn = imaplib.IMAP4_SSL("imap.mail.yahoo.com")
auth_str = construire_xoauth2("user@yahoo.com", jeton_d_accès)
conn.authentifier("XOAUTH2", lambda x : auth_str)La complexité cachée de l'OAuth multi-fournisseurs
La mise en œuvre d'une API OAuth pour l'e-mail d'un fournisseur prend quelques jours. La mettre en œuvre correctement pour Gmail, Outlook et IMAP – avec une gestion des jetons prête pour la production, une gestion des erreurs et la conformité – prend généralement 4 à 8 semaines de temps d'ingénierie. Voici pourquoi.
La console Google Cloud, le portail Azure et le réseau de développeurs Yahoo sont 3 tableaux de bord entièrement différents avec des UX différentes, des flux d'enregistrement d'applications différents et des exigences de vérification différentes. La rotation de toute credential touche les 3.
Les champs d'application sensibles de Gmail (y compris gmail.lecture seule) sont limités à 100 utilisateurs jusqu'à ce que vous ayez réussi l'évaluation CASA de niveau 2. Celle-ci comprend un laboratoire agréé par la CASA, un test d'intrusion et un audit de sécurité formel ; elle dure généralement entre 6 et 12 semaines et coûte entre 10 000 et 25 000 dollars.
Microsoft exige la vérification de l'éditeur pour les applications demandant des étendues d'e-mail sensibles. Sans cela, les utilisateurs voient un avertissement rouge "éditeur non vérifié" sur l'écran de consentement. Le processus de vérification nécessite un compte Microsoft Partner Network actif avec un domaine vérifié.
Les jetons de rafraîchissement de Google expirent après 6 mois d'inactivité (ou immédiatement si l'utilisateur les révoque). Les jetons de Microsoft expirent après 90 jours d'inactivité. Les jetons XOAUTH2 Yahoo/IMAP ont des durées de vie spécifiques au fournisseur. Votre couche de gestion des jetons doit gérer les 3 différemment.
Google, Microsoft et Yahoo affichent les écrans de consentement différemment - branding différent, descriptions de portée différentes, interfaces utilisateur différentes. Vos utilisateurs voient 3 flux différents en fonction de leur fournisseur de messagerie, créant une expérience utilisateur incohérente et des taux de désabonnement plus élevés.
Les points de terminaison OAuth changent. Les noms de portée sont dépréciés. De nouvelles exigences de sécurité sont ajoutées. Chaque fournisseur annonce des changements majeurs à des moments différents. Quelqu'un de votre équipe doit suivre 3 blogs de fournisseurs, 3 journaux de modifications et 3 calendriers de conformité – indéfiniment.
Éviter toute complexité OAuth
Authentification hébergée, gestion des scopes, gestion du rafraîchissement. Unipile s'occupe de tout pour que vous puissiez vous concentrer sur votre produit.
Architecture de l'API de messagerie OAuth : 3 approches comparées
Il existe 3 architectures pour construire une couche d'API d'e-mails OAuth. Chacune a un coût de mise en œuvre, une charge de maintenance et un profil de sécurité fondamentalement différents. Le bon choix dépend si la connectivité par e-mail est votre produit principal ou une fonctionnalité que vous proposez en parallèle de votre produit principal.
| Dimension | Fournisseur OAuth direct (x3) | Passerelle OAuth auto-hébergée | OAuth hébergé unifié (Unipile) Recommandé |
|---|---|---|---|
| Temps avant le premier courrier électronique lié | 3-7 jours (par fournisseur) | 2-4 semaines | 5 minutes |
| Flux OAuth à implémenter | 3 flux distincts | 3 flux + logique de routage | 1 point de terminaison hôte |
| Commentaire sur Google CASA | C'est à toi de t'en occuper (6 à 12 semaines, $10k+) | Vous vous en occupez | Géré par Unipile |
| Vérification Microsoft Publisher | Vous vous en occupez | Vous vous en occupez | Géré par Unipile |
| Gestion du rafraîchissement des jetons | 3 stratégies pour construire | Personnalisé par fournisseur | Automatique, transparent |
| API de lecture/envoi d'e-mails | 3 API différentes | Couche d'abstraction nécessaire | 1 API REST unifiée |
| Webhook sur les nouveaux e-mails | Push/pull par fournisseur | Personnalisé | Événements de webhook unifiés |
| Conformité SOC2 / RGPD | Votre responsabilité | Votre responsabilité | Unipile est certifié SOC2 |
| Maintenance en cours | Élevé (3 journaux des modifications des fournisseurs) | Elevé | Zéro - géré par Unipile |
| Meilleur pour | Produits natifs d'email à fournisseur unique | Grandes équipes avec une infrastructure dédiée | Toute équipe livrant rapidement |
Build ou Achat : API de messagerie OAuth hébergée en 5 minutes
Au lieu de créer 3 flux OAuth distincts, Unipile fournit un lien d'authentification hébergé qui gère pour vous l'authentification OAuth de Google, Microsoft Identity et IMAP. Votre application génère un lien, redirige l'utilisateur et reçoit une notification webhook lorsque la boîte aux lettres est connectée. L'API e-mail OAuth est alors immédiatement utilisable – aucune configuration de console, aucun examen CASA, aucune logique de rafraîchissement de jeton à implémenter.
Étape 1 : Générer un lien d'authentification hébergé
Un appel d'API pour créer une session d'authentification hébergée. Spécifiez le type de fournisseur et un nom pour le compte. Unipile renvoie une URL pour rediriger votre utilisateur vers l'écran de consentement OAuth.
// Connecter l'utilisateur Gmail via l'API email OAuth hébergée par Unipile
const response = await fetch(
'https://api6.unipile.com:13226/api/v1/hosted/accounts/link',
{
method: POST,
headers: {
'X-API-KEY': 'VOTRE_CLE_API_UNIPILE',
'Content-Type': 'application/json'
},
body: JSON.stringify({
type : 'Google',
nom : 'utilisateur_alice_123',
URL_de_redirection_en_cas_de_succès: 'https://yourapp.com/connecté',
url_redirection_echec: 'https://yourapp.com/erreur'
})
}
);
const { url, objet } = await réponse.json();
Rediriger l'utilisateur vers l'URL - Unipile gère le consentement OAuth
window.location.href = url;Étape 2 : Connecter un utilisateur Outlook
Même point d'arrivée, même schéma. Changement type à MICROSOFT. Pas de portail Azure, pas de vérification de l'éditeur à gérer de votre côté.
import demandes
# : connexion d'un utilisateur Outlook via l'API de messagerie OAuth d'Unipile
response = requêtes.poste(
"https://api6.unipile.com:13226/api/v1/hosted/accounts/link",
en-têtes={"X-API-KEY": "VOTRE_CLE_API_UNIPILE"},
json={
"type": "MICROSOFT",
"nom": "utilisateur_bob_456",
"url_de_redirection_en_cas_de_succès": "https://votreapplication.com/connecte"
}
)
url_authentification = response.json()["url"]
# Redirection vers auth_url - Flux d'authentification Microsoft géré par UnipileÉtape 3 : Recevoir le webhook sur account.connected
Une fois le consentement OAuth obtenu, Unipile déclenche un webhook vers votre point de terminaison. La charge utile de l'événement comprend le nouveau account_id - que vous enregistrez et utilisez pour toutes les opérations suivantes lire l'API des e-mails et API d'envoi d'e-mails appels.
Événement Webhook : Lorsqu'un utilisateur termine la procédure OAuth, Unipile envoie un compte.connecté événement à l'URL de votre webhook. La charge utile contient les account_id (enregistrer ceci), le provider (GOOGLE / MICROSOFT / IMAP) et l'adresse e-mail associée. C'est la seule information que vous devez conserver : Unipile gère tous les jetons OAuth en interne.
Évitez 8 semaines d'implémentation OAuth. Connectez les boîtes aux lettres en quelques minutes.
L'API de messagerie OAuth hébergée d'Unipile gère Google CASA, la vérification de l'éditeur Microsoft, XOAUTH2 et le rafraîchissement des jetons pour tous les fournisseurs. Vos utilisateurs lient leur boîte aux lettres via un flux hébergé unique - vous obtenez une API unifiée pour lire, envoyer et synchroniser.
Gestion des jetons OAuth : actualisation, révocation, rotation
La gestion des jetons est l'aspect le plus exigeant sur le plan opérationnel lors de la mise en place d'une API de messagerie OAuth. Les jetons d'accès expirent, les jetons de rafraîchissement sont révoqués par les utilisateurs, et votre système doit gérer tout cela de manière fluide, sous peine de voir vos utilisateurs perdre l'accès à leur boîte mail sans qu'ils s'en rendent compte.
Bonnes pratiques en matière de stockage des jetons
- Chiffrez les jetons d'actualisation au repos à l'aide de l'algorithme AES-256 ou d'un service KMS dans le cloud (AWS KMS, GCP Cloud KMS, Azure Key Vault). Ne les stockez jamais en clair dans votre base de données.
- N'enregistrez jamais les jetons d'accès ni les jetons d'actualisation. Dans les systèmes de journalisation structurés tels que Datadog ou Splunk, les champs contenant ces jetons doivent être masqués ou expurgés.
- Conservez les jetons dans un référentiel de secrets dédié (Vault, AWS Secrets Manager) plutôt que dans la base de données principale de votre application, afin de limiter l'ampleur des dégâts en cas de compromission de la base de données.
- Mettez en place la rotation des jetons : lorsque vous obtenez un nouveau jeton d'actualisation lors d'un appel d'actualisation (certains fournisseurs émettent un nouveau jeton à chaque utilisation), invalidez immédiatement l'ancien.
Gérer les échecs de rafraîchissement de manière élégante
Lorsqu'un jeton d'actualisation expire ou est révoqué, votre appel d'actualisation renvoie une erreur 400 ou 401. Votre API OAuth pour les e-mails doit détecter cette situation et déclencher un processus de réauthentification pour l'utilisateur, sans se contenter d'un échec silencieux. Le pire scénario serait qu'un utilisateur pense que ses e-mails sont lus, alors que son jeton est révoqué depuis des semaines. Mettez en place un contrôle explicite de l'état du compte et alertez les utilisateurs lorsqu'une réauthentification est nécessaire.
Domaines d'application OAuth : ce qu'il faut demander (et ce qu'il ne faut pas demander)
La réduction du champ d'application est à la fois une bonne pratique en matière de sécurité et une stratégie d'optimisation du consentement. Demander plus de droits que nécessaire incite les utilisateurs à hésiter (ou à refuser) lors de l'écran de consentement, et entraîne un examen plus minutieux lors des contrôles effectués par Google CASA et Microsoft Publisher.
| Portée | Fournisseur | Cas d'utilisation | Sensibilité | Avis sur CASA ? |
|---|---|---|---|---|
| gmail.lecture seule | Gmail | Lire tous les e-mails et toutes les métadonnées | Elevé | Oui - Niveau 2 |
| gmail.envoyer | Gmail | Envoyer un courriel en tant que l'utilisateur | Elevé | Oui - Niveau 2 |
| gmail.modifier | Gmail | Lire, envoyer, supprimer, classer | Elevé | Oui - Niveau 2 |
| libellés gmail | Gmail | Lire et gérer les étiquettes uniquement | Faible | Non |
| Mail.Read | Outlook | Lire tous les e-mails | Moyen | Vérification de l'éditeur |
| Mail.Send | Outlook | Envoyer un courrier en tant qu'utilisateur | Moyen | Vérification de l'éditeur |
| Mail.ReadWrite | Outlook | Lire, envoyer, supprimer, gestion des dossiers | Elevé | Vérification de l'éditeur |
| accès_hors_ligne | Outlook | Obtenir des jetons de rafraîchissement | Faible | Non |
| courriel-r | IMAP (Yahoo) | Lire les e-mails via IMAP/XOAUTH2 | Moyen | Examen du développeur Yahoo |
Jetons actualisés et réorganisés pour vous
Arrêtez d'écrire du code de cycle de vie de jetons. Connectez une boîte aux lettres une fois, Unipile maintient l'accès actif sur tous les fournisseurs.
Conformité : SOC2, RGPD, CASA
Une API d'e-mails OAuth qui gère les boîtes aux lettres des utilisateurs se situe à l'intersection de la conformité en matière de sécurité et de confidentialité. Voici les quatre cadres les plus susceptibles d'intéresser les acheteurs d'entreprise - et ce que le modèle de jeton d'OAuth signifie pour chacun d'eux.
Les auditeurs SOC2 examinent la gestion des jetons dans le cadre des critères de disponibilité et de confidentialité. Les jetons OAuth doivent être chiffrés au repos (AES-256 ou KMS), enregistrés en accès, et soumis à une politique de rotation formelle. Le stockage de jetons d'actualisation en clair constitue une constatation automatique. L'utilisation d'une API OAuth hébergée pour les e-mails comme Unipile (certifiée SOC2) déplace cette responsabilité.
Conformément au RGPD, votre application est un sous-traitant de données lorsqu'elle accède au contenu des e-mails des utilisateurs. Vous avez besoin d'un Accord de Traitement des Données (ATD) avec votre fournisseur d'infrastructure API de messagerie OAuth. La révocabilité de l'OAuth satisfait directement l'article 17 (droit à l'effacement) - lorsqu'un utilisateur révoque, votre accès prend fin immédiatement. Documentez votre base juridique pour l'accès aux données de messagerie (généralement le consentement via le flux OAuth).
Dès que votre application API de messagerie Gmail OAuth dépasse les 100 utilisateurs disposant de périmètres d'accès sensibles, Google bloque toute nouvelle inscription d'utilisateur jusqu'à ce que vous ayez satisfait aux exigences du niveau 2 du programme CASA. Cela nécessite un test d'intrusion réalisé par un laboratoire agréé CASA, un questionnaire de sécurité et un rapport d'évaluation officiel soumis à Google. Durée : 8 à 16 semaines. Coût : 10 000 à 25 000 TWD. Les applications vérifiées obtiennent le badge " Vérifié par Google " sur leur écran de consentement.
API d'e-mail OAuth : tarification et modèles de coûts
Les API de fournisseurs " gratuits " de Google et Microsoft masquent des coûts réels importants. Voici un modèle de coût réaliste pour la mise en œuvre d'une API d'e-mail OAuth à grande échelle – couvrant la voie directe du fournisseur par rapport aux API unifiées.
Les API de Google et Microsoft sont techniquement gratuites au niveau des appels d'API. Cependant : le niveau 2 de Google CASA coûte entre 10 000 et 25 000 TP4T, auxquels s'ajoutent au moins trois mois de travail d'ingénierie. La vérification des éditeurs pour Microsoft nécessite un compte Partner Network et une vérification légale du domaine. Temps d'ingénierie requis pour mettre en place trois flux, la gestion des jetons et la gestion des erreurs : 6 à 10 semaines. Maintenance annuelle : 2 à 4 semaines par an et par fournisseur.
L'API de messagerie OAuth d'Unipile comprend la conformité à tous les fournisseurs (CASA, vérification de l'éditeur), la gestion des jetons et une API de messagerie unifiée sous un même abonnement. Pour les équipes qui intègrent la connectivité par e-mail comme une fonctionnalité (pas comme un produit), le calcul du retour sur investissement est simple : des semaines de temps d'ingénierie économisées par rapport à un coût mensuel de l'API. Voir le Comparer les fournisseurs d'API d'e-mail guide pour une ventilation complète des coûts.
Pièges courants lors de l'implémentation de l'e-mail OAuth
Voici les erreurs les plus courantes que les développeurs commettent lorsqu'ils créent pour la première fois une API de messagerie OAuth - et ce qu'il faut faire à la place.
Google invalide les jetons de rafraîchissement si l'utilisateur n'a pas utilisé votre application pendant 6 mois. Votre appel de rafraîchissement de jeton renvoie grant_invalide. Correction : implémenter une " vérification de l'état du jeton " périodique qui effectue un appel léger à l'API Gmail pour chaque compte lié au moins une fois tous les 30 jours afin d'éviter l'expiration due à l'inactivité.
Demande gmail.modifier quand on a seulement besoin de gmail.lecture seule gonfle votre écran de consentement et amène les utilisateurs à abandonner le flux OAuth. Il augmente également votre exigence de niveau CASA. Demandez toujours la portée minimale nécessaire. Vous pouvez demander des étendues supplémentaires progressivement plus tard.
La limite de portée sensible de Gmail à 100 utilisateurs est le principal obstacle à la croissance pour les implémentations d'API d'e-mails OAuth. Anticipez la revue CASA avant d'atteindre 50 utilisateurs : la revue prend 8 à 16 semaines, et votre croissance d'utilisateurs sera bloquée en attendant.
Une journalisation détaillée des requêtes qui capture les en-têtes d'autorisation enregistrera vos jetons d'accès en texte brut. Implémentez un middleware de nettoyage de journaux qui censure Porteur [TOKEN] schémas avant que les journaux ne soient écrits dans un support de stockage persistant.
Certains serveurs de messagerie d'entreprise fonctionnent derrière des configurations IMAP personnalisées qui ne prennent pas en charge OAuth. Votre API de messagerie OAuth doit disposer d'une voie de repli élégante pour les fournisseurs IMAP uniquement. Intégrez cela dès le premier jour dans votre flux de connexion de compte, sinon vous exclurez un segment important d'utilisateurs B2B. Voir notre Intégration IMAP guide pour le modèle de repli complet.
Construire au lieu d'assembler des fournisseurs
Intégrez votre e-mail avec OAuth dès aujourd'hui. Offre gratuite, sans carte de crédit, portée complète pour Gmail et Microsoft disponible.
Questions fréquemment posées
Les questions les plus courantes des développeurs lors de la création d'une intégration d'API de messagerie OAuth - répondues précisément.
https://oauth2.googleapis.com/token, portées dans le gmail.* Espace de noms. Pour Outlook (couvrant Outlook.com, Microsoft 365 et Exchange Online) : Plateforme d'identité Microsoft, point de terminaison de jeton https://login.microsoftonline.com/common/oauth2/v2.0/token, scopes sous https://graph.microsoft.com/. Pour IMAP : IMAP n'est pas un fournisseur OAuth. Il utilise des identifiants nom d'utilisateur/mot de passe ou mot de passe d'application. XOAUTH2 existait en tant qu'extension SASL pour un petit nombre de fournisseurs mais a été largement déprécié.type_de_consentement=rafraîchir_jeton. Pour Google : POST vers https://oauth2.googleapis.com/token. Pour Microsoft : POST à https://login.microsoftonline.com/common/oauth2/v2.0/token. Si vous recevez grant_invalide, le jeton d'actualisation a expiré ou a été révoqué - demandez à l'utilisateur de se réauthentifier.gmail.lecture seule lire, gmail.envoyer envoyer, gmail.modifier pour lecture/écriture/suppression complète. Pour Outlook : Mail.Read lire, Mail.Send envoyer, Mail.ReadWrite pour un accès complet - plus accès_hors_ligne pour obtenir des jetons d'actualisation. Demandez toujours le champ d'application minimal requis par votre cas d'utilisation. Voir le Page de l'API de messagerie pour des recommandations de portée spécifiques à un cas d'utilisation.libellés gmail (pas soumis à la CASA), lancez le processus CASA avant d'atteindre 50 utilisateurs (cela prend 8 à 16 semaines), ou utilisez une API d'e-mail OAuth hébergée comme Unipile dont l'infrastructure a déjà passé l'examen CASA - supprimant ainsi complètement cette exigence pour votre application./api/v1/hosted/accounts/link. Vous passez un type (GOOGLE, MICROSOFT, or IMAP) et Unipile génère une URL d'authentification hébergée. L'utilisateur complète le consentement OAuth sur l'infrastructure d'Unipile, qui a passé la vérification CASA de Google et la vérification de l'éditeur de Microsoft. Après consentement, Unipile envoie un webhook avec le account_id. Toute la gestion et le rafraîchissement des jetons sont gérés en interne.grant_invalide. Votre API OAuth d'e-mails doit intercepter cela, marquer le compte lié comme déconnecté et avertir l'utilisateur avec un lien de réauthentification. Avec Unipile, un webhook de révocation se déclenche automatiquement pour que votre système soit notifié en temps réel – aucun interrogatoire nécessaire.
FR 
EN 
ES 
DE 
IT 
BR 
NL 
PL 
TR