ASP Authentification par défaut .NET Core Identity vs authentification JWT
Je développe ASP NET Core Web API et je suis confus en choisissant la méthode d'authentification. J'avais l'habitude d'appliquer l'authentification par défaut Asp Net Identity, mais récemment je connaissais JWT. J'ai donc implémenté l'authentification presque comme il l'a fait dans cet article: https://stormpath.com/blog/token-authentication-asp-net-core . Mais je ne comprends pas les avantages de ce JWT. Avec Authentification Asp Net Identity simple, je ne me soucie pas du stockage de jetons, etc. Je n'ai besoin que de me connecter avec signInManager et d'utiliser des méthodes autorisées jusqu'à la déconnexion. Avec JWT, je dois penser au magasin de jetons, à l'expiration et à d'autres difficultés. Quels sont les avantages de ce JWT? Comment puis-je stocker ce jeton JWT après la connexion? De plus, dois-je même utiliser ce JWT? Dans mon cas, j'ai besoin d'une authentification simple pour WebApi simple qui sera utilisé par un ou plusieurs utilisateurs J'ai également entendu parler d'OpenIddict, Auth0, IdentityServer, alors quelle est la différence entre tous ces mécanismes d'authentification?
C'est ainsi que je comprends cela, divisé en 3 parties logiques.
- Serveur d'authentification - cela authentifiera et émettra le jeton JWT, lorsque l'API doit valider le jeton, il enverra le jeton à ce serveur pour le valider.
- Client - c'est ce qui sert vos pages Web, ou votre application peut-être. C'est ce qui devra demander et stocker le jeton JWT. Le client devra transmettre le jeton à l'API chaque fois qu'il demande des données.
- API - c'est ce qui sert les informations et doit valider le jeton avec le serveur d'authentification.
Alors, quels sont les avantages de ce JWT?
JWT est délivré au client et stocké côté client. Le fait d'avoir JWT permet à plusieurs clients (applications ou sites Web) d'utiliser le même serveur d'authentification qui distribue JWT et indique les API que le client peut utiliser et comment.
Comment puis-je stocker ce jeton JWT après la connexion?
J'ai seulement essayé de le stocker dans une application Ionic 2 qui utilise angular 2 qui a un module de stockage. Mais je suis sûr que de nombreuses personnes l'ont fait) déjà et posé cette question:
Authentification JWT simple dans l'API Web ASP.NET Core 1.
Authentification basée sur les jetons dans ASP.NET Core (actualisée)
Mise à jour Si votre front-end est purement html/js/css et n'a pas de back-end pour l'accueillir, vous stockerez votre token dans le stockage local , il existe plusieurs packages npm qui vous aident avec cela comme celui-ci . Vous souhaitez rechercher le flux implicite.
Sinon, si vous avez un serveur principal fourni avec votre serveur frontal, vous souhaitez stocker le jeton dans une session/base de données de votre choix, il existe des fournisseurs tiers pour le faire, comme IdentityServer4. Vous souhaitez utiliser le flux hybride
De plus, devrais-je même utiliser ce JWT? Dans mon cas, j'ai besoin d'une authentification simple pour WebApi simple qui sera utilisé par un ou plusieurs utilisateurs.
La raison de toute la séparation des préoccupations est la performance, donc vous n'en avez pas vraiment besoin car ce n'est qu'un ou un peu plus d'utilisateurs. Faites-le parce que c'est une expérience d'apprentissage, JWT n'est pas facile à configurer depuis le début et vous demandera de faire beaucoup de lecture et vous échouerez et vous serez frustré mais à la fin vous saura comment le configurer et comment il fonctionne
J'ai également entendu parler d'OpenIddict, Auth0, IdentityServer, alors quelle est la différence entre tous ces mécanismes d'authentification?
Donc, ce que vous avez fait dans le tutoriel Stormpath n'est PAS prêt pour la production. Ce n'est qu'une petite démo, pour vous aider à comprendre ce qu'est JWT et comment il fonctionne. Les éléments mentionnés ci-dessus sont des bibliothèques complètes qui s'attaquent à tous les travaux lourds et ne nécessitent pas que vous construisiez le tout à partir de zéro. Et la principale différence entre eux est l'étendue qu'ils couvrent.
J'ai personnellement utilisé IS4 et ça m'a fait pleurer pas plus de 2 fois (c'était plus simple que je ne le pensais): http://identityserver4.readthedocs.io/en/release/
https://github.com/openiddict/openiddict-core
https://auth0.com/docs/quickstart/webapp/aspnet-core/00-intro
Utilisez des jetons (JWT) si vous disposez de plusieurs applications ou services (Web, mobile, autres services) de connexion à votre API. Avantages: apatride, évolutivité, pas de cookie, pas de problèmes CORS (si vous le permettez).
Si votre API n'est utilisée que par une seule application Web, utilisez le système d'authentification par défaut ASP par défaut. C'est plus facile à configurer.
Si votre webapi et votre interface utilisateur sont hébergés dans la même application Web, la sécurité des bases de jetons ne vous rapporte rien par rapport à l'authentification basée sur les cookies fournie par l'authentification intégrée. En effet, le cookie d'authentification est renvoyé à l'application keep à chaque demande HTTP. Lorsque vous effectuez des appels vers un site Web autre que celui sur lequel vous vous êtes connecté, ces cookies ne sont pas envoyés. Les jetons Web JSON (JWT) fournissent donc un format standard permettant au navigateur d'envoyer des informations d'identité à un site Web lorsqu'un cookie n'est pas une option.
Si votre Web Api doit être accessible par AJAX appels alors JWT peut être un choix souhaité, mais pas obligatoire. À en juger par la description de votre application, il me semble que le système d'authentification par défaut peut vous servir bien. Auth2 est le mécanisme d'authentification qui permet la connexion externe comme Facebook. Il fait partie du système d'authentification par défaut, et vous n'avez pas besoin de faire grand-chose pour l'utiliser dans votre application.
OpenIddict se trouve au-dessus d'Auth2. Il fait partie du système d'authentification par défaut et vous n'avez pas besoin de faire grand-chose pour l'utiliser dans votre application. C'est le mécanisme d'authentification qui permet une connexion externe telle que Google+
IdentityServer peut être utilisé pour les grands Wep Api accessibles par les appels Ajax. Comme par exemple, vous pouvez utiliser IdentityServer pour authentifier les utilisateurs désireux d'accéder à une application frontale Angular app.
Encore une fois, le système d'authentification par défaut peut bien vous servir.
J'espère que cela t'aides...