Comment interagir avec back-end après un auth réussi avec OAuth sur front-end?
je veux construire une petite application. Il y aura certains utilisateurs. Je ne veux pas créer mon propre système d'utilisateur. Je veux intégrer mon application avec oauth / oauth2.0.
il n'y a pas de problème dans l'intégration de mon application front-end et oauth 2.0. Il ya tellement d'articles utiles, comment faire, même sur stackoverflow.com. Par exemple ce post est très utile.
Mais. Que dois-je faire après avoir obtenu une autorisation à la réception? Bien sûr, je peux juste drapeau sur le client, qui dit "ok, mate, l'utilisateur est authentifié", mais comment je dois interagir avec mon backend maintenant? Je ne peux pas juste faire certaines demandes. Back-end-some application, qui fournit des fonctions API. Tout le monde peut accéder à cette api.
donc, j'ai besoin d'un système d'auth de toute façon entre mon FE et BE. Comment ce système devrait fonctionner?
ps j'ai quelques problèmes avec l'anglais et peut-être je ne peux pas correctement "demandez à google". Pouvez-vous fournir la réponse correcte, s'il vous plaît :) ou au moins de donner quelques articles sur ma question.
UPD
je cherche le concept. Je ne veux pas trouver de solution à mon problème actuel. Je ne pense pas que ce soit important ce que FE et BE j'utilise (de toute façon je vais fournir des informations à ce sujet ci-dessous)
FE et BE utiliseront JSON pour communiquer. FE fera des demandes, BE enverra des réponses JSON. Ma demande aura cette structure (probablement):
- Frontend - probablement AngularJS
- Backend-probablement Laravel (laravel implémentera la logique, il y a aussi la base de données dans la structure)
peut-être" fournisseur de services " comme google.com, vk.com, twitter.com etc se souvient de l'état de l'utilisateur? Et après avoir réussi l'écriture sur FE, je peux juste poser des questions sur l'état de l'utilisateur de BE?
6 réponses
nous avons 3 principaux problèmes de sécurité lors de la création d'une API.
Authentification: un fournisseur d'identification comme Google n'est qu'une solution partielle. Parce que vous ne voulez pas demander à l'utilisateur de se connecter / confirmer son identité pour chaque requête API, vous devez implémenter vous-même l'authentification pour les requêtes suivantes. Vous devez stocker, accessible à backend:
- un identifiant d'utilisateur. (tiré du fournisseur d'identité, par exemple: e-mail)
- un jeton utilisateur. (Un token temporaire que vous générez, et que vous pouvez vérifier à partir du code API)
l'Autorisation: votre backend doit implémenter des règles basées sur l'identifiant de l'utilisateur (c'est votre propre entreprise).
sécurité des transports: HTTPS et cookies expirants sont sécurisés et non rejouables par d'autres. (HTTPS est le cryptage du trafic, de sorte que les défaites man-in-the-middle attaques, et l'expiration des cookies défaites les attaques de relecture plus tard dans le temps)
ainsi votre API / backend a une table de recherche d'emails vers des chaînes aléatoires. Maintenant, vous n'avez pas à exposer l'identité de l'utilisateur. Le jeton est insignifiant et temporaire.
Voici comment fonctionne le flux, dans ce système:
User-Agent IdentityProvider (Google/Twitter) Front-End Back-End
|-----------------"https://your.app.com"---------->|
|---cookies-->|
your backend knows the user or not.
if backend recognizes cookie,
user is authenticated and can use your API
ELSE:
if the user is unknown:
|<--"unknown"-|
|<----"your/login.js"----------+
"Do you Authorize this app?"
|<------------------+
|--------"yes"----->|
+----------auth token--------->|
|<---------/your/moreinfo.js---|
|-------access_token ---------->|
1. verify access token
2. save new user info, or update existing user
3. generate expiring, random string as your own API token
+----------->|
|<-------------- set cookie: your API token --------------------|
maintenant, l'utilisateur peut utiliser directement votre API:
|--------------- some API request, with cookie ---------------->|
|<-------------- some reply, depends on your logic, rules ------|
EDIT
basé sur la discussion - ajoutant que le backend peut authentifier un utilisateur en vérifiant le jeton d'accès avec le fournisseur d'identité:
Par exemple, Google expose ce paramètre pour vérifier un token XYZ123:
https://www.googleapis.com/oauth2/v3/tokeninfo?id_token=XYZ123
j'ai lu toutes les réponses très attentivement, et plus de la moitié des personnes qui ont répondu manquent complètement la question. OP demande la connexion initiale entre FE & BE, après l'émission du jeton OAuth par le fournisseur de services.
comment votre backend sait - il que le jeton OAuth est valide? Gardez à l'esprit que votre BE peut envoyer une demande au fournisseur de services et confirmer la validité du jeton OAuth, qui a d'abord été reçu par votre FE. Cette OAuth la clé ne peut être déchiffrée par le fournisseur de Services que parce qu'il est le seul à posséder la clé secrète. Une fois qu'ils déchiffrent la clé, ils répondent généralement avec des informations telles que le nom d'utilisateur, le courrier électronique et autres.
En résumé:
votre FE reçoit un autre jeton du fournisseur de services après que l'Utilisateur a donné son autorisation. FE passe un autre token pour être. BE envoie le jeton OAuth au fournisseur de services pour valider le jeton OAuth. Le fournisseur de services répond D'être avec des informations de nom d'utilisateur/email. Vous pouvez ensuite utilisez le nom d'utilisateur / e-mail pour créer un compte.
ensuite, après que votre BE crée le compte, votre BE devrait générer sa propre implémentation d'un jeton OAuth. Ensuite, vous envoyez ce jeton à votre FE, et à chaque demande, votre FE enverrait ce jeton dans l'en-tête à votre BE. Puisque seul votre BE possède la clé secrète pour valider ce token, votre application sera très sûre. Vous pouvez même rafraîchir le jeton de votre BE à chaque demande, en donnant à votre FE une nouvelle clé à chaque fois. En cas quelqu'un vole le jeton OAuth de votre FE, ce jeton serait rapidement invalidé, puisque votre BE aurait déjà créé un nouveau jeton OAuth pour votre FE.
il y a plus d'informations sur la façon dont votre BE peut valider le jeton OAuth. comment valider un jeton d'accès OAuth 2.0 pour un serveur de ressources?
Eh bien, vous n'avez pas besoin de système D'utilisateur sur votre face avant. La face avant est juste une façon d'interagir avec votre serveur et demandez jeton d'utilisateur valide et un mot de passe.
Votre serveur censé gérer les utilisateurs et les autorisations.
connexion de l'Utilisateur scénario
Utilisateur demandant jeton en entrant son nom d'utilisateur et mot de passe. L'API serveur accepte la requête car c'est une méthode anonyme (tout le monde peut appeler cette méthode sans se soucier de savoir s'il est connecté). ou pas.
le serveur vérifie la base de données (ou un peu de stockage) et compare les détails de l'utilisateur avec les détails qu'il a. Dans le cas où les détails correspondent, le serveur renvoie le token à l'utilisateur.
A partir de maintenant, l'utilisateur doit configurer ce token avec n'importe quelle requête pour que le serveur reconnaisse l'utilisateur. Le token contient en fait les rôles utilisateur, timestamp, etc...
quand l'utilisateur demande des données par API, il récupère le token de l'en-tête, et vérifie si l'utilisateur est autorisé à accéder à cette méthode.
comment ça marche en général.
je me base sur .NET dans ma réponse. Mais la plupart des Be libaries fonctionnent comme ça.
comme je fais un projet pour SSO et basé sur ma compréhension de votre question, je peux suggérer que vous créez un point final dans votre back-end pour générer des sessions, une fois que le client-frontend - a été autorisé avec succès par le titulaire du compte, et a obtenu les informations utilisateur du fournisseur, vous postez cette information au point final back-end, le point final back-end génère une session et stocke cette information, et renvoie L'ID de session-fréquemment appelé jSessionId - avec un cookie retour au client-frontend-de sorte que le navigateur peut le sauvegarder pour vous et chaque demande après cela à la fin considérée comme un utilisateur authentifié.
pour se déconnecter, il suffit de créer un autre endpoint dans le back-end pour accepter un identifiant de session afin que le back-end puisse le supprimer.
j'espère que ce sera utile pour vous.
nous allons utiliser OAuth concept pour commencer,FE Client ,Serveur De Ressources.
- puisque votre client est déjà autorisé, le serveur D'autorisation devrait accorder jeton d'Accès pour le client.
- le Client en fait la demande au serveur de ressources avec l' jeton d'Accès
- le serveur de ressources valide le jeton d'Accès si valide, traiter la demande.
vous demandez-vous, qu'est-ce que le jeton d'Accès, le token D'accès a été émis par le serveur d'autorisation, grant au client, et reconnu par le serveur de ressources.
jeton d'Accès est une chaîne d'indiquer les informations de l'autorisation(par exemple, les infos de l'utilisateur, l'autorisation de la portée， l'expiration du temps...).
jeton d'Accès peut crypté pour la sécurité, et vous devez vous assurer que le serveur de ressources peut le décrypter.
pour plus de détails, veuillez lire OAuth2.0 0 spécification https://tools.ietf.org/html/rfc6749.
vous devez stocker le token dans l'état de votre application et le passer ensuite au backend avec chaque requête. Passer à backend peut être fait dans les en - têtes, les cookies ou comme params-dépend de la façon dont backend est mis en œuvre.
suivez le code pour voir un bon exemple de toutes les pièces en action (pas mon code) Cet exemple définit l'Autorisation: Porteur du JETON d'en-tête https://github.com/cornflourblue/angular-registration-login-example