OpenID Connect (OIDC) prend en charge plusieurs mécanismes d’authentification des clients auprès de ses endpoints, notamment le Token Endpoint, l’Introspection Endpoint et le Revocation Endpoint. Ces mécanismes permettent au client, qu’il s’agisse d’une application confidentielle ou publique, de prouver son identité de manière sécurisée à l’OpenID Provider (OP). Le choix du mécanisme dépend des exigences de sécurité et des capacités du client. Voici une présentation détaillée des mécanismes d’authentification supportés par OpenID Connect.
Basic Authentication
L’un des mécanismes d’authentification les plus simples et les plus largement supportés dans OIDC est l’authentification HTTP Basic. Dans cette méthode, le client ID et le client secret sont concaténés en une seule chaîne, séparés par deux-points, puis encodés en Base64. La chaîne obtenue est placée dans le header Authorization de la requête HTTP.
Par exemple, le header ressemble à ceci :
POST /token HTTP/1.1Host: server.example.comAuthorization: Basic <Base64(client_id:client_secret)>Cette méthode est principalement utilisée pour les échanges avec le Token Endpoint, l’Introspection Endpoint et le Revocation Endpoint. Facile à implémenter et compatible avec la plupart des systèmes, elle repose toutefois fortement sur l’utilisation de HTTPS pour chiffrer les identifiants transmis.
Post Authentication
Lorsque la Basic Authentication n’est pas supportée ou pas souhaitée, les identifiants du client peuvent être envoyés dans le corps de la requête HTTP. Le client transmet client_id et client_secret comme paramètres de formulaire, avec les autres paramètres requis par l’endpoint appelé.
Par exemple, le corps de la requête peut contenir :
POST /token HTTP/1.1Host: server.example.comContent-Type: application/x-www-form-urlencoded
grant_type=client_credentials&client_id=<client_id>&client_secret=<client_secret>Cette méthode est fonctionnellement équivalente à la Basic Authentication, mais elle est généralement considérée comme moins élégante. Elle est supportée par les mêmes endpoints : Token, Introspection et Revocation.
Private Key JWT Authentication
Private Key JWT est une méthode d’authentification robuste qui renforce la sécurité en supprimant la nécessité de transmettre un client secret statique. À la place, le client crée un JSON Web Token (JWT) signé avec sa clé privée. Ce JWT est envoyé à l’OpenID Provider, qui vérifie la signature à l’aide de la clé publique correspondante.
Le JWT contient plusieurs claims, dont :
iss(issuer) : le client ID.sub(subject) : le client ID.aud(audience) : l’URL du token endpoint.exp(expiration time) : la durée de validité du jeton.
Cette méthode est particulièrement adaptée aux clients qui ont besoin d’un haut niveau de sécurité, car elle évite les risques liés aux secrets statiques. Elle est couramment utilisée avec le Token Endpoint.
Mutual TLS (mTLS) Authentication
Le Mutual TLS (mTLS) est un mécanisme d’authentification du client dans lequel celui-ci présente un certificat X.509 lors du handshake TLS. L’OpenID Provider valide le certificat pour authentifier le client. Ce mécanisme offre un haut niveau de sécurité en s’appuyant sur des identités cryptographiques et garantit que le canal de communication est sécurisé.
Le mTLS est généralement utilisé pour les applications à haute sécurité et permet aussi de lier les jetons au certificat du client (certificate-bound tokens), ce qui empêche leur utilisation frauduleuse en cas d’interception. Il est supporté par les endpoints Token, Introspection et Revocation.
Client Assertion Authentication
À l’instar de Private Key JWT, la Client Assertion Authentication permet à un client de s’authentifier en présentant une assertion signée. Toutefois, au lieu de s’appuyer sur une clé privée, l’assertion peut utiliser d’autres secrets, comme des client secrets. L’assertion est envoyée dans la requête de jeton et contient des claims similaires à ceux de Private Key JWT.
Ce mécanisme est très flexible et particulièrement utile dans les systèmes fédérés ou multipartites, où les identifiants client traditionnels ne conviennent pas toujours.
Pas d’authentification du client (clients publics)
Pour les clients publics, comme les single-page applications (SPA) ou les applications mobiles, l’authentification du client n’est pas toujours requise. Ces clients n’utilisent généralement pas d’identifiants confidentiels et s’appuient plutôt sur des flows comme l’Authorization Code flow avec PKCE (Proof Key for Code Exchange). Même si le client lui-même n’est pas authentifié, des mécanismes comme PKCE garantissent la sécurité du processus d’autorisation.