Protocoles SSO : les bases¶

Pourquoi le SSO ?¶

Le Single Sign-On (SSO), ou authentification unique, évite à l’utilisateur de saisir ses identifiants dans chaque application. Une application délègue la vérification de l’identité à un service de confiance. Une fois authentifié, l’utilisateur peut accéder à d’autres applications compatibles, selon les sessions et règles de sécurité configurées.

Le SSO ne signifie pas que toutes les applications partagent un mot de passe ou une session technique unique. Chaque application valide un message ou un jeton selon un protocole. L’autorisation métier demeure sous la responsabilité de l’application, même si Keycloak fournit des rôles ou attributs.

Comment les rôles coopèrent-ils ?¶

Fournisseur d’identité (IdP) : authentifie l’utilisateur et émet une preuve d’identité. Keycloak peut jouer ce rôle.
Fournisseur de services (SP) : terme courant dans SAML pour l’application qui délègue l’authentification.
Relying Party (RP) : terme OIDC pour l’application cliente qui fait confiance à un fournisseur OIDC.
Navigateur / agent utilisateur : transporte fréquemment les redirections entre l’application et l’IdP.
Annuaire d’utilisateurs : peut être interne à Keycloak ou externe (par ex. LDAP/Active Directory).

Pour OIDC, on parle surtout d’OP (OpenID Provider, le fournisseur OIDC) et de RP. Pour SAML, on parle d’IdP et de SP. Ces rôles sont analogues, mais les protocoles et leurs objets ne sont pas interchangeables.

sequenceDiagram
    actor U as Utilisateur
    participant B as Navigateur
    participant A as Application (RP / SP)
    participant I as Keycloak (IdP / OP)
    U->>B: Demande une ressource protégée
    B->>A: Accès à l'application
    A-->>B: Redirection vers Keycloak
    B->>I: Demande d'authentification (OIDC ou SAML)
    I->>U: Authentification et éventuel MFA
    U->>I: Preuve d'identification
    I-->>B: Code OIDC ou réponse SAML
    B->>A: Retour de protocole
    A->>I: Échange / validation côté serveur si requis
    A-->>U: Session applicative et page autorisée

Session et déconnexion¶

Une session Keycloak représente la connexion de l’utilisateur au realm ; une session applicative est créée par chaque application après validation du résultat. Elles ont des durées et des cycles de vie distincts. La suppression de l’une n’entraîne pas toujours immédiatement la suppression de l’autre. OIDC propose notamment des mécanismes de déconnexion et SAML des messages de logout, mais leur prise en charge dépend des clients, des URL, des versions et de la configuration. Les jetons déjà émis peuvent rester valides jusqu’à expiration, sauf contrôles supplémentaires.

OIDC et SAML 2.0 en bref¶

Aspect	OpenID Connect (OIDC)	SAML 2.0
Fondations	Couche d’identité au-dessus d’OAuth 2.0	Norme XML d’échange d’assertions et de protocoles SSO
Format habituel	JSON / JWT (JWS, parfois JWE)	XML, souvent signé ; chiffrement possible
Éléments centraux	ID token, access token, claims, endpoints	Assertion, AuthnRequest, Response, métadonnées
Échanges navigateur	Redirections HTTP, retour avec code, puis échange de jeton	HTTP-Redirect et HTTP-POST, selon les messages
Usages courants	Applications web modernes, mobiles et API	SSO d’entreprise et applications historiques / SaaS
Découverte / configuration	Document OIDC Discovery et JWKS	Métadonnées XML de l’IdP et du SP
Vocabulaire	OP et RP ; client OAuth	IdP et SP
Consommation	Bibliothèque OIDC, validation des jetons et claims	Bibliothèque SAML, validation XML/signatures et conditions

Le choix dépend des capacités de l’application, des exigences de l’organisation et de l’écosystème existant. OIDC n’est pas « OAuth avec un nom différent » : OAuth délègue l’accès à une ressource, tandis qu’OIDC ajoute une couche standard d’authentification. Voir OIDC en détail et SAML 2.0 en détail.