J'ai un serveur d'authentification construit à l'aide de spring boot oauth2.0 et suit le modèle david_syer.
Mon serveur d'authentification suit -
Laissez l'utilisateur se connecter via un fournisseur tiers tel que Google ou laissez l'utilisateur créer son compte sur notre serveur en utilisant le nom d'utilisateur et le mot de passe et générer un jeton.
Ainsi, lorsque l'utilisateur utilise un oauth externe comme google pour se connecter, je stocke simplement le jeton et transmets le même jeton (google) à mon application d'interface utilisateur pour accéder aux serveurs api de ressources. J'ai un filtre d'authentification qui vérifie le jeton et autorise l'accès à l'API.
Lorsque l'utilisateur utilise un nom d'utilisateur et un mot de passe pour obtenir un jeton, nous stockons l'utilisateur et ses autorisations et générons un jeton pour lui. Désormais, l'interface utilisateur utilise le jeton généré par nos serveurs d'authentification pour accéder aux serveurs API de ressources.
Maintenant ma question est
Ainsi, la sécurité de printemps qui charge les autorités des utilisateurs et des utilisateurs (loadUserByUsername () de UserDetailsService) n'aura rien si l'utilisateur provient d'un fournisseur éternel.
J'ai une suggestion pour l'étape 2: une fois que l'utilisateur utilise l'authentification google et est redirigé vers votre page d'application, effectuez la transformation des revendications sur votre serveur et générez votre propre jeton émis par le serveur d'identité que vous avez.
La raison en est que vous serez en mesure de fournir des revendications spécifiques et que les noms des revendications ne doivent pas nécessairement correspondre.
De cette façon, vous continuez à vérifier votre propre jeton tout le temps sur l'application cliente. Disons donc que l'utilisateur utilise Facebook au lieu de Google et même dans ce scénario, car vous attribuerez votre propre jeton, vous n'avez pas besoin de vérifier le jeton provenant de différents serveurs d'identité tiers.
De cette façon, votre serveur d'identité fait confiance à Facebook, le jeton fourni par Google et votre application ne fera confiance qu'à votre serveur d'identité afin que votre application n'ait pas besoin de savoir quel IDP émet le jeton.
Et avec l'approche que j'ai suggérée ci-dessus, vous pourrez même modifier vous-même les revendications de l'utilisateur et ne pas avoir à dépendre du serveur d'identité tiers pour fournir des revendications.
Cet article est collecté sur Internet, veuillez indiquer la source lors de la réimpression.
En cas d'infraction, veuillez [email protected] Supprimer.
laisse moi dire quelques mots