SSO et Keycloak : sécuriser ses applications sans réinventer l'authentification

Pourquoi ne plus gérer les mots de passe soi-même

Stocker des mots de passe, gérer la réinitialisation, le verrouillage anti-bruteforce et la double authentification représente un chantier à part entière — et chaque raccourci devient une faille. Le Single Sign-On (SSO) délègue cette responsabilité à un fournisseur d'identité : l'application ne voit jamais le mot de passe, elle reçoit un jeton d'identité vérifiable.

Keycloak, solution IAM open source, joue ce rôle : il centralise utilisateurs, connexions sociales, MFA et autorisations pour toutes vos applications, web comme mobiles.

1. Comprendre les acteurs : OpenID Connect au-dessus d'OAuth 2.0

OAuth 2.0 encadre la délégation d'accès (autoriser une app à agir pour un utilisateur), tandis qu'OpenID Connect (OIDC) ajoute l'authentification : un id_token signé (JWT) qui prouve qui est l'utilisateur.

Le flux à privilégier aujourd'hui est l'Authorization Code + PKCE : - L'application redirige vers Keycloak avec un code_challenge. - L'utilisateur s'authentifie côté Keycloak (mot de passe, MFA, Google, etc.). - Keycloak renvoie un code que l'application échange, avec le code_verifier, contre access_token, id_token et refresh_token. - Même si le code fuit, il est inutilisable sans le vérificateur : c'est ce qui rend PKCE indispensable sur les clients publics (SPA, mobile).

2. Les concepts clés de Keycloak

• Realm : un espace isolé (utilisateurs, clients, rôles). Créez un realm par environnement ou par organisation, jamais de test dans le realm master.
• Client : chaque application enregistrée (frontend, API, mobile) avec son type d'accès : confidential (secret côté serveur) ou public (PKCE, sans secret).
• Rôles et groupes : les rôles realm pour les droits transverses (admin, user), les rôles client pour les permissions fines d'une API.
• Mappers : ils injectent rôles et attributs dans les jetons pour que l'API autorise sans appeler Keycloak à chaque requête.

3. Intégrer Keycloak côté web (Next.js)

• Ne mettez jamais le client secret dans le navigateur : l'échange code-contre-jetons se fait dans une Route Handler ou un backend.
• Sessions serveur : stockez les jetons côté serveur (session chiffrée, cookie httpOnly) et n'exposez au client que l'état de session.
• Refresh rotation : un access_token court (5 minutes) + refresh_token renouvelé à chaque usage limite l'impact d'un vol de jeton.
• Déconnexion complète : appelez le endpoint end_session (RP-Initiated Logout) pour tuer la session SSO, sinon l'utilisateur reste connecté chez le fournisseur.

4. Intégrer Keycloak côté mobile (React Native / Expo)

• Client public + PKCE : pas de secret embarqué dans l'application, il serait extractible en quelques minutes.
• Deep links : configurez un schéma de redirection (myapp://auth) et utilisez expo-auth-session ou react-native-app-auth pour le flux système (Custom Tabs / ASWebAuthenticationSession).
• Stockage : conservez les jetons dans le stockage sécurisé (expo-secure-store, Keychain/Keystore), jamais dans AsyncStorage en clair.
• Renouvellement silencieux : rafraîchissez avant expiration et gérez le cas hors-ligne avec une file d'attente de requêtes.

5. Checklist de mise en production

• HTTPS partout, cookies Secure + SameSite=Lax, durées de vie courtes pour les access tokens.
• Moindre privilège : scopes et rôles minimaux par client, comptes de service dédiés pour les appels machine-to-machine.
• Realm exporté et versionné : export JSON du realm dans le dépôt pour recréer les environnements à l'identique.
• Sauvegarde et haute dispo : baseLiv externalisée (PostgreSQL), au moins deux instances derrière un reverse proxy.
• Journalisation : activez les events Keycloak (connexions, erreurs) vers votre SIEM pour détecter les anomalies.

Conclusion

SSO avec Keycloak, c'est un seul système d'authentification bien durci au lieu de N implémentations artisanales : vos applications web et mobiles délèguent la connexion, reçoivent des jetons standards et appliquent des rôles cohérents. Le coût initial de configuration se rentabilise dès la deuxième application — et vos utilisateurs ne retiennent qu'un seul mot de passe.