v3.37.0
OAuth2 & OIDC

Enregistrer un client

Sur cette page

Un client (« agent » OAuth2 dans la console) représente une application autorisée à demander des jetons au fournisseur OAuth2 du royaume.

Créer un client dans la console#

Menu Clients, puis Créer un agent. L’assistant compte trois étapes :

  1. Identité : l’identifiant du client (son client_id, définitif), des labels facultatifs et les URI de redirection.
  2. Sécurité : le mot de passe du client (son client_secret), la méthode d’authentification, les types d’autorisation et les scopes.
  3. Résumé : contrôle avant création. Le secret n’est plus affiché ensuite.
Étape Sécurité de l'assistant de création d'un client : mot de passe, méthode d'authentification, types d'autorisation et scopes Étape Sécurité de l'assistant de création d'un client : mot de passe, méthode d'authentification, types d'autorisation et scopes
Étape Sécurité : méthode d’authentification (1), types d’autorisation, Authorization Code et Refresh Token cochés par défaut (2), scopes (3).

Avec ssoadm, le type d’agent est OAuth2Client :

bash 
./ssoadm.sh create-agent --realm /partenaires --agenttype OAuth2Client --agentname portail-rh \
    --attributevalues "userpassword=<secret>"

Authentifier le client#

La méthode d’authentification du client au point de terminaison des jetons (« Méthode d’authentification ») accepte :

Faites défiler le tableau
MéthodePrincipe
client_secret_basicSecret dans l’en-tête Authorization: Basic (par défaut)
client_secret_postSecret dans le corps de la requête (client_id, client_secret)
private_key_jwtAssertion JWT signée par la clé privée du client ; TOSIAM la vérifie avec la clé publique ou le JWKS déclaré dans la fiche
tls_client_authCertificat client émis par une autorité, reconnu par son sujet
self_signed_tls_client_authCertificat auto-signé, reconnu par sa clé publique publiée dans un JWKS

Un client public (application mobile, SPA), qui ne peut pas garder de secret, se déclare avec le type de client Public dans la fiche ; associez-le à PKCE (voir Fournisseur OAuth2).

La fiche du client#

Après création, la fiche du client regroupe ses réglages en onglets :

Faites défiler le tableau
OngletContenu
GénéralNom, groupe, mot de passe, type de client, scopes et scopes par défaut, URI de redirection, durées de vie propres au client
AvancéTypes d’autorisation, types de réponse, méthode d’authentification, PKCE obligatoire, consentement implicite, jetons sans état, jetons d’accès au format JWT
OpenID ConnectClaims, URI de redirection après déconnexion, déconnexion back-channel, max_age et ACR par défaut, niveau d’authentification
Signature et chiffrementClés du client (clé publique, JWKS ou jwks_uri), algorithmes de signature et de chiffrement de l’ID token, de userinfo et des objets de requête, certificats liés
TLS mutuelSujet attendu du certificat client, en-tête HTTP du certificat derrière un proxy

L’option Émettre les jetons d’accès sous forme de JWT (onglet Avancé) remet au client des jetons d’accès JWT signés ; elle exige un algorithme de signature asymétrique côté fournisseur (voir Algorithme de signature).

Authentification par certificat (mTLS)#

Pour tls_client_auth, renseignez dans l’onglet TLS mutuel une seule catégorie d’identité attendue : le nom distinctif du sujet, ou des noms alternatifs (DNS, URI, adresse électronique ou IP). Derrière un proxy inverse qui termine le TLS, indiquez l’en-tête HTTP qui porte le certificat et son format.

Onglet TLS mutuel de la fiche d'un client : nom distinctif du sujet et noms alternatifs Onglet TLS mutuel de la fiche d'un client : nom distinctif du sujet et noms alternatifs
L’onglet TLS mutuel (1) et le nom distinctif du sujet attendu (2).

Le fonctionnement complet (jetons liés au certificat, self_signed_tls_client_auth, formats d’en-tête) est décrit dans l’article mTLS.

Enregistrement dynamique#

Une application peut s’enregistrer elle-même auprès du point de terminaison /connect/register du royaume (RFC 7591), annoncé dans le document de découverte (registration_endpoint).

  • Enregistrement protégé (par défaut) : la requête doit porter un jeton d’accès dont le scope contient dynamicClientRegistration, obtenu par un client déjà déclaré.
  • Enregistrement ouvert : avec le réglage Autoriser l’enregistrement dynamique ouvert des clients du fournisseur, aucun jeton n’est demandé. À réserver aux environnements de test.
  • Le réglage Désactiver le point d’accès d’enregistrement dynamique ferme complètement /connect/register.
bash 
curl -X POST "https://<serveur>/tosiam/oauth2/partenaires/connect/register" \
     -H "Authorization: Bearer <jeton avec le scope dynamicClientRegistration>" \
     -H "Content-Type: application/json" \
     -d '{
           "client_name": "Portail RH",
           "redirect_uris": ["https://rh.example.com/callback"],
           "grant_types": ["authorization_code", "refresh_token"],
           "token_endpoint_auth_method": "client_secret_basic",
           "scopes": ["openid", "profile", "email"]
         }'

Les scopes se passent dans un tableau scopes, et non dans la chaîne scope de la RFC 7591, qui serait ignorée.

La réponse contient le client_id et le client_secret générés, ainsi que l’adresse de gestion du client (registration_client_uri) et, selon le réglage Générer des jetons d’accès à l’enregistrement (activé par défaut), un registration_access_token pour la consulter ou la modifier.

Mis à jour le