Client public Keycloak et autorisation
Nous utilisons l'adaptateur keycloak avec Jetty pour l'authentification et l'autorisation à l'aide de Keycloak. Selon doc Keycloak pour le flux d'authentification OIDC :
Un autre aspect important de ce flux est le concept d'un public vs confidentiel client. Les clients confidentiels sont tenus de fournir un secret client lorsqu'ils échangent les codes temporaires contre des jetons. Les clients publics ne sont pas tenus de fournir ce secret client. Les clients publics sont parfaitement bien tant que HTTPS est strictement appliqué et que vous êtes très strict quant aux URI de redirection enregistrés pour le client.
Les clients HTML5/JavaScript doivent toujours être des clients publics car il n'y a aucun moyen de leur transmettre le secret client de manière sécurisée.
Nous avons des webapps qui se connectent à Jetty et utilisent l'auth. Nous avons donc créé un client public et cela fonctionne très bien pour l'authentification webapp/REST.
Le problème est que dès que nous activons l'autorisation, le type de client est converti en confidentiel de public et il ne permet pas de le réinitialiser en public. Maintenant, nous sommes dans la soupe. Nous ne pouvons pas avoir de clients publics en raison d'une autorisation et nous ne pouvons pas connecter des applications Web à un client confidentiel.
Cela nous semble contradictoire. Une idée pourquoi le client doit être confidentiel pour l'autorisation? Une aide à ce sujet, comment pouvons-nous surmonter ce problème?
Merci.
Pour autant que je sache, vos applications frontend et backend sont séparées. Si votre frontend est une application web statique et n'est pas desservi par la même application backend (serveur), et que votre backend est une simple REST API - alors vous aurez configuré deux clients Keycloak:
publicclient pour l'application frontale. Il serait responsable de l'acquisition des jetons JWT.bearer-onlyclient, qui serait attaché à votre application backend.
Pour activer l'autorisation, vous devez créer des rôles (domaine ou domaine défini par le client, commencez au niveau du domaine car il est plus facile à comprendre). Chaque utilisateur se verrait alors attribuer un/des rôle (s) dans l'interface d'administration de Keycloak. Sur cette base, vous devez configurer la configuration de votre adaptateur keycloak (sur le backend).
Tout bien considéré, afin de parler à votre REST API, vous devez attacher un jeton JWT à chaque demande HTTP dans l'en-tête Autorisation. En fonction de votre infrastructure frontale, vous pouvez utiliser l'une des options suivantes:
- Adaptateur js Keycloak
- Autres fixations ( angulaire , réagir )
P.S. Pour le débogage, je viens d'écrire un outil CLI appelé brauzie qui vous aiderait à récupérer et analyser vos jetons JWT (étendues, rôles, etc.). Il pourrait être utilisé pour des clients publics et confidentiels. Vous pouvez également utiliser Postman et https://jwt.io
HTH :)
Je pense que vous faites référence au commutateur "Autorisation activée" dans la console d'administration de Keycloak, lors de la création d'un client. Si vous passez le point d'interrogation à côté de l'étiquette, vous verrez l'indication "Activer/désactiver la prise en charge des autorisations détaillées pour un client.
Créer un client dans la console d'administration Keycloak (v 6.0.1)
Cela est destiné lorsque vous créez un client pour une application dorsale qui sert de serveur de ressources. Dans ce cas, le client sera confidentiel.
Si vous souhaitez créer un client pour une application frontale, authentifier un utilisateur et obtenir un JWT, vous n'en avez pas besoin.
Voir aussi: https://www.keycloak.org/docs/latest/authorization_services/index.html
Après de longues délibérations, nous avons constaté qu'il n'est pas nécessaire d'activer l'autorisation sur le client public lorsque vous vous y connectez. Lorsqu'une demande parvient au client public, elle ne fait que la partie d'authentification. La partie autorisation est effectuée lorsque la demande réelle arrive sur le serveur de ressources (dans notre cas, Jetty) en utilisant le client confidentiel (car Jetty a connaissance du client confidentiel configuré en son sein).