Faut-il déléguer son identité à un tiers, ou la garder en main ?
Chaque fois qu'une entreprise confie son authentification à un service externe — Auth0, Okta, Google Identity — elle accepte un compromis : simplicité contre dépendance. Pour les PME et les éditeurs de logiciels qui gèrent plusieurs applications, ce compromis mérite d'être reconsidéré. Un SSO (Single Sign-On) auto-hébergé, construit sur des standards ouverts, offre une alternative crédible. Laravel Passport, qui implémente le protocole OAuth 2.0, permet de le construire sans réinventer la roue cryptographique.
Cet article explore l'architecture et les arbitrages du "build vs buy" appliqués à l'authentification, en s'appuyant sur le guide publié par Hoang Manh Cam sur dev.to.
Le problème concret : quatre applications, quatre tables users
Imaginez une structure typique : un back-office interne, un portail client, une application mobile et un outil d'analytics. Chacun a sa propre base, son propre formulaire de connexion, son propre flux de réinitialisation de mot de passe. Quand un collaborateur arrive, on crée quatre comptes. Quand il part, on espère avoir pensé à tout désactiver.
C'est exactement ce que résout un SSO. Un seul point d'authentification, une seule source de vérité, et les applications enfants apprennent l'identité de l'utilisateur via un échange de tokens standardisé.
L'approche "Buy" : rapide mais contraignante
Les solutions SaaS comme Auth0 ou Keycloak cloud résolvent ce problème en quelques heures. Mais elles introduisent :
- Une dépendance critique sur un tiers pour chaque connexion de vos utilisateurs
- Des données d'identité hébergées à l'extérieur, ce qui peut poser des problèmes RGPD selon les contextes
- Un coût variable qui explose avec le volume d'authentifications
- Une personnalisation limitée sur les règles métier (MFA conditionnel, rôles complexes, fusion de comptes)
L'approche "Build" avec Passport : vous êtes l'Identity Provider
Avec Laravel Passport, vous implémentez un serveur d'autorisation OAuth 2.0 complet. Vous possédez la table users, vous émettez les codes et les tokens, vous conservez les clés de signature. La bibliothèque s'occupe de la mécanique du protocole — le flux Authorization Code, la gestion des scopes, la rotation des tokens — pendant que vous gardez la main sur toutes les décisions d'identité.
L'architecture cible décrite dans l'article source se compose :
- D'un Portail Central : le serveur OAuth 2.0, qui héberge la page de login et gère les sessions maîtres
- De sites enfants (Site A, B, C) : des clients OAuth qui redirigent vers le portail et reçoivent un token en retour
OAuth 2.0 Authorization Code Flow : le protocole derrière le SSO
Comprendre le flux est essentiel pour déboguer et sécuriser l'implémentation.
1. Utilisateur clique 'Connexion' sur Site A
2. Site A redirige vers Portail Central avec client_id + redirect_uri + state
3. Portail authentifie l'utilisateur (login/password)
4. Portail redirige vers Site A avec un code d'autorisation à usage unique
5. Site A échange le code contre un access_token (appel serveur-à-serveur)
6. Site A appelle /api/user avec l'access_token pour récupérer l'identité
Le paramètre state (étape 2) est critique : il prévient les attaques CSRF sur le callback OAuth. Laravel génère et vérifie ce nonce automatiquement via Socialite ou un package dédié côté client.
Ce que Passport gère pour vous
- La génération et le stockage des paires de clés RSA pour signer les tokens
- La table
oauth_clients pour enregistrer les applications enfants
- Les endpoints standards :
/oauth/authorize, /oauth/token, /oauth/token/revoke
- La gestion des scopes pour un contrôle granulaire des permissions
Ce que vous gérez vous-même
- La logique d'authentification de l'utilisateur (hash du mot de passe, 2FA, verrouillage de compte)
- L'écran de consentement (ou son absence, pour des applications internes de confiance)
- La propagation des rôles et attributs métier dans la réponse
/api/user
- La révocation des tokens lors d'une déconnexion globale
Considérations de sécurité à ne pas négliger
Autoheberger un Identity Provider est une responsabilité sérieuse. Quelques points d'attention :
PKCE obligatoire pour les clients publics. Si une application mobile ou une SPA doit s'authentifier, le flux Authorization Code doit être couplé à PKCE (Proof Key for Code Exchange). Passport v13 le supporte nativement.
Rotation des refresh tokens. Activer la rotation garantit qu'un refresh token volé devient inutilisable après sa première utilisation. C'est un paramètre de configuration dans Passport.
Isolation des clés de signature. Les clés RSA générées par php artisan passport:keys doivent être stockées hors du dépôt Git, idéalement dans un secret manager (AWS Secrets Manager, HashiCorp Vault) injecté en variable d'environnement.
Déconnexion globale. Le SSO crée un état de session distribué. Une déconnexion du portail central doit déclencher la révocation des tokens sur tous les sites enfants — ce qui nécessite soit un webhook de révocation, soit des tokens à courte durée de vie (expires_in faible + refresh token rotation).
HTTPS partout, y compris en développement. OAuth 2.0 repose sur la sécurité de la couche transport. Les redirect_uri doivent être enregistrées en HTTPS en production, et les déviations doivent être bloquées strictement.
Quand choisir cette approche ?
L'auto-hébergement SSO avec Passport est pertinent si :
- Vous avez plusieurs applications PHP/Laravel à fédérer
- Vos données utilisateurs sont sensibles et doivent rester sur votre infrastructure (santé, finance, juridique)
- Vous avez des règles d'authentification métier complexes que les solutions SaaS ne couvrent pas
- Votre volume d'authentifications rendrait les coûts SaaS prohibitifs à l'échelle
En revanche, si vous démarrez une application unique avec une équipe réduite, l'investissement initial d'un SSO maison n'est probablement pas justifié. Auth0 ou même un simple laravel/socialite avec Google suffisent.
Conclusion
Laravel Passport offre une base solide pour construire un Identity Provider aux standards OAuth 2.0 sans dépendance externe. L'article de Hoang Manh Cam démontre qu'il est possible de monter un SSO complet sur une installation Laravel vierge, avec un périmètre délibérément restreint à l'authentification pure.
Le vrai enjeu n'est pas technique : c'est la question de la souveraineté. Qui doit savoir quand vos utilisateurs se connectent ? Qui doit détenir les clés de leur identité numérique ? Pour beaucoup d'organisations, la réponse justifie amplement l'investissement dans un SSO auto-hébergé.
