OAuth est utile, mais Google et Microsoft en font une porte d’accès contrôlée

OAuth est une amélioration de sécurité

Abandonner l’authentification Basic, les mots de passe durables et les identifiants aux privilèges étendus était une bonne décision. OAuth permet des permissions limitées, des jetons d’accès de courte durée, des connexions révocables et un meilleur contrôle de ce qu’une application peut réellement faire.

Le standard est ouvert. Il explique comment une application peut demander et obtenir un accès au nom d’un utilisateur. Il n’exige pas lui-même que les développeurs soumettent des documents commerciaux, des preuves organisationnelles, des vidéos de démonstration ou une demande d’admission à un opérateur de plateforme. Cette couche supplémentaire vient des règles de l’écosystème.

Un standard ouvert peut malgré tout devenir une porte fermée

SMTP et IMAP sont apparus dans un Internet construit autour de l’interopérabilité. Un fournisseur pouvait exploiter un serveur de messagerie, un développeur construire un client, et les deux communiquer grâce à des standards documentés.

OAuth ne détruit pas cette ouverture. Mais lorsque l’accès à la boîte mail dépend en plus de l’accord du propriétaire de la plateforme, la question décisive change : l’utilisateur autorise-t-il l’application, ou Google ou Microsoft décide-t-il si cette application peut seulement être autorisée ?

Une revue de sécurité demande à une application de démontrer un traitement sûr des données utilisateurs, lié à une finalité. Le contrôle d’accès à l’écosystème demande au contraire régulièrement à son éditeur de justifier pourquoi l’application peut y exister. Cet article défend l’importance de cette distinction, tout en reconnaissant la sensibilité des données de messagerie.

Microsoft 365 : le consentement s’arrête souvent à la frontière du tenant

L’obstacle Microsoft décrit ici n’est souvent pas une revue vidéo à la Google. Il tient à l’interaction entre Microsoft Entra ID, la vérification des éditeurs, le consentement administrateur et les politiques propres à chaque tenant Microsoft 365.

Microsoft recommande de limiter le consentement utilisateur aux éditeurs vérifiés et à certaines permissions classées à faible risque. Les administrateurs peuvent le restreindre davantage ou le désactiver. Un utilisateur peut vouloir explicitement une intégration de messagerie et se voir malgré tout demander l’approbation d’un administrateur.

La vérification de l’éditeur peut aussi être décisive pour les applications multitenants plus récentes. Parmi d’autres exigences, l’éditeur doit disposer d’un compte Microsoft AI Cloud Partner Program vérifié, lié à l’inscription de l’application. C’est un signal de confiance compréhensible, mais il lie aussi l’usage de l’autorisation ouverte aux procédures commerciales et partenaires de Microsoft.

Google et Gmail : la revue des périmètres peut devenir un frein au produit

Le processus Gmail est plus centralisé. Les classifications décrites à la publication désignent gmail.send comme sensible et gmail.readonly comme restreint. Selon leur usage, les applications publiques nécessitant ces permissions peuvent devoir fournir des preuves de marque et de domaine, une justification précise des périmètres et une vidéo de démonstration.

La vidéo doit montrer le parcours OAuth complet, l’écran exact de consentement et les fonctions utilisant chaque périmètre demandé. Si la justification est refusée ou si, selon l’évaluateur, la présentation ne correspond pas à l’application, d’autres questions, de nouveaux enregistrements ou une nouvelle soumission peuvent suivre.

L’article publié cite des estimations non contraignantes de Google : deux à trois jours ouvrés pour la marque, dix jours ouvrés pour les périmètres sensibles et jusqu’à six semaines pour les périmètres restreints. Stocker ou transmettre des données Gmail restreintes sur un serveur peut aussi exiger une évaluation de sécurité annuelle. Il s’agit des descriptions et estimations associées à la publication d’origine, pas d’une nouvelle promesse de délai d’approbation.

La limite de 100 utilisateurs a des conséquences concrètes

En mode test, l’accès est limité à au plus 100 utilisateurs de test explicitement listés, dont les autorisations expirent après sept jours dans les conditions décrites par les recommandations Google liées. Les applications non vérifiées peuvent aussi rencontrer un plafond à vie de 100 nouveaux utilisateurs.

