Cedric Abonnel
7.2 KiB
Keycloak est un outil puissant pour la gestion des identités et des accès. Dans cet article, nous allons voir comment configurer un client OAuth 2.0 dans Keycloak, en détaillant toutes les options importantes, et en restreignant l’accès aux utilisateurs ou groupes autorisés uniquement.
🧱 1. Prérequis
- Un Keycloak fonctionnel (v15+ recommandé)
- Les droits d’administration sur un realm
- Une application (client) souhaitant s’authentifier via OAuth 2.0
🛠️ 2. Création d’un client OAuth 2.0
Dans Keycloak, un client représente toute application ou service qui souhaite interagir avec le système d’authentification pour authentifier des utilisateurs ou obtenir des informations sur eux. Cela peut être une application web, une API, une application mobile ou encore un service tiers. Le client est en quelque sorte un consommateur de l’identité, et c’est à travers lui que les échanges avec Keycloak se font.
Chaque client est enregistré dans un realm (l’espace logique d’authentification dans Keycloak) avec un identifiant unique, appelé client_id. Cet identifiant est utilisé par l’application lorsqu’elle initie une demande d’authentification ou tente d’obtenir un jeton d’accès. Un client peut être configuré de différentes manières selon son type et son usage : il peut être public (par exemple une application JavaScript qui n’a pas de secret), confidentiel (une application serveur qui possède un secret partagé), ou encore de type bearer-only, c’est-à-dire une API qui ne déclenche pas elle-même l’authentification mais qui attend des requêtes déjà munies d’un jeton.
Dans Keycloak, le client définit les paramètres de sécurité : les flux d’authentification autorisés (code, implicite, mot de passe, client_credentials), les URL de redirection autorisées, les origines web pour le support CORS, la durée de vie des jetons, ou encore les claims (informations) que l’on souhaite injecter dans les tokens.
Un client peut aussi être associé à des rôles spécifiques ou à des scopes personnalisés. Cela permet de gérer les droits d’accès de manière fine, en s’assurant que seuls certains utilisateurs ou groupes peuvent utiliser une application donnée. Il est également possible de lier des politiques d'autorisation à un client pour restreindre dynamiquement l’accès selon des règles (groupes, rôles, attributs utilisateur, etc.).
- Connectez-vous à Keycloak Admin Console.
- Sélectionnez le realm cible.
- Menu Clients > Create client.
Options de base :
| Champ | Description |
|---|---|
| Client ID | Identifiant unique du client. Visible dans les tokens. Exemple : myapp-client |
| Client Type | Choisir OpenID Connect |
| Client Protocol | Par défaut : openid-connect (OAuth 2.0). Alternatif : saml. |
| Root URL | URL de base de redirection pour les applications web. |
Cliquez sur Save pour accéder à toutes les options.
⚙️ 3. Configuration du client
A. Settings
| Option | Valeur typique | Description |
|---|---|---|
| Client Authentication | ON / OFF | Requiert un secret (ON) ou public (OFF) |
| Authorization Enabled | OFF par défaut |
Activer pour gérer les autorisations internes |
| Access Type | confidential, public, bearer-only |
Type d’application (voir plus bas) |
| Standard Flow Enabled | ON | Active le flux d’autorisation (code) |
| Implicit Flow Enabled | OFF (⚠️ déconseillé) | Active le flux implicite |
| Direct Access Grants | ON | Permet l’authentification via mot de passe (grant_type=password) |
| Service Accounts Enabled | ON (si machine to machine) | Utilise le client comme un compte de service |
| Valid Redirect URIs | https://app.example.com/* |
URI(s) autorisées pour les redirections |
| Web Origins | + ou domaines CORS autorisés |
Obligatoire si accès depuis navigateur JS |
| Base URL | https://app.example.com/ |
Page par défaut post-login |
| Admin URL | Pour backchannel logout | Optionnel |
B. Credentials
- Affiche le Client Secret (pour les clients confidentiels).
- Possibilité d’utiliser des JWT signés (client assertion).
🔑 4. Types de clients
| Type | Description |
|---|---|
| Confidential | Application backend avec secret. Ex : Web server |
| Public | Application JS/mobile sans secret |
| Bearer-only | Client backend n’initie pas d’auth, mais vérifie les tokens |
🧑🤝🧑 5. Restreindre l’accès aux utilisateurs/groupes
A. Méthode recommandée : Configurer une politique d’accès
- Activer Authorization dans l’onglet
Settings. - Aller dans l’onglet Authorization >
Authorization settings> activerEnable.
B. Créer une policy :
- Type : Group ou Role
- Exemple :
Groupe = /clients/myappouRole = access-myapp
C. Créer une permission
- Type : Client Scope Permission
- Associer à la policy créée
- Appliquer à la ressource “client” ou à des scopes (ex:
openid,profile)
🔍 7. Options avancées
- Fine grain session settings : durée de session, idle timeout
- Token Settings : durée de vie des access/refresh tokens
- Client Scopes : définir les claims par défaut (email, profile, etc.)
- Mapper des claims personnalisés dans les tokens (ex : groupes, fonctions)
- Backchannel Logout : URL appelée lors d’un logout global
📌 Conclusion
Configurer un client OAuth 2.0 dans Keycloak permet une intégration sécurisée avec vos applications, que ce soit via des tokens d’accès ou des scopes personnalisés. N’oubliez pas de restreindre l’accès au client pour éviter qu’il soit utilisé par des utilisateurs non autorisés.