Olivier Brun
Architecte cloud & cybersécurité freelance, certifié AWS, Azure, GCP. Spécialiste IAM et protocoles d'identité (OIDC, SAML, Token Exchange).
Dans un écosystème cloud‑natif, microservices et applications legacy cohabitent. SAML, OAuth2, OpenID Connect (OIDC) et l'extension Token Exchange (RFC 8693) sont les piliers de la sécurité fédérée. Cet article détaille leur mise en œuvre concrète avec Keycloak et Ory (Hydra, Kratos).
📜 SAML 2.0 : le vétéran des SSO d'entreprise
Security Assertion Markup Language repose sur XML et l'échange d'assertions signées entre un fournisseur d'identité (IdP) et un fournisseur de service (SP). Incontournable dans les environnements d'entreprise (ADFS, Shibboleth), SAML brille par sa maturité pour le SSO transverse.
- ✔ Avantages : SSO robuste, support des applications legacy, métadonnées IdP/SP standardisées.
- ⚠ Inconvénients : lourd (XML), peu adapté aux APIs / applications natives, absence de délégation fine.
Keycloak peut agir comme IdP SAML ou comme proxy (broker) SAML vers OIDC. Configuration via Admin Console ou fichier saml-sp-metadata.xml.
⚡ OAuth2 & OIDC : le duo moderne
OAuth 2.0 (RFC 6749) est le framework d'autorisation déléguée permettant d'obtenir un accès limité à des ressources protégées via des access tokens (souvent JWT). Différents grant types existent : Authorization Code, Client Credentials, Device Code...
Mais OAuth2 seul n'est PAS une authentification. C'est là qu'intervient OpenID Connect (OIDC) : une couche d'identité au‑dessus d'OAuth2. OIDC ajoute l'id_token (JWT contenant les claims d'identité), l'endpoint UserInfo, et standardise la découverte (.well-known/openid-configuration).
Exemple : SPA avec Keycloak
// Initialisation de Keycloak JS
const keycloak = new Keycloak('keycloak.json');
keycloak.init({ onLoad: 'login-required' })
.then(authenticated => {
console.log(keycloak.idToken); // preuve d'authentification (OIDC)
console.log(keycloak.token); // access_token OAuth2
});
L'access_token sert à appeler des APIs protégées, tandis que l'id_token prouve l'identité de l'utilisateur.
🔄 OAuth2 Token Exchange (RFC 8693) : la délégation avancée
Dans les architectures microservices, on a souvent besoin de transformer / échanger un token existant pour changer d'audience, de scope, ou pour de l'impersonation. Le Token Exchange définit le grant_type dédié : urn:ietf:params:oauth:grant-type:token-exchange. Permet :
- 🔄 Échange d'un access_token pour un autre token (audience différente, scopes réduits).
- 👤 Impersonation / delegation : obtenir un token au nom d'un autre utilisateur.
- 🔀 Fédération entre fournisseurs : échange de token OIDC externe vers un token local.
- 📦 Workload identity : service‑to‑service avec token d'identité pour chaînage.
Exemple d'appel Token Exchange avec Keycloak :
POST /realms/myrealm/protocol/openid-connect/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&client_id=myclient
&client_secret=xxx
&subject_token=eyJhbGciOiJ...
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&requested_token_type=urn:ietf:params:oauth:token-type:jwt
&audience=target-api
🧩 Comparaison : SAML / OAuth2 / OIDC / Token Exchange
| Protocole/Extension | Usage principal | Format message | Idéal pour |
|---|---|---|---|
| SAML 2.0 | SSO entre organisations | XML (Redirect/POST) | Applications legacy, fédérations institutionnelles |
| OAuth2 | Autorisation déléguée (API) | JSON / JWT | APIs, délégation machine‑to‑machine |
| OpenID Connect | Authentification fédérée + id_token | JSON / JWT | Apps modernes (SPA, mobile, backends) |
| Token Exchange (RFC8693) | Échange/transformation de tokens | JSON / grant_type | Microservices, impersonation, cross‑IdP |
🛡️ Keycloak : maîtrise opérationnelle
Keycloak (Quarkus) est la solution open source la plus mature pour la gestion d'identité. Support natif OIDC, SAML, et Token Exchange.
▶ Token Exchange avec audience et scope
curl -X POST https://keycloak.local/realms/demo/protocol/openid-connect/token \
-d "grant_type=urn:ietf:params:oauth:grant-type:token-exchange" \
-d "client_id=backend-service" \
-d "client_secret=XXXX" \
-d "subject_token=$USER_ACCESS_TOKEN" \
-d "subject_token_type=urn:ietf:params:oauth:token-type:access_token" \
-d "audience=inventory-api"
▶ Brokerage SAML → OIDC
Keycloak excelle dans la fédération hybride : configurez un IdP SAML externe (ex: ADFS) comme fournisseur d'identité, puis exposez des applications OIDC. Le mapping des attributs est entièrement personnalisable.
🐙 Ory : l'écosystème cloud‑natif
Ory propose une suite de composants : Ory Hydra (serveur OAuth2/OIDC durci), Ory Kratos (gestion d'identité utilisateur, MFA), Ory Keto (moteur Zanzibar) et Ory Oathkeeper (proxy d'authentification).
🔹 Hydra + Token Exchange (RFC 8693)
Hydra implémente nativement Token Exchange. Exemple d'échange pour un service cible :
POST /oauth2/token HTTP/1.1
Host: hydra.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&client_id=my-client
&client_secret=xxx
&subject_token=user-jwt
&subject_token_type=urn:ietf:params:oauth:token-type:jwt
&audience=payment-service
🔹 Intégration OIDC avec Kratos + Hydra
Kratos gère le cycle de vie des utilisateurs (inscription, login, recovery), Hydra sert les tokens. Support complet de openid‑connect, claims personnalisés, UI custom. Utilisé en production par de nombreux acteurs fintech.
📌 Stratégies & recommandations terrain
✅ Quand choisir SAML ?
Intégration avec des partenaires institutionnels qui ne supportent que SAML. Keycloak sert alors de proxy SAML‑to‑OIDC.
✅ Quand privilégier OIDC ?
Applications web modernes, mobiles, SPAs, backends microservices. Standard actuel, supporté par Keycloak, Ory Hydra, etc.
✅ Power‑up Token Exchange : scénarios "must‑have"
- Service‑to‑service / identity chaining : un service obtient un token pour un autre service.
- Impersonation sécurisée (admin agissant en tant qu'utilisateur). Keycloak supporte l'impersonation avec rôle dédié.
- Réduction de privilège (downscoping) : échange d'un token large contre un token avec scopes restreints.
⚙️ Déploiement Keycloak vs Ory : critères
Keycloak est tout‑en‑un avec interface admin riche, idéal pour une DSI. Ory est plus "API‑first", parfait pour Kubernetes et CI/CD (chaque composant scalable séparément).
🚀 Conclusion : vers une architecture IAM résiliente
Maîtriser OAuth2, OIDC, SAML et le Token Exchange est indispensable pour construire des plateformes sécurisées à grande échelle. Keycloak offre un contrôle granulaire ; Ory propose une approche modulaire ultra‑performante pour le cloud‑natif.
# Vérification rapide d'un token échangé (introspection avec Hydra)
curl -X POST https://hydra/oauth2/introspect \
-d "token=$EXCHANGED_TOKEN" \
-d "client_id=api-gateway"
Les outils modernes permettent de combiner SAML legacy avec OIDC moderne. Adoptez Token Exchange pour gagner en flexibilité, et laissez Keycloak ou Ory gérer la complexité.
✉️ Besoin d'un accompagnement sur Keycloak, Ory, ou votre stratégie IAM ? Contactez-moi – je vous aide à déployer ces briques en production.