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 ?
Un paramètre permet de lister les hôtes de confiance (vers qui une redirection est autorisée). On peut autoriser tout un sous-domaine par exemple.
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.
Pour être précis, le scope "openid" est obligatoire, sinon tu fais du OAuth2 et pas du OpenID Connect. Et donc l'utilisateur doit accepter ce scope.
Toutes les solutions que je connais permet de bypasser cette étape au besoin
En effet, LL::NG le permet aussi, mais c'est contraire au protocole.
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) ?
Attention, un ID Token est un JWT qui n'a pas vocation à être utilisé en authentification Bearer, c'est l'access token qui est prévu pour ça. Pour être bref, oui OpenID Connect peut marcher pour protéger applications et API, mais ce n'est pas la seule solution et elle nécessite que les applications et API implémentent le protocole.
[^] # Re: SSO as a Service (SSOaaS)
Posté par KPTN (site web personnel, Mastodon) . En réponse à la dépêche Sortie de LemonLDAP::NG 2.0. Évalué à 2.
Un paramètre permet de lister les hôtes de confiance (vers qui une redirection est autorisée). On peut autoriser tout un sous-domaine par exemple.
Pour être précis, le scope "openid" est obligatoire, sinon tu fais du OAuth2 et pas du OpenID Connect. Et donc l'utilisateur doit accepter ce scope.
En effet, LL::NG le permet aussi, mais c'est contraire au protocole.
Attention, un ID Token est un JWT qui n'a pas vocation à être utilisé en authentification Bearer, c'est l'access token qui est prévu pour ça. Pour être bref, oui OpenID Connect peut marcher pour protéger applications et API, mais ce n'est pas la seule solution et elle nécessite que les applications et API implémentent le protocole.
Merci, je ne connaissais pas.