web-dev-qa-db-fra.com

Comment implémenter correctement OAuth dans l'API avec Laravel Passport?

J'essaie de créer une [~ # ~] api [~ # ~] et de l'utiliser dans mes propres applications (application Web et application mobile native) et de la rendre disponible pour des tiers applications (ceci est à des fins futures).

J'ai lu la documentation de Laravel Passport , et je doute que quelqu'un puisse m'aider.

En tant que développeur, j'essaie toujours de trouver la meilleure et correcte façon de mettre en œuvre mes projets et de trouver les packages appropriés aux fins des projets.

Brève explication de ce que je veux faire:

Je veux créer une [~ # ~] api [~ # ~] et je consommerai la mienne [~ # ~] api [~ # ~] = dans mes applications Web et mobiles, mon [~ # ~] api [~ # ~] a deux points de terminaison pour s'inscrire et se connecter pour étudiants et enseignants . Ils peuvent se connecter avec leur email et leur mot de passe. Chaque type d'utilisateur a ses propres informations. Un enseignant peut avoir un [~ # ~] cv [~ # ~] , et les élèves peuvent voir le CV des enseignants (l'ensemble de la création et de la lecture Les CV sont gérés dans mon API), et les deux types d'utilisateurs peuvent communiquer entre eux. J'utilise la version laravel 6.x pour construire mon [~ # ~] api [~ # ~] . Nous avons une section pour les développeurs dans notre sous-domaine qui les développeurs peuvent enregistrer des comptes et obtenir/acheter un jeton d'accès pour faire des requêtes à mon API et l'utiliser, d'autre part, je veux quand les étudiants ou les enseignants se connectent à leurs comptes [~ # ~] api [~ # ~] génère un jeton d'accès pour cet utilisateur afin que mon application puisse utiliser ce jeton et le transmettre dans toutes les requêtes pour que les utilisateurs soient authentifiés pour accéder à leur les ressources privées comme leur tableau de bord, comme nous le savons, API sont sans état et nous ne pouvons pas utiliser de sessions pour stocker les informations d'identification des utilisateurs, nous avons donc besoin d'un jeton d'accès pour cela.

Peut Laravel Passport générer le jeton d'accès développeur et Jeton d'accès utilisateur (enseignant ou élève) ?
Est-il correct d'utiliser OAuth ici pour développer mon [~ # ~] api [~ # ~]? Ou puis-je simplement utiliser le package tymondesigns/JWT à ces fins?

Je dois dire que je suis nouveau dans les applications basées sur l'API Oauth et . J'ai lu quelques articles sur Oauth , et je suis un peu familier avec la terminologie Oauth , mais encore, je ne sais pas comment implémenter ce projet correctement.

Donc, voici mes questions:

  1. Qu'est-ce que exactement serveur Oauth ? Est-ce mon propre serveur hébergé par [~ # ~] api [~ # ~]?
  1. Après la configuration de Laravel Passport et la migration de la base de données, Laravel Passport a créé des tables dans ma base de données, je serais vraiment apprécié si vous pouviez me dire quel est le but de chaque table? les noms de table sont failed_jobs , oauth_access_tokens , oauth_auth_codes , oauth_clients , oauth_personal_access_clients , oauth_refresh_tokens .
  1. J'ai configuré mon application Laravel pour utiliser le Laravel Passport et je créé deux Routes dans mon fichier api.php 
Route::post('login','API\Auth\UserAuthController@login');
Route::post('register','API\Auth\UserAuthController@register');

puis, j'ai créé le fichier UserAuthController.php et j'ai écrit les méthodes de connexion et d'enregistrement. Ils travaillent sans aucun problème. Une fois qu'un utilisateur s'est enregistré ou s'est connecté à son compte, mon code générera un jeton d'accès personnel .

$token = $user->createToken('authentication')->accessToken;

puis les étudiants ou les enseignants peuvent accéder à leurs propres ressources privées avec ce jeton d'accès . Est-il juste de créer un jeton d'accès personnel pour mes deux types d'utilisateurs? Qu'est-ce qu'un jeton d'accès personnel ?
Je sais juste que vous pouvez le passer dans l'en-tête de la requête, et le serveur vous autorisera à accéder aux ressources privées. ce que j'entends par ressources privées, ce sont les points de terminaison qui sont protégés par middleware API comme ceci:

Route::post('/update-info','API\Auth\UserAuthController@update')->middleware('auth:api');
  1. Ai-je raison de créer un jeton d'accès personnel lorsque les enseignants et les étudiants se connectent à leur compte ou je devrais faire une autre façon de le gérer?! cette façon fonctionne, mais je cherche la bonne façon s'il y a autre chose.
  1. La chose étrange ici est Laravel Passport crée un jeton chaque fois que les utilisateurs se connectent et il ne vérifie pas s'ils ont déjà créé un jeton ou non? Si quelqu'un peut accéder au point de terminaison API, il peut faire une demande de publication au point de terminaison/login et créer de nombreux jetons. C'est un problème? Comment le réparer?
  1. Lorsque je crée un jeton d'accès personnel , je dois passer un argument à la méthode createToken($arg), et il stocke dans oauth_personal_access_clients table. quel est le but de cela? Est-ce juste pour Laravel Passport but, ou peut-être que j'en aurai besoin à l'avenir?
  1. J'ai des points de terminaison qui ne sont pas protégés par le middleware auth:api, par exemple, chaque utilisateur visite mon application, il peut rechercher le nom de l'enseignant et leçons et ..., il n'est pas nécessaire de les faire se connecter ou de s'inscrire au préalable. Ces points de terminaison sont accessibles à tous dans mon application, et ils sont libres de rechercher et de rechercher à l'avance certaines informations. Ma question est de savoir si je le rends accessible à tous, comment puis-je protéger ces points d'extrémité qui uniquement mon application tierce et application tierce peut y accéder. Je veux dire que je ne veux pas que les gens y accèdent par ligne de commande ou postman ou une sorte de ces outils sans jeton d'accès, je veux protéger ces points de terminaison des attaquants pour ne pas faire d'énormes requêtes pour arrêter mon serveur. Comment puis-je protéger ce type de terminaux? Je sais que je peux limiter les demandes par minute, mais je ne sais pas combien le limiter? Est-ce qu'il y a un autre moyen?
  1. Je vois qu'il y a un terme appelé clients dans la terminologie Oauth , comme je comprendre les clients sont des applications telles que applications Web ou l'application mobile native et toutes les autres applications qui utilisent mon API sont appelées clients . Ai-je raison? Et je pense que c'est pour l'authentification des applications tierces . Je suis un peu confus après avoir lu la documentation de Laravel Passport sur clients , et quand j'ai configuré le Laravel Passport , il génère deux clients et les a stockés dans la base de données. Dois-je créer un client pour mes applications?! Comment puis-je ignorer le flux d'autorisation juste pour les applications propriétaires?
  1. Après la configuration de Laravel Passport , je peux maintenant voir qu'il génère une route par défaut pour les clients.
/oauth/clients
/oauth/clients/{client-id}
/oauth/authorize
/oauth/token

Quelle est l'utilisation de ces routes ?! en ai-je besoin pour créer mes applications propriétaires ?

  1. Comme je l'ai dit, le but futur de cette application est de rendre l'API accessible par des applications tierces , je dois créer une page Web qui développeurs créer un compte et obtenir/acheter un jeton pour accéder à mon API. est-il possible de le faire avec Laravel Passport ou devrais-je écrire ma propre logique pour le faire fonctionner? Dois-je créer un client pour mes clients tiers?

Merci beaucoup pour votre aide <3

phplaravelapioauthlaravel-passport
7
Parsa mhn

Il va me falloir trop de temps pour répondre à chacune de vos questions en profondeur, j'ai donc essayé de créer un lien vers les sections pertinentes de la RFC pour plus de lecture.

Essentiellement, je vous recommande d'utiliser le flux d'octroi d'informations d'identification de mot de passe pour vos clients propriétaires (votre application mobile et votre application Web). Un des clients que Laravel aurait créé pour vous, aurait été le "Laravel Password Grant Client" et sa documentation est disponible ici .

Vous devrez toujours définir votre propre route "register", mais vous pouvez utiliser la route oauth/token Au lieu de votre propre route /login.

  1. Qu'est-ce que exactement serveur Oauth ? Est-ce mon propre serveur hébergé par [~ # ~] api [~ # ~]?

Le serveur OAuth serait votre serveur qui exécute Passport. Ou dans la terminologie officielle selon le RFC , le = OAuth server/Passport server serait appelé le "serveur d'autorisation".

Dans votre cas, le "serveur de ressources", qui est votre API qui sert votre contenu, serait le même serveur que le "serveur d'autorisation".

  1. Après la configuration de Laravel Passport et la migration de la base de données, Laravel Passport a créé des tables dans ma base de données, je serais vraiment apprécié si vous pouviez me dire quel est le but de chaque table? les noms de table sont failed_jobs , oauth_access_tokens , oauth_auth_codes , oauth_clients , oauth_personal_access_clients , oauth_refresh_tokens .

La table failed_jobs N'est pas directement liée à Passport. C'est lié aux files d'attente de Laravel. Voir Traitement des travaux ayant échoué .

Les autres tableaux sont tous là pour que Passport puisse garder une trace des clients et des codes qu'il a créés.

  • oauth_clients: Voir la section clients RFC .
  • oauth_access_tokens: Voir la section jetons d'accès RFC .
  • oauth_auth_codes: Voir Authorization Code Grant .
  • oauth_personal_access_clients: Les clients d'accès personnel ne semblent pas faire partie de la spécification officielle, mais il s'agit essentiellement d'un client lorsqu'un utilisateur souhaite obtenir un jeton d'accès directement, au lieu de passer par une application ou un site Web. Il s'agit généralement d'un développeur qui souhaite obtenir un jeton d'accès pour pouvoir appeler des points de terminaison d'API sur son propre compte. La table des clients d'accès personnel stocke les clients spécialement créés à cet effet. Habituellement, il n'y en aurait qu'un seul.
  • oauth_refresh_tokens: Voir la section jetons d'actualisation RFC .
  1. Est-il correct de créer un jeton d'accès personnel pour mes deux types d'utilisateurs? Qu'est-ce qu'un jeton d'accès personnel?

Chaque utilisateur devrait obtenir son propre jeton d'accès, mais pas un jeton d'accès personnel.

Les jetons d'accès personnels ne sont que des jetons d'accès qui ont été créés spécifiquement pour les utilisateurs qui souhaitent générer et utiliser eux-mêmes le jeton d'accès. Dans Laravel Passport, en particulier, ce sont des jetons d'accès qui sont liés au "Laravel Personal Access Client".

Donc, dans votre cas, votre serveur créerait des jetons d'accès "normaux" pour les utilisateurs et non des jetons d'accès "personnels".

  1. Ai-je raison de créer un jeton d'accès personnel lorsque les enseignants et les étudiants se connectent à leur compte ou je devrais faire une autre façon de le gérer?! cette façon fonctionne, mais je cherche la bonne façon s'il y a autre chose.

Voir la réponse à la question 3.

  1. La chose étrange ici est Laravel Passport crée un jeton chaque fois que les utilisateurs se connectent et il ne vérifie pas s'ils ont déjà créé un jeton ou non? Si quelqu'un peut accéder au point de terminaison API, il peut faire une demande de publication au point de terminaison/login et créer de nombreux jetons. C'est un problème? Comment le réparer?

Je ne pense pas que ce soit un problème. L'itinéraire oauth/token Est limité par un tarif. Vous pouvez le limiter encore plus.

Vous pouvez également écouter événements et supprimer ou révoquer des jetons si vous souhaitez limiter le nombre de jetons qu'il peut y avoir pour un seul utilisateur.

  1. Lorsque je crée un jeton d'accès personnel , je dois passer un argument à la méthode createToken($arg), et il stocke dans oauth_personal_access_clients table. quel est le but de cela? Est-ce juste pour Laravel Passport but, ou peut-être que j'en aurai besoin à l'avenir?

Ce tableau est juste pour Laravel Passport. Il peut également être utile lorsque vous souhaitez auditer ou déboguer quelque chose plus tard.

La ligne que vous voyez dans la table oauth_personal_access_clients A été créée lorsque vous avez exécuté php artisan passport:install.

Lorsque vous appelez createToken, une nouvelle ligne est insérée dans oauth_access_tokens.

  1. J'ai des points de terminaison qui ne sont pas protégés par le middleware auth:api, par exemple, chaque utilisateur visite mon application, il peut rechercher le nom de l'enseignant et leçons et ..., il n'est pas nécessaire de les faire se connecter ou de s'inscrire au préalable. Ces points de terminaison sont accessibles à tous dans mon application, et ils sont libres de rechercher et de rechercher à l'avance certaines informations. Ma question est de savoir si je le rends accessible à tous, comment puis-je protéger ces points d'extrémité qui uniquement mon application tierce et application tierce peut y accéder. Je veux dire que je ne veux pas que les gens y accèdent par ligne de commande ou postman ou une sorte de ces outils sans jeton d'accès, je veux protéger ces points de terminaison des attaquants pour ne pas faire d'énormes requêtes pour arrêter mon serveur. Comment puis-je protéger ce type de terminaux? Je sais que je peux limiter les demandes par minute, mais je ne sais pas combien le limiter? Est-ce qu'il y a un autre moyen?

Oui, vous devrez limiter le débit. Vous devrez expérimenter et voir ce qui fonctionne pour vous.

  1. Je vois qu'il y a un terme appelé clients dans la terminologie Oauth , comme je comprendre les clients sont des applications telles que applications Web ou l'application mobile native et toutes les autres applications qui utilisent mon API sont appelées clients . Ai-je raison? Et je pense que c'est pour l'authentification des applications tierces . Je suis un peu confus après avoir lu la documentation de Laravel Passport sur clients , et quand j'ai configuré le Laravel Passport , il génère deux clients et les a stockés dans la base de données. Dois-je créer un client pour mes applications?! Comment puis-je ignorer le flux d'autorisation juste pour les applications propriétaires?

Oui, les clients sont comme des applications Web, des applications mobiles, etc. Habituellement, vous avez un nouveau client pour chaque application mobile, application Web, CLI, etc., mais en plus de ces applications, Laravel définit pour vous les clients "Password Grant Client" et "Personal Access Client" qui ont des objectifs spécifiques.

Vous pouvez utiliser Laravel Password Grant Client pour vos deux applications car ce sont des applications propriétaires.

Vous pouvez ignorer le flux d'autorisation pour les applications propriétaires en utilisant la route /oauth/token qui est fournie pour les clients d'octroi de mot de passe.

La section RFC sur le flux d'informations d'identification de mot de passe est disponible ici .

Vous pouvez en savoir plus sur la façon dont la RFC définit les clients ici .

  1. Quelle est l'utilisation de ces routes ? en ai-je besoin pour créer mes applications propriétaires ?

Nécessaire pour les applications propriétaires: - /oauth/token

Non nécessaire pour les applications propriétaires:

  • /oauth/clients: Ceci permet à un développeur tiers de voir quels clients il a créés.
  • /oauth/clients/{client-id}: Pour qu'un développeur tiers mette à jour l'un de ses clients.
  • /oauth/authorize: Cette route sera appelée par un développeur tiers pour démarrer le flux d'octroi d'autorisation avec son ID client et son secret.

Vous pouvez en savoir plus sur les routes ci-dessus dans la section "API JSON" dans Gestion des clients .

  1. Comme je l'ai dit, le but futur de cette application est de rendre l'API accessible par des applications tierces , je dois créer une page Web qui développeurs créer un compte et obtenir/acheter un jeton pour accéder à mon API. est-il possible de le faire avec Laravel Passport ou devrais-je écrire ma propre logique pour le faire fonctionner? Dois-je créer un client pour mes clients tiers?

Laravel Passport fournit Vue des composants que vous pouvez utiliser pour que les développeurs puissent créer des clients. Vous pouvez soit utiliser ces composants, soit créer votre propre frontend et appeler le routes API JSON depuis votre propre frontend.

Gardez à l'esprit que OAuth a été conçu à l'origine lorsque des applications tierces doivent accéder à des éléments au nom d'un utilisateur . Ainsi, au lieu d'obtenir des jetons d'accès, les applications tierces recevront un ID client et un secret client et elles devront passer par l'un des flux d'octroi d'autorisation pour chaque utilisateur pour lequel elles souhaitent agir au nom de.

Si vous n'allez jamais avoir d'applications tierces qui doivent agir au nom des utilisateurs, cela peut valoir la peine d'envisager d'autres protocoles comme mentionné dans les commentaires.

1
Delena Malan