L’écosystème DFC utilise le serveur d’authentification des communs.org. Une mise à jour importante de ce serveur d’authentification a introduit deux problèmes mineurs dans notre prototype. Le premier posait problème lors de la déconnexion de l’utilisateur. Le second concernait un nom mal orthographié.
Le standard DFC prévoit l’utilisation d’Open ID Connect (OIDC) pour l’authentification des utilisateurs. Avec ce système, les utilisateurs peuvent se connecter aux applications qui utilisent le prototype DFC avec les mêmes identifiants. Ce système permet également de sécuriser les données contenues sur les plateformes. Seul l’utilisateur authentifié peut accéder à ses données hébergées par une plateforme depuis une autre application. Appelé Social Login, ce système est utilisé par de nombreuses applications web qui souhaitent permettre à leurs utilisateurs de se connecter avec un compte d’une autre application. Il s’agit des fameux boutons de connexion « Se connecter avec ».
Le Data Food Consortium a choisi le service d’authentification des communs.org. Il s’agit d’un collectif militant pour des communs numériques. Le service d’authentification des communs est hébergé par Indie Hosters. Le DFC participe financièrement au maintien de ce service avec plusieurs autres membres et organisations. L’administration du serveur est communautaire. Le logiciel utilisé pour faire fonctionner le serveur d’authentification s’appelle KeyCloak.
Après la version 18 de KeyCloak, un nouvel élément doit être fourni pour déconnecter un utilisateur correctement. Il s’agit de l’id_token_hint (ou indice de jeton d’identification). L’équipe de KeyCloak explique [1] que cette nouvelle façon de faire améliore les performances et la sécurité. Plusieurs modifications du code source du prototype ont dues être effectuées pour l’adapter à cette nouveauté. Un jour de travail a été nécessaire.
L’autre problème soulevé par la montée de version du serveur concernait le nom du royaume (realm) dans les adresses de redirections autorisées pour les applications relative à la gestion de KeyCloak (Valid Redirect URIs). Le nom du royaume était mal orthographié. Cette erreur facile à corriger n’entraînait aucun désagrément pour les utilisateurs.
[1] Détails concernant l’ajout de l’id_token_hint à partir de KeyCloak 18
Previous versions of Keycloak had supported automatic logout of the user and redirecting to the application by opening logout endpoint URL such as http(s)://example-host/auth/realms/my-realm-name/protocol/openid-connect/logout?redirect_uri=encodedRedirectUri. While that implementation was easy to use, it had potentially negative impact on performance and security. The new version has better support for logout based on the OpenID Connect RP-Initiated Logout specification. The parameter redirect_uri is no longer supported; also, in the new version, the user needs to confirm the logout. It is possible to omit the confirmation and do automatic redirect to the application when you include parameter post_logout_redirect_uri together with the parameter id_token_hint with the ID Token used for login.
The existing deployments are affected in the following ways:
If your application directly uses links to logout endpoint with the redirect_uri parameter, you may be required to change this as described above. Consider either removing the redirect_uri parameter entirely or replacing it with the id_token_hint and post_logout_redirect_uri parameters.
If you use java adapters and your application does logout by call httpServletRequest.logout(), you are not affected because this call uses the backchannel variant of the logout endpoint and that one was not changed.
If you use the latest javascript adapter, you are also not affected. However if your application uses an older version of the JavaScript adapter, you are affected as this adapter uses the variant of the logout endpoint with the deprecated redirect_uri parameter. In this case, you may need to upgrade to the latest version of the JavaScript adapter.
For the Node.js adapter, the same guideline applies as for the JavaScript adapter. You are encouraged to update to the latest version as the older version of the adapter uses the deprecated redirect_uri parameter. With the latest Node.js adapter, you are not affected as long as you use the logout based on the /logout URL as described in the documentation or in the Node.js adapter example. However, in the case when your application directly uses the method keycloak.logoutUrl, you can consider adding idTokenHint as the second argument to this method. The possibility to add idTokenHint as second argument was newly added in this version. The idTokenHint needs to be a valid ID Token that was obtained during the login. Adding idTokenHint is optional, but if you omit it, your users will need to confirm the logout screen as described earlier. Also they will not be redirected back to the application after logout.
There is a backwards compatibility option, which allows your application to still use the old format of the redirect_uri parameter.
You can enable this parameter when you start the server by entering the following command:
bin/kc.[sh|bat] --spi-login-protocol-openid-connect-legacy-logout-redirect-uri=true start
With this configuration, you can still use the format with the redirect_uri parameter. Note the confirmation screen will be needed if the id_token_hint is omitted.
Warning
The backwards compatibility switch will be removed in some future version - probably Keycloak 23. You are encouraged to update your clients as soon as possible as described above rather than rely on this switch. Previous versions of Keycloak had supported automatic logout of the user and redirecting to the application by opening logout endpoint URL such as http(s)://example-host/auth/realms/my-realm-name/protocol/openid-connect/logout?redirect_uri=encodedRedirectUri. While that implementation was easy to use, it had potentially negative impact on performance and security. The new version has better support for logout based on the OpenID Connect RP-Initiated Logout specification. The parameter redirect_uri is no longer supported; also, in the new version, the user needs to confirm the logout. It is possible to omit the confirmation and do automatic redirect to the application when you include parameter post_logout_redirect_uri together with the parameter id_token_hint with the ID Token used for login.
The existing deployments are affected in the following ways:
If your application directly uses links to logout endpoint with the redirect_uri parameter, you may be required to change this as described above. Consider either removing the redirect_uri parameter entirely or replacing it with the id_token_hint and post_logout_redirect_uri parameters.
If you use java adapters and your application does logout by call httpServletRequest.logout(), you are not affected because this call uses the backchannel variant of the logout endpoint and that one was not changed.
If you use the latest javascript adapter, you are also not affected. However if your application uses an older version of the JavaScript adapter, you are affected as this adapter uses the variant of the logout endpoint with the deprecated redirect_uri parameter. In this case, you may need to upgrade to the latest version of the JavaScript adapter.
For the Node.js adapter, the same guideline applies as for the JavaScript adapter. You are encouraged to update to the latest version as the older version of the adapter uses the deprecated redirect_uri parameter. With the latest Node.js adapter, you are not affected as long as you use the logout based on the /logout URL as described in the documentation or in the Node.js adapter example. However, in the case when your application directly uses the method keycloak.logoutUrl, you can consider adding idTokenHint as the second argument to this method. The possibility to add idTokenHint as second argument was newly added in this version. The idTokenHint needs to be a valid ID Token that was obtained during the login. Adding idTokenHint is optional, but if you omit it, your users will need to confirm the logout screen as described earlier. Also they will not be redirected back to the application after logout.
There is a backwards compatibility option, which allows your application to still use the old format of the redirect_uri parameter.
You can enable this parameter when you start the server by entering the following command:
bin/kc.[sh|bat] --spi-login-protocol-openid-connect-legacy-logout-redirect-uri=true start
With this configuration, you can still use the format with the redirect_uri parameter. Note the confirmation screen will be needed if the id_token_hint is omitted.
Warning
The backwards compatibility switch will be removed in some future version - probably Keycloak 23. You are encouraged to update your clients as soon as possible as described above rather than rely on this switch. Previous versions of Keycloak had supported automatic logout of the user and redirecting to the application by opening logout endpoint URL such as http(s)://example-host/auth/realms/my-realm-name/protocol/openid-connect/logout?redirect_uri=encodedRedirectUri. While that implementation was easy to use, it had potentially negative impact on performance and security. The new version has better support for logout based on the OpenID Connect RP-Initiated Logout specification. The parameter redirect_uri is no longer supported; also, in the new version, the user needs to confirm the logout. It is possible to omit the confirmation and do automatic redirect to the application when you include parameter post_logout_redirect_uri together with the parameter id_token_hint with the ID Token used for login.
The existing deployments are affected in the following ways:
If your application directly uses links to logout endpoint with the redirect_uri parameter, you may be required to change this as described above. Consider either removing the redirect_uri parameter entirely or replacing it with the id_token_hint and post_logout_redirect_uri parameters.
If you use java adapters and your application does logout by call httpServletRequest.logout(), you are not affected because this call uses the backchannel variant of the logout endpoint and that one was not changed.
If you use the latest javascript adapter, you are also not affected. However if your application uses an older version of the JavaScript adapter, you are affected as this adapter uses the variant of the logout endpoint with the deprecated redirect_uri parameter. In this case, you may need to upgrade to the latest version of the JavaScript adapter.
For the Node.js adapter, the same guideline applies as for the JavaScript adapter. You are encouraged to update to the latest version as the older version of the adapter uses the deprecated redirect_uri parameter. With the latest Node.js adapter, you are not affected as long as you use the logout based on the /logout URL as described in the documentation or in the Node.js adapter example. However, in the case when your application directly uses the method keycloak.logoutUrl, you can consider adding idTokenHint as the second argument to this method. The possibility to add idTokenHint as second argument was newly added in this version. The idTokenHint needs to be a valid ID Token that was obtained during the login. Adding idTokenHint is optional, but if you omit it, your users will need to confirm the logout screen as described earlier. Also they will not be redirected back to the application after logout.
There is a backwards compatibility option, which allows your application to still use the old format of the redirect_uri parameter.
You can enable this parameter when you start the server by entering the following command:
bin/kc.[sh|bat] --spi-login-protocol-openid-connect-legacy-logout-redirect-uri=true start
With this configuration, you can still use the format with the redirect_uri parameter. Note the confirmation screen will be needed if the id_token_hint is omitted.
Warning
The backwards compatibility switch will be removed in some future version - probably Keycloak 23. You are encouraged to update your clients as soon as possible as described above rather than rely on this switch. 
