Cedric Abonnel
108 lines
7.2 KiB
Markdown
108 lines
7.2 KiB
Markdown
*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.).
|
||
|
||
1. Connectez-vous à **Keycloak Admin Console**.
|
||
2. Sélectionnez le **realm** cible.
|
||
3. 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**
|
||
|
||
1. Activer **Authorization** dans l’onglet `Settings`.
|
||
2. Aller dans l’onglet **Authorization** > `Authorization settings` > activer `Enable`.
|
||
|
||
### B. Créer une **policy** :
|
||
|
||
* **Type** : Group ou Role
|
||
* Exemple : `Groupe = /clients/myapp` ou `Role = 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.
|