Accueil > OpenID Connect OAuth Serveur dédié > Développer > OpenID Connect > id_token_hint : ré-authentification silencieuse du sujet avec l’ID (...)

id_token_hint : ré-authentification silencieuse du sujet avec l’ID Token

Toutes les versions de cet article : [English] [français]

L’authentification du sujet (subject, sub) avec l’ID Token est une option du flux de code OpenID Connect Authorization.
Pour passer la certification OpenID Connect, il est nécessaire de terminer le test "OP-Req-id_token_hint".
La bibliothèque oauth2-server-php de Brent Shaffer ne traite pas id_token_hint. OAuthSD devra donc s’en occuper.

Le cas d’utilisation consiste à appeler Authorize à l’aide de prompt = ’none’ et à transmettre l’ID Token par le paramètre id_token_hint.

La spécification stipule :

id_token_hint
OPTIONNEL. Le jeton ID précédemment émis par le serveur d’autorisations est transmis en tant qu’identifiant de la session d’authentification actuelle ou passée de l’utilisateur final avec le client. Si l’utilisateur final identifié par le jeton ID est connecté ou est connecté par la requête, le serveur d’autorisations renvoie une réponse positive. sinon, il DEVRAIT retourner une erreur, telle que login_required. ... Le serveur d’autorisation n’a pas besoin d’être répertorié en tant qu’audience du jeton ID lorsqu’il est utilisé en tant que valeur id_token_hint.

Comment OAuthSD Implémente le traitement id_token_hint

Si l’appel à Authorize inclut le paramètre id_token_hint, nous vérifierons la signature du Jeton d’Identité JWT. Si Ok, nous adopterons la valeur de la déclaration sub pour définir l’identifiant de l’utilisateur final (user_id) et nous continuerons normalement avec le traitement de prompt = ’none’.

L’expression "ou est connecté par la requête" peut couvrir un mécanisme tel que la réauthentification silencieuse (SRA). C’est ce que OAuthSD permet de faire : le processus revient alors à étendre la session OIDC, c’est à dire rafraîchir le cookie SLI, que l’utilisateur soit connecté ou non.
Le contrôleur authorize répondra avec un code d’autorisation, et l’application redemandera les jetons, ce qui provoquera le rafraîchissement du jeton d’accès.
Ainsi, l’utilisateur sera (re)connecté, vu du serveur, pour la pleine durée de vie du nouveau jeton d’accès. Nous n’accorderons pas beaucoup de confiance à cette méthode, aussi l’acr_value sera fixé à 1.

L’administrateur peut contrôler le processus avec les constantes de configuration REAUTHENTICATE_BY_ID_TOKEN et DO_SRA_ON_ID_TOKEN (définies par défaut sur true).

Remarque de sécurité

Lorsque l’on fait une authentification avec prompt = ’none’, on devrait toujours y associer le paramètre id_token_hint. Plus exactement, interroger Authorize avec prompt = ’none’ sans id_token_hint ne peut être considéré comme une authentification, mais comme une simple information sur la connexion de l’utilisateur déclaré.

Notes :
- Si user_id est forcé par l’enregistrement du client, la déclaration subject du jeton d’identité doit être identique, sinon le processus échouera.
- login = "none" exclut l’invite de l’utilisateur. L’expression « ou est connecté par la demande » peut couvrir un mécanisme tel que la ré-authentification silencieuse (SRA). C’est ce que OAuthSD permet de faire.

Voyez également :
- OpenID Connect : SSO, management de session etc..

[dnc68]