Plugin OAuth2 Client pour SPIP

[JMarc_64 (Jean-Marc)]

Bonjour tous,

Je travaille actuellement sur un plugin OAuth2 Client pour SPIP, en cours de finalisation, avec pour objectif de proposer un socle commun pour les plugins ayant besoin de dialoguer avec des API OAuth2 (Dropbox, Google, API internes, etc.), sans dépendance externe (pas de Composer, pas de librairie tierce).

Principes généraux

Implémentation OAuth2 (RFC 6749)

Support des flux :

• authorization_code
• refresh_token
• client_credentials

Gestion complète du cycle de vie des tokens :

• stockage en métas SPIP
• expiration
• rafraîchissement automatique

API procédurale simple (oauth2_client_xxx)

Aucun écran de configuration : les paramètres OAuth2 sont fournis dynamiquement à l’appel

Le plugin repose sur 3 API publiques :

• oauth2_client_get_authorization_url(): Construit l’URL d’autorisation OAuth2
• oauth2_client_get_token() : Appelle le endpoint token OAuth2
• oauth2_client_get_access_token() : Retourne un access_token valide en utilisant le refresh_token si nécessaire (dérivée des 2 précédentes).

L’architecture fonctionnelle repose sur:
Les providers :

• Provider Generic : endpoints fournis inline lors de l’appel
• Providers spécifiques : dédiés pour des APIs particulières (authentification client, paramètres spécifiques). Ils n’ont pas vocation à intégrer ce plugin mais peuvent être ajoutés afin d’étendre la classe générique; Il suffit de la placer dans un dossier provider/MonProvider.php (plugin ou squelettes) .

Les grants
Les grants implémentent les différents flux OAuth2 :

• AuthorizationCode
• RefreshToken
• ClientCredentials
  Chaque grant est une classe dédiée, permettant d’en ajouter de nouveaux si nécessaire.

Pipelines
Le plugin propose 3 pipelines permettant aux plugins tiers de modifier les composants OAuth2 :

• oauth2_client_authorization_provider: intervenir sur le provider (Classe) utilisé pour modifier l’URL d’autorisation
• oauth2_client_token_provider: intervenir sur le provider (Classe) utilisé pour l’échange ou le rafraîchissement du token
• oauth2_client_grant: modifier le grant (Classe) OAuth2 utilisé

Ces pipelines sont appelés après les factories correspondantes, ce qui permet une extensibilité sans modifier le cœur du plugin.

Une v0 est actuellement disponible sur git.spip.net/spip-contrib-extensions/oauth2_client. Une documentation est en cours de rédaction dans le README.md

Avant publication sur Contrib, je serais preneur d’éventuels retours sur :

• l’API exposée
• la structure providers / grants
• les pipelines et points d’extension
• les cas d’usage éventuels (OpenID, API internes, etc.)

Les retours de développeurs SPIP intéressés pour tester ou challenger l’architecture sont également les bienvenus.
Merci d’avance

[maieul (Maïeul Rouquette)]

@JMarc_64

Aucun écran de configuration : les paramètres OAuth2 sont fournis dynamiquement à l’appel

c’est à dire ? concrètement c’est à chaque site qui utilise cela de se brancher via un pipeline php ou un truc du genre ?

[rastapopoulos]

Non c’est juste un client, donc c’est à chaque plugin qui a besoin de se connecter ailleurs avec OAuth d’appeler les fonctions PHP fournies, avec les bons paramètres (et donc c’est à chacun de ces plugins d’avoir leur propre configuration si besoin). Si j’ai bien compris

[JMarc_64 (Jean-Marc)]

Du genre, dans une v2 du plugin dropbox (export de fichiers sur Dropbox), pour obtenir mon token:

$token = oauth2_client_get_access_token($app, [
        'provider'     => 'dropbox',
        'client_id'     => $client_id ?? null,
        'client_secret' => $client_secret ?? null,
    ]);

Là, j’ai créé un provider spécifique (Classe=Dropbox) uniquement pour ne pas à avoir à saisir en plus les 2 urls (autorisation + token) dans le Provider Generic (enregistrté une fois pour toutes dans la classe Dropbox)
ça va plus vite sans avoir à gérer les autorisations, token et refresh_token dans chauque plugin qui fait des appels Oauth2.

[rastapopoulos]

Et bé c’est super d’avoir un truc à jour pour ça, merci beaucoup. Ça peut être utile pour plein de besoin différents, donc c’est bien d’avoir un truc « agnostique » comme ça !

