Pour le moment, nous construisons une boutique en ligne sous la forme d'une application spa . Toutes les informations SKU sont fournies par un Bien sûr, le magasin Web est accessible au public sur chaque visiteur et il n'existe actuellement qu'un seul utilisateur qui peut se connecter pour gérer le magasin Web: l'administrateur.
Pour l'administrateur, nous avons construit l'authentification de base avec le jeton , car beaucoup d'échantillons sur Internet nous le montre, mais nous avons maintenant besoin de chaque utilisateur pour vous connecter avant de pouvoir voir n'importe quel produit. . Pas vraiment ce que nous avons à l'esprit pour un magasin Web ;-)
Ce que nous aimerions mettre en œuvre, c'est que notre API Web n'est pas disponible pour le monde, mais uniquement pour notre application SPA. Chaque poste de blog ou didacticiel sur l'autorisation semble supposer qu'il existe toujours un utilisateur qui doit être connecté, dans notre cas, un seul utilisateur: l'administrateur.
Le Il s'agit essentiellement pour empêcher toute autre application (Web ou mobile) de récupérer les données de notre API Web.
Quelle serait la meilleure et la plus sécurisée d'approche pour sécuriser notre API Web sans avoir les visiteurs anonymes de notre magasin Web pour vous connecter?
Solution pour l'instant : Alough, je ne suis pas 100% heureux avec cette solution, cela fonctionnera pour l'instant. Nous avons mis en place le flux implicite OAuth avec Cors activé pour un domaine spécifique. Web API 2 Service.
Autoronymous attribue des appels d'API spécifiques disponibles au monde à nouveau, c'est aussi une impasse.
3 Réponses :
Comment implémenteriez-vous ce flux spécifique dans un client JavaScript? D'une manière ou d'une autre, le client doit faire une demande avec quelques références, non?
Je pensais que vous feriez l'authentification du côté serveur lorsque vous chargez d'abord le spa. Si vous voulez être complètement client, je vous conseillerais de regarder le flux implicite de OAuth. Pour un exemple, voir ici: développeurs.google.com/Accounts/docs/oauth2USERAGENT
TNX, je vais regarder la documentation Google. Un problème avec la génération de jeton sur la première charge est que nous ne pouvons pas avoir une liaison profonde puis, ou pouvons-nous?
OAuth 2.0 est intrinsèquement non sécurisé et repose uniquement sur SSL. Il n'a pas de cryptage et la plupart des derniers gurus de l'API Web suggèrent que c'est mort. Cela est à nouveau relatif à ce dont vous avez besoin de la sécurité. Si c'est pour un spa social où les données ne sont pas financières ou médicales, par exemple, et une bonne sécurité SSL conviennent, peut-être peut-être que OPENID ou OAUTH2 conviennent.
Une bien meilleure solution consiste à implémenter l'identité 2.0 pour le flux d'authentification de l'API Web, puis utilisez quelque chose comme le protocole Hawk pour la mise en œuvre de Mac HTTP. Consultez ceci: https://github.com/webapibook/hawknet pour un exemple.
Pour le cadre OAuth2 et une solution extensible, consultez la pensée ThinkTecure.IdentityServer3 sur Github
Pour une solution de jeton de tokénisation de l'API WEB 4.5 Lightwewewewewewewewewewewew.NET, consultez la pensée ThinkTecure.IdentityServer2 sur Github.
J'espère que cela aide.
Oauth 2.0 est intrinsèquement non sécurisé et repose uniquement sur SSL. Il n'a pas de cryptage et la plupart des derniers gurus Web API Web suggèrent qu'il est mort. Avez-vous d'autres références pour soutenir cette déclaration?
Je pense jeton Web JSON pourrait vous aider avec cela. Ce
0 commentaires
Donc, vous ne voulez pas permettre à tous les utilisateurs d'entrer dans l'application, mais que vous souhaitez que certains utilisateurs y accèdent, mais sans effectuer une journalisation?
L'application elle-même est publique, chaque utilisateur peut accéder au site. Fondamentalement, il s'agit de prévenir toutes les autres applications (Web ou mobile) pour récupérer les données de notre API Web.