Si un périmètre sensible ou restreint est refusé, les utilisateurs ne peuvent plus accéder à ce périmètre non approuvé. Un plafond ou un refus n’est donc pas un simple avertissement administratif : il peut arrêter la fonction que l’utilisateur tente d’activer.

Pourquoi Hassolux a besoin de ces permissions

Hassolux est une plateforme de travail pour les entreprises du bâtiment et de services, réunissant projets, documents, factures et communication dans un processus traçable. Un utilisateur autorisé active volontairement sa connexion facultative à la messagerie.

Pour Microsoft 365, les accès délégués Mail.Read et Mail.Send permettent de lire les messages entrants au nom de l’utilisateur connecté et d’envoyer les courriels de documents qu’il demande explicitement. Pour Gmail, gmail.readonly récupère les messages sélectionnés et les pièces jointes PDF/XML, tandis que gmail.send sert séparément aux messages sortants initiés par l’utilisateur.

Hassolux recherche uniquement la période choisie par l’utilisateur, lit l’expéditeur, l’objet et l’heure de réception, puis importe les pièces jointes PDF ou XML prises en charge pour le traitement des factures. Il ne déplace, ne marque, ne modifie ni ne supprime les messages Gmail. L’envoi est séparé et n’intervient qu’après une action précise de l’utilisateur. La connexion peut être supprimée et également révoquée chez le fournisseur.

Demander un périmètre plus réduit peut ici devenir techniquement contradictoire. Une permission limitée aux métadonnées ne fournit ni le contenu des messages ni les factures jointes ; l’application ne peut pas importer un document qu’elle n’a pas le droit de lire. Pour cette fonction visible, gmail.readonly est demandé comme la permission Google la plus étroite donnant l’accès nécessaire, et non comme une collecte préventive de droits plus larges.

Notre expérience : des démonstrations répétées et malgré tout un refus

Pour Hassolux, la vérification Google a dépassé la mise en œuvre de l’intégration. Nous avons produit plusieurs vidéos de démonstration, attendu les cycles de revue, répondu aux courriels de suivi et expliqué pourquoi le périmètre était nécessaire. Son refus retire davantage qu’une permission API abstraite : il retire la fonction pour laquelle un utilisateur veut connecter sa propre boîte mail.

La sensibilité des données de messagerie justifie des exigences de sécurité élevées. Une revue doit néanmoins distinguer une collecte excessive d’une permission minimale techniquement nécessaire. Sinon, le moindre privilège devient impossible à satisfaire : la plateforme ne propose aucun périmètre plus étroit utilisable, mais rejette celui qui existe comme trop large. Il s’agit du récit et de l’argumentation de l’auteur sur son expérience de revue, pas de l’affirmation que toutes les applications reçoivent le même traitement.

Ce qu’un processus de vérification équitable devrait offrir

Les améliorations proposées visent à préserver la protection tout en rendant possibles les intégrations indépendantes.

• Des critères clairs vérifiables à l’avance : les développeurs doivent connaître les usages permis avant l’implémentation.
• Des décisions précises et compréhensibles : un refus doit identifier l’incompatibilité technique ou liée à la confidentialité concrète.
• Des preuves proportionnées : évaluer le flux de données, le lieu de stockage et le risque réel plutôt que principalement la taille de l’éditeur.
• Des revues réutilisables : un petit changement de produit ne doit pas relancer tout le processus de preuve.
• Un recours technique pertinent : tenir compte des cas où le fournisseur ne propose aucun périmètre fonctionnel plus étroit.
• Un choix utilisateur effectif : consentement éclairé et révocation à tout moment doivent peser davantage que des plafonds généraux de plateforme.

L’autorisation ouverte doit rester ouverte

Nous soutenons OAuth, une authentification renforcée et une protection cohérente des données utilisateurs. C’est précisément pourquoi il doit être possible de critiquer les mécanismes d’approbation ajoutés au-dessus. La sécurité doit protéger des applications nuisibles sans augmenter à la légère les barrières à l’entrée ni renforcer le contrôle des propriétaires de plateformes sur les logiciels interopérables.

Un standard peut être ouvert sur le papier. En pratique, l’ouverture exige aussi que les développeurs indépendants, start-up et petites entreprises logicielles puissent l’utiliser dans des conditions transparentes et équitables. L’avenir d’Internet ne devrait pas dépendre d’une poignée de plateformes autorisant chaque intégration techniquement nécessaire.