OpenID Connect exige que le client soit déclaré au niveau du serveur pour obtenir en particulier un client_id et un client_secret.
Comment le serveur sait-il que la demande est ou non légitime et que ce n'est pas une application faisant par exemple du phishing ?
Enfin OpenID Connect impose l'utilisation de scope et de claims
Il est tout à fait possible de faire une demande d'autorisation sans scope et de ne retourner aucun claims (et donc de ne faire que de l'authentification). Mais c'est plutôt dommage si l'application doit faire du contrôle d'accès derrière.
avec validation du consentement de l'utilisateur
Toutes les solutions que je connais permet de bypasser cette étape au besoin
pas forcément souhaité dans le déploiement de micro services.
Je ne suis absolument pas un spécialiste en micro service, mais n'utiliserions nous pas simplement les jetons en Bearer (access_token ou id_token). Jetons issuent d'une authentification utilisateur préalable (avec éventuellement un consentement :)) ou d'une authentification en grant_type=client_credential pour les "non humains" puis propagation des jetons de services en services (exemple de conf de sécurisation de ressource avec mon cher mod_auth_openidc https://github.com/zmartzone/mod_auth_openidc/wiki/OAuth-2.0-Resource-Server) ?
Mais mod_auth_openidc n'est par exemple disponible que pour Apache, pas Nginx
[^] # Re: SSO as a Service (SSOaaS)
Posté par Mathieu CLAUDEL (site web personnel) . En réponse à la dépêche Sortie de LemonLDAP::NG 2.0. Évalué à 1.
merci pour le retour.
Comment le serveur sait-il que la demande est ou non légitime et que ce n'est pas une application faisant par exemple du phishing ?
Il est tout à fait possible de faire une demande d'autorisation sans scope et de ne retourner aucun claims (et donc de ne faire que de l'authentification). Mais c'est plutôt dommage si l'application doit faire du contrôle d'accès derrière.
Toutes les solutions que je connais permet de bypasser cette étape au besoin
Je ne suis absolument pas un spécialiste en micro service, mais n'utiliserions nous pas simplement les jetons en Bearer (access_token ou id_token). Jetons issuent d'une authentification utilisateur préalable (avec éventuellement un consentement :)) ou d'une authentification en grant_type=client_credential pour les "non humains" puis propagation des jetons de services en services (exemple de conf de sécurisation de ressource avec mon cher mod_auth_openidc https://github.com/zmartzone/mod_auth_openidc/wiki/OAuth-2.0-Resource-Server) ?
Pour ngnix il y a https://github.com/zmartzone/lua-resty-openidc (lui aussi certifié)
Désolé, j'ai beaucoup de questions et interrogations, mais c'est un sujet qui m’intéresse beaucoup.