Le token broker OAuth, quand il sert et quand c'est du cargo cult

J'ai construit un token broker dont je n'avais techniquement pas besoin. Je l'ai gardé quand même, et les deux moitiés de cette phrase méritent une explication.

Dernier volet de ma série photo : après le paysage des sources, les headers contradictoires et les accents Dropbox, la question d'architecture qui revient à chaque fois.

Ce que PKCE a changé

L'argument historique du broker : « le client mobile ne peut pas garder le client secret, donc il faut un serveur ». C'était vrai avant PKCE.

Avec l'Authorization Code Flow + PKCE, le client génère un code_verifier éphémère par session d'autorisation. Il n'y a aucun secret durable à protéger dans l'app. Les fournisseurs sérieux (Google, Microsoft, Dropbox) supportent tous ce flow pour les clients publics, sans client secret.

Conséquence : une app mobile peut faire son OAuth de bout en bout, stocker les tokens dans le Keychain ou EncryptedSharedPreferences, et parler directement à l'API. C'est propre, documenté, prévu pour.

Le broker n'est donc pas une obligation de sécurité. C'est un choix d'architecture. Et comme tout choix, il a de bonnes et de mauvaises raisons.

Les bonnes raisons d'avoir un broker

Les refresh tokens hors device. Si le broker échange le code et garde les refresh tokens côté serveur, un device volé ou compromis n'expose que des access tokens courts. Pour des scopes sensibles (toute une photothèque), c'est un vrai gain.

La révocation centrale. Utilisateur supprimé, abus détecté, incident : côté serveur, vous coupez tous les accès en une requête. Côté device, vous espérez que l'app se lance pour recevoir l'ordre.

Le travail hors session. Si votre produit doit accéder aux photos quand l'app est fermée (import en tâche de fond côté serveur, traitement batch), les tokens doivent vivre côté serveur. Ce n'est plus un choix, c'est le besoin produit qui décide.

L'hygiène des secrets et des scopes. Un broker permet la rotation des secrets via Secret Manager sans re-livrer l'app, et la vérification côté serveur que les scopes demandés restent read-only : personne ne peut élargir les permissions depuis un client modifié. Ce sont ces raisons-là qui m'ont fait garder le mien.

Bonus d'architecture, appris en regardant une facture : le broker gère les tokens, jamais les octets. Proxifier les images elles-mêmes par la Cloud Function double vos coûts d'egress pour zéro bénéfice. Les binaires transitent en direct entre le device et le cloud photo.

Les mauvaises raisons

• « C'est plus sécurisé » sans menace identifiée : non. Un broker ajoute une surface d'attaque (le serveur détient les tokens de tous les utilisateurs), un point de panne et du travail de conformité RGPD. Concentrer tous les refresh tokens au même endroit n'est un gain que si le reste suit.
• « Tout le monde fait comme ça » : le tutoriel que vous copiez a été écrit avant PKCE, ou pour un provider qui ne le supportait pas.
• « On en aura peut-être besoin » : vous ajoutez aujourd'hui une Cloud Function, sa surveillance, ses secrets et ses mises à jour, pour un besoin hypothétique.

Ma grille de décision

Trois questions, dans l'ordre :

1. Le produit doit-il accéder aux données quand l'app est fermée ? Oui → broker, fin de la discussion.
2. Les scopes sont-ils assez sensibles pour justifier des refresh tokens hors device, et avez-vous la maturité ops pour protéger ce serveur ? Oui aux deux → broker.
3. Sinon → PKCE direct, tokens dans le stockage sécurisé de l'OS, et une Cloud Function de moins à maintenir.

L'honnêteté sur le « pas indispensable » compte : un broker mal protégé est pire que pas de broker du tout.

À retenir

• PKCE a supprimé l'argument « pas de secret sur mobile » : le flow direct est légitime et prévu pour.
• Le broker se justifie par trois besoins précis : tokens hors device, révocation centrale, accès hors session.
• Sans un de ces besoins, c'est du cargo cult qui coûte de l'ops et concentre le risque.

Votre broker actuel répond à un besoin identifié, ou à un tutoriel de 2019 ?