Ton cas d'usage est celui que j'utilise la plupart du temps, mais dans OAuth2/OIDC il faut distinguer deux notions différentes:
Le client peut être public ou privé
Un client privé est un client qui doit s'authentifier sur le serveur OAuth2/OIDC pour faire une demande quelconque, avec un mot de passe, une clé RSA, ou un autre moyen pris en charge par le serveur OAuth2/OIDC. Il doit donc être capable de stocker ladite méthode d'authentification quelque part pour le donner au serveur OAuth2/OIDC à chaque requête.
Un client public n'a pas besoin de s'authentifier à chaque requête sur le serveur OAuth2/OIDC.
Je vois souvent les clients OAuth2/OIDC confidentiels qui sont des services web intermédiaires, biens que plein d'autres facons de faire existent.
Effectivement si ton client est une application javascript s'exécutant sur le navigateur de l'utilsateur (SPA), c'est inutile d'avoir un client confidentiel car avec un simple F12 n'importe quel utilisateur (authentifié ou non) peut accéder au secret du client.
Le client peut demander un refresh token ou seulement un access token
S'il demande un refresh token, le client doit le stocker quelque part pour utiliser le refresh token à chaque besoin, d'autant que le token peut avoir une durée de vie longue, donc faut faire attention à ce que tu en fais.
Maintenant dans les faits, je ne vois pas de contre indication à utiliser un client public pour demander des refresh token. Si tu as confiance en ton navigateur pour stocker tes cookies de session, éventuellement tes mots de passe, je ne vois pas pourquoi tu ne pourrais pas non plus y stocker tes refresh token, via un cookie ou un stockage local.
[^] # Re: keycloak ?
Posté par Babelouest (site web personnel) . En réponse au journal Glewlwyd 2.0, serveur SSO, est maintenant en RC1. Évalué à 3. Dernière modification le 10 septembre 2019 à 15:35.
Ton cas d'usage est celui que j'utilise la plupart du temps, mais dans OAuth2/OIDC il faut distinguer deux notions différentes:
Un client privé est un client qui doit s'authentifier sur le serveur OAuth2/OIDC pour faire une demande quelconque, avec un mot de passe, une clé RSA, ou un autre moyen pris en charge par le serveur OAuth2/OIDC. Il doit donc être capable de stocker ladite méthode d'authentification quelque part pour le donner au serveur OAuth2/OIDC à chaque requête.
Un client public n'a pas besoin de s'authentifier à chaque requête sur le serveur OAuth2/OIDC.
Je vois souvent les clients OAuth2/OIDC confidentiels qui sont des services web intermédiaires, biens que plein d'autres facons de faire existent.
Effectivement si ton client est une application javascript s'exécutant sur le navigateur de l'utilsateur (SPA), c'est inutile d'avoir un client confidentiel car avec un simple F12 n'importe quel utilisateur (authentifié ou non) peut accéder au secret du client.
S'il demande un refresh token, le client doit le stocker quelque part pour utiliser le refresh token à chaque besoin, d'autant que le token peut avoir une durée de vie longue, donc faut faire attention à ce que tu en fais.
Maintenant dans les faits, je ne vois pas de contre indication à utiliser un client public pour demander des refresh token. Si tu as confiance en ton navigateur pour stocker tes cookies de session, éventuellement tes mots de passe, je ne vois pas pourquoi tu ne pourrais pas non plus y stocker tes refresh token, via un cookie ou un stockage local.