[JMarc_64 (Jean-Marc)]

@rastapopoulos

Non c’est juste un client, donc c’est à chaque plugin qui a besoin de se connecter ailleurs avec OAuth d’appeler les fonctions PHP fournies, avec les bons paramètres (et donc c’est à chacun de ces plugins d’avoir leur propre configuration si besoin). Si j’ai bien compris

Effectivement, il ne fait rien tout seul, il aide juste les autres (plugins…) à faire.

[maieul (Maïeul Rouquette)]

Ok je comprend mieux.

Moi je tique sur provider, cela me semble un peu trop generique comme terme. Il y a pas que OAuth2 qui a des provider :).

Autre point quitte à faire de la prog OBJET (ce en quoi je suis favorable), avoir des interfaces plutot que des extensions de class ?

[JMarc_64 (Jean-Marc)]

Pourquoi pas « Source » qu’on retrouve dans la littérature Spipienne plutôt que « Provider » ? Sinon Connecteur ?

D’autre part , tu as en tête des exemples de plugin comportant des objets avec interfaces ? Je ne vois pas trop…

[maieul (Maïeul Rouquette)]

En fait le problèpme c’est pas Source vs Provider. C’est que Provider c’est generique.

Pour des interfaces, le plugin formidable_pdf fait cela.

On peut se prendre un temps si tu veux pour que je t’expose en vocal l’intêret de ce type de dev

[JMarc_64 (Jean-Marc)]

@maieul

On peut se prendre un temps si tu veux pour que je t’expose en vocal l’intêret de ce type de dev

Je suis preneur ! Juste auparavant jeter un coup d’oeil formidable_pdf pour ne pas partir de zéro. Je te fais signe. Et par la même occasion échanger sur le « Provider » car tu m’as définitivement perdu

[nicod]

Ah ben merci tiens, au passage, je vais jeter un œil à comment tu as structuré ça.

[JMarc_64 (Jean-Marc)]

Oui tu me diras ! Au passage, il reste encore pas mal de logs en mode debug le temps de stabiliser ça .
Merci

Le 27 janv. 2026 à 20:39, nicod_ via Discuter de SPIP noreply@discuter.spip.net a écrit :

	nicod_ I’m only in it for the money. Janvier 27

Ah ben merci tiens, au passage, je vais jeter un œil à comment tu as structuré ça.

---

Voir le sujet ou répondre à cet e-mail pour répondre.

Pour vous désabonner de ces e-mails, cliquez ici.

[maieul (Maïeul Rouquette)]

Je pense qu’en plus vu le projet, avoir des interfaces a encore plus de sens que dans mon cas, car le projet est précisment generique, ce qui n’est pas le cas dans formidable pdf.

Pour faire court, je pense qu’il y a 3 trucs qui feront gagner en qualité

1. interface
2. autoloader
3. namespace

Et ca tombe bien, ca fait partie des choses où je voulais proposer une formation dessus.

[nicod]

Je répondais à @maieul en fait

Mais j’irai voir oauth2_client aussi, j’ai justement un projet qui devrait débarquer dans les semaines à venir avec du Keycloak, il me semble que c’est en lien.

[nicod]

Déjà c’est top le readme en markdown pour un début de doc.
Pour info, si tu veux référencer ce plugin sur contrib.spip.net un jour (ce qui est encouragé), on a un modèle qui permet justement d’insérer un readme de git.spip.net directement dans un article sur Contrib (une sorte d’embed).
Ensuite on peut faire des PR sur le readme, ce qui met à jour Contrib, pratique (merci aussi à @maieul pour ça).

[maieul (Maïeul Rouquette)]

Ah mais le plugin pour readme ç’est pas moi. C’est @b_b

[nicod]

Oups ! Alors rendons à César, tout ça…

Merci @b_b

[JMarc_64 (Jean-Marc)]

Super ! Un format de formation comme celui que tu avais pris pour ta formation Git était top

[JMarc_64 (Jean-Marc)]

@nicod Oui, je vais certainement tester le modèle pour alimenter contrib depuis le readme.

Pour un accès avec Keycloak, il faudra certainement que j’implémente préalablement dans mon plugin OIDC (et/ou PKCE), ne serait-ce que pour récupérer et retourner l’id_token.

[b_b]

Si mes souvenirs sont bons, je n’ai rien fait là dessus à part proposer l’idée