I am new to microservices, I only know the theory, developed some local examples, and also deploy them to AWS, but just that, and I have a project that has to be done with microservices, but my question is about the structure.
For example, I am planning to do the following:
Vuejs SPA for the frontend store in AWS S3- this will make the request to the Main Laravel app
the Main Laravel app to manage the authorization(login, register, password recovery)
When the user is logged in, is redirected to the "posts" page and that page loads all the posts, you can create new posts, delete them, add comments, etc. This would be another Laravel app, another microservice
Then I have another Laravel app for the user profile, where the users can update their information and also monetize their posts with given options
So, this is my plan:
a SPA stored in S3
a microservice for the Main app that handles authorization, this will be stored in lambda
a microservice for posts, this will be stored in lambda
a microservice for monetization, this will be stored in lambda
I am planning to use serverless so I am a little bit confused.
Where should be the AWS API gateway in the SPA or Main app? or how can I configure it
Should I use only one database and each microservice connect to it?
Should I use different databases? if so, can I how can I synchronize them
If a user logs in to the Main app, it generates a token with sanctum or passport, then this token is sent in the header request to the posts or monetization microservice, is ok this approach?
Should I install a Sanctum or passport?
Should I install Sanctum or passport in all the microservices or only in the Main app?
What can I do? thank you.
If I understand correctly you have one UI communicating with multiple microservices in the backend.
Since you are using serverless, a microservice is probably a set of functions around one functionality that are deployed together. That is totally fine.
In general you will want to have a separate storage area for each microservice. If they are physically different databases or not does not make the big difference in cloud environments because you can always change it according to your needs. The important point is that the storage area is encapsulated by the services. This might mean each microservice has an area within a database that noone else has access to.
This also means you have to use interfaces to get data of other microserivces. There are basically two ways to do so:
synchronously API use of other microservice to retrieve data.
asynchronous data replication via a message bus (event-driven architecture).
For token-based auth: your Main app will create an encrypted JWT token using a private key including user information like email, etc. This token has to be stored in the client and sent to other microservices via a header with every request. They can use decryption mechanisms to ensure the validity of the token and need the public key of the Main app for this. You might consider enter link description hereAWS Cognito libraries because they to that job for you
In general, you should overthink using microservice since they are no silver bullet. You should ask yourself the following two questions:
Do I need to scale development? (e.g. 50 developers +)
Do I need independent deployment/service evolution?
If the answer is "no" to these questions you might consider using some best practices of microservices, but I'd advice against introducing the full overhead of microservices. You could also just have some serverless functions working on a common database.
I'm trying to create an API and use it in my own applications (web application and native mobile app) and make it available for third-party applications ( this is for future purposes).
I've read the Laravel Passport documentation, and I have some doubts that hopefully someone could help me with it.
As a developer, I always try to find the best and correct way to implement my projects and find the appropriate packages for the purposes of the projects.
Brief explanation of what I want to do:
I want to create an API and I will consume my own API in my web and mobile applications, my API has two endpoints for register and login for students and teachers. They can login with their email and password. Each user type has its own information. A teacher can have a CV, and students can see teachers' CV( the whole creating and reading CV's are handling in my API ), and they both user types can communicate with each other. I'm using laravel 6.x version to build my API. We have a section for developers in our subdomain which developers can register accounts and get/buy an access token to make requests to my API and use it, on the other hand, I want when students or teachers login to their accounts the API generates an access token for that user so then my application can use that token and pass that in every requests to make users be authenticated to access their private resources like their Dashboard as we know API's are stateless and we can't use sessions to store user credentials, so we need an access token for that.
Can Laravel Passport generate the both Developer access token, and User( teacher or student) access token?
Is it correct to use OAuth in here to develop my API?
Or can I just use tymondesigns/JWT package for these purposes?
I have to say that I'm new to Oauth and API based applications. I've read some articles about Oauth, and I'm a little bit familiar with Oauth terminology, but still, I don't know how to implement this project correctly.
So here are my questions:
What is exactly Oauth server? Is it my own server that is hosted by API?
After Laravel Passport configuration and database migration, Laravel Passport created some tables in my database, I would be really appreciated if you could tell me what is the purpose of each tables? table names are failed_jobs, oauth_access_tokens, oauth_auth_codes, oauth_clients, oauth_personal_access_clients, oauth_refresh_tokens.
I've configured my Laravel application to use the Laravel Passport and I created two Routes in my api.php file
Route::post('login','API\Auth\UserAuthController#login');
Route::post('register','API\Auth\UserAuthController#register');
and then, I created the UserAuthController.php file and wrote the login and register methods. They are working without any problem. After a user registers or login into their account, my code will generate a personal access token.
$token = $user->createToken('authentication')->accessToken;
and then students or teachers can access to the private resources of their own with this access token. Is it right to create a personal access token for my two types of users? What is exactly a personal access token?
I just know you can pass it into request header, and the server will authorize you to access private resources. what I mean by private resources is the endpoints which are protected by API middleware like this:
Route::post('/update-info','API\Auth\UserAuthController#update')->middleware('auth:api');
Am I doing right to create a personal access token when teachers and students login to their account or I should do another way to handle it?! this way works, but I'm looking for correct way if there is anything else.
The weird thing here is Laravel Passport create a token every time users login and it doesn't check if they have already created token or not? If someone can access the API endpoint, they can make a post request to /login endpoint and create a lot of tokens. Is it a problem? How to fix it?
When I create a personal access token I need to pass an argument to createToken($arg) method, and it stores in oauth_personal_access_clients table. what is the purpose of this? Is it just for Laravel Passport purpose, or maybe I need it in the future?
I have some endpoints which are not protected by auth:api middleware, for example, every user visit my application they can search for teachers name and lessons and ... , it's not necessary to make them login or register first. These endpoints are accessible to everyone in my application, and they are free to search and advance search for some information. My question is if I make it accessible to everyone, how can I protect these endpoints that only my first-party app and third-party app can access them. I mean I don't want people to access them by command line or postman or some kind of these tools without access token, I want to protect these endpoints from attackers not to make a huge requests to make my server down. How can I protect this kind of endpoints? I know I can limit requests per minute, but I don't know how much limit it? Is there any other way?
I see there is a term called clients in Oauth terminology, as I understand clients are the applications like web applications or native mobile app and any other applications that use my API are called clients. Am I right? And I think this is for third-party application authentication. I'm a little bit confused after reading Laravel Passport documentation about clients, and when I configured the Laravel Passport, it generates two clients and stored them in database. Do I need to create a client for my Applications?! How Can I ignore authorization flow just for first-party applications?
After Laravel Passport configuration, now I can see it generates some default route for clients.
/oauth/clients
/oauth/clients/{client-id}
/oauth/authorize
/oauth/token
What is the usage of these routes?! do I need them to create my first-party applications?
As I said the future purpose of this application is to make the API accessible by third-party applications, I have to create a web page that developers register an account and get/buy a token to access my API. is it possible to do it with Laravel Passport or I should write my own logic to make it work? Do I need to create a client for my third-party clients?
Thanks a lot for your help <3
It's going to take too long for me to answer each of your questions in depth, so I've
tried to link to the relevant sections in the RFC for further reading.
Essentially, I would recommend for you to use the password credentials grant flow for your first-party clients (your mobile app and web app). One of the clients that
Laravel would have created for you, would have been the "Laravel Password Grant Client" and its
documentation is available here.
You would still need to define your own "register" route, but you can use the oauth/token route
instead of your own /login route.
What is exactly Oauth server? Is it my own server that is hosted by API?
The OAuth server would be your server that is running Passport. Or in the official
terminology according to the RFC, the
OAuth server/Passport server would be called the "authorization server."
In your case, the "resource server", which your API that serves your content, would be
the same server as the "authorization server."
After Laravel Passport configuration and database migration, Laravel Passport created some tables in my database, I would be really appreciated if you could tell me what is the purpose of each tables? table names are failed_jobs, oauth_access_tokens, oauth_auth_codes, oauth_clients, oauth_personal_access_clients, oauth_refresh_tokens.
The failed_jobs table is not directly related to Passport. It's related to Laravel's queues. See Dealing With Failed Jobs.
The rest of the tables are all there so that Passport can keep track of the clients and codes it has created.
oauth_clients: See the RFC clients section.
oauth_access_tokens: See the RFC access tokens section.
oauth_auth_codes: See Authorization Code Grant.
oauth_personal_access_clients: Personal access clients don't seem to be part of the official specification, but it is basically a client for when a user wants to get an access token directly, instead of going through an app or website. Usually this would be a developer who wants to get an access token to be able to call API endpoints on their own account.
The personal access clients table stores clients that were specifically created for this purpose. Usually there would
only be one of them.
oauth_refresh_tokens: See the RFC refresh tokens section.
Is it right to create a personal access token for my two types of users? What is exactly a personal access token?
Every user would need to get their own access token, but not a personal access token.
Personal access tokens are just access tokens that were created specifically for users who wants to generate
and use the access token themselves. In Laravel Passport, specifically, they are access tokens
which are linked to the "Laravel Personal Access Client."
So in your case, your server would create "normal" access tokens for users and not "personal" access
tokens.
Am I doing right to create a personal access token when teachers and students login to their account or I should do another way to handle it?! this way works, but I'm looking for correct way if there is anything else.
See answer to question 3.
The weird thing here is Laravel Passport create a token every time users login and it doesn't check if they have already created token or not? If someone can access the API endpoint, they can make a post request to /login endpoint and create a lot of tokens. Is it a problem? How to fix it?
I don't think this is a problem. The oauth/token route is rate-limited. You can rate-limit it even more.
You can also listen to events and delete or revoke tokens
if want to limit the amount of tokens there may be for a single user.
When I create a personal access token I need to pass an argument to createToken($arg) method, and it stores in oauth_personal_access_clients table. what is the purpose of this? Is it just for Laravel Passport purpose, or maybe I need it in the future?
This table is just for Laravel Passport. It can also be of use for when you want to audit or debug something later on.
The row that you see in the oauth_personal_access_clients table, was created when you ran php artisan passport:install.
When you call createToken, a new row is inserted into oauth_access_tokens.
I have some endpoints which are not protected by auth:api middleware, for example, every user visit my application they can search for teachers name and lessons and ... , it's not necessary to make them login or register first. These endpoints are accessible to everyone in my application, and they are free to search and advance search for some information. My question is if I make it accessible to everyone, how can I protect these endpoints that only my first-party app and third-party app can access them. I mean I don't want people to access them by command line or postman or some kind of these tools without access token, I want to protect these endpoints from attackers not to make a huge requests to make my server down. How can I protect this kind of endpoints? I know I can limit requests per minute, but I don't know how much limit it? Is there any other way?
Yes, you'll have to do rate-limiting. You'll have to experiment and see what works for you.
I see there is a term called clients in Oauth terminology, as I understand clients are the applications like web applications or native mobile app and any other applications that use my API are called clients. Am I right? And I think this is for third-party application authentication. I'm a little bit confused after reading Laravel Passport documentation about clients, and when I configured the Laravel Passport, it generates two clients and stored them in database. Do I need to create a client for my Applications?! How Can I ignore authorization flow just for first-party applications?
Yes, clients are like web applications, mobile apps, etc. Usually you would have a new
client for every mobile app, web app, CLI, etc., but in addition to those apps, Laravel defines
the "Password Grant Client" and the "Personal Access Client" clients for you which have
specific purposes.
You can use the Laravel Password Grant Client for
both of your applications since they're first-party applications.
You can ignore the authorization flow for first-party applications by using the
/oauth/token route that is provided for
password grant clients.
The RFC section about the password credentials flow is available here.
You can read more about how the RFC defines clients here.
What is the usage of these routes? do I need them to create my first-party applications?
Needed for first-party applications:
/oauth/token
Not needed for first-party applications:
/oauth/clients: this is for a third-party developer to see which clients they have created.
/oauth/clients/{client-id}: for a third-party developer to update one of their clients.
/oauth/authorize: this route will be called by a third-party developer to start the
authorization grant flow with their client ID and secret.
You can read more about the above routes under the "JSON API" section in Managing clients.
As I said the future purpose of this application is to make the API accessible by third-party applications, I have to create a web page that developers register an account and get/buy a token to access my API. is it possible to do it with Laravel Passport or I should write my own logic to make it work? Do I need to create a client for my third-party clients?
Laravel Passport provides Vue components that you can use so that developers will be able to create clients. You can either use these components or you can create your own frontend and call
the JSON API routes from your own frontend.
Keep in mind that OAuth was designed originally for when third-party apps needs to access things on behalf of a user. So instead of getting access tokens, third-party apps will get a client ID and client secret and they will need to go through one of the authorization grant flows for each user that they want to act on behalf of.
If you're never going to have third-party apps that need to act on behalf of users, it might be worth considering other protocols like mentioned in the comments.
I am developing a web app using Laravel, But I have to integrate the mobile application in the future. Now I want to ass API Authentication passport. I am a little bit confused how passport API handle multi auth system form multiple user and permission systems. Currently, I am using Laravel default auth to handle user. Is there any library for Laravel multi auth using API Authentication passport??
The thing you have to understand about Passport is that it is nothing more than a Laravel wrapper of the oAuth2 framework, specifically this implementation: https://github.com/thephpleague/oauth2-server
As such, you must understand how the different oAuth2 grant types work. I recommend reading up on oAuth2 to familiarize yourself with the concepts (I personally found this site to be the most helpful for understanding the different grant types: http://www.bubblecode.net/en/2016/01/22/understanding-oauth2/).
Specifically to your question, take a look at Password Grant Tokens (https://laravel.com/docs/5.6/passport#password-grant-tokens) for use in a mobile app. Once you have your token, Laravel handles all the Authentication behind the scenes and you can use Auth::user() as you would normally, assuming you have Passport set up and configured correctly; the user is tied to the token and is independent of any other token and any logged in user.
As for permission systems, Passport uses scopes (https://laravel.com/docs/5.6/passport#token-scopes) which is a handy way of limiting what routes your tokens have access to. Aside from that, permission management for the Auth::user() is the same as any other user using your application.
EDIT:
Passport scopes are used to lock down routes, so they can be used. However, Passport is only concerned with authentication (ie, is this user valid) and NOT with authorization (ie, what can this user do). How you authorize users to do different things is 100% independent of Passport and is up to your web app.
I was already looking for quite some time for my issue:
have Several Independend Apps implemented in Symfony
Each uses an centralized API
Login should be handled by an own central Application
My Idea is
domain security.xxxxxx.xxx handles the login form and app
domain frontend.xxxxxx.xxx handles the working customer stuff
domain cms.xxxxxx.xxx is the non loged in users stuff
domain backend.xxxxxx.xxx handles staff administration stuff
domain support.xxxxxx.xxx handles user support related stuff
domain api.xxxxxx.xxx handles the central database related stuff for internal and third party applications
domain reg.xxxxx.xxx handles new user registrations
domain job.xxxxxx.xxx handles the job worker stuff
domain monitoring.xxxxx.xxx handles the monitoring of app data etc.
the main idea is that each system is handles by an unique server.
All are connected within the same network but each have different resources and services connected to it.
I tried to use lightSaml for symfony. But don't get the point in how to implement the server component for providing identities.
The security should be provider and authentication interface.
Kind of handling like my.atlassian.net.
This is an Service like I would love to implement.
Any hints are appreceated.
SingleSignOn can ba achieved in many ways and protocols:
SAMLv2
Oauth2
JWT
OpenID
etc
There is two considerations:
Work with tokens
Work with users
For business constraints I could not use a third party provider (Auth0, Okta, etc) which I really encourage.
Implementations: https://en.wikipedia.org/wiki/List_of_single_sign-on_implementations
Work with tokens in symfony
You store the access and refresh token (It may change the name on each implementation). This has the limitation that as the Symfony app is not constantly running only when you have a request you have to reload/refresh the user per request (Request to the Identity Provider server).
Benefits:
Single sign out as once you logout to the Identity Provider you invalidate the sessions.
Risks:
You will get a request to the Identity Provider for each request in your app.(You can make workarounds there it is a Symfony implementation limitation)
Working with users
You authenticate and authorize the user on the Identity provider and create a user in the microservice you have.
Benefits:
Full control of the user data you store. Once authenticated you do not need access to the identity provider.
Risks:
Once you logout of your app if you have not logged out from your SSO/Identity provider the user will automatically logged in back.
You have to keep user details in sync or do not allow the user to update their personal details that comes from the Identity provider in your microservice.
My case: OAuth2
I've personally choose working with users on the symfony services as I want to have more freedom on how I store the user details, which details I store and keep most of the traffic on the service.
Ideally I wanted to use SAMLv2 but I could not find any solution that I was willing to carry over for a long time implemented in PHP, there is many in JAVA.
Technical stack on the Identity Provider
Symfony 2.7 (We have planned to upgrade but it is not a priority now)
FOSOAuthServerBundle : https://github.com/FriendsOfSymfony/FOSOAuthServerBundle
MySQL
MsSQL
Technical stack on the Microservice
Symfony 3.4
MySQL
FOSUserBundle
HWIOAuthBundle https://github.com/hwi/HWIOAuthBundle
If you decide to work with OAuth2 I recommend you this guide: https://alexbilbie.com/guide-to-oauth-2-grants/
I'm writing an app that has both client and admin side and I need roles and sub-accounts (for client side) feature.
I understand that there are many of this question but I'm not sure which way to go as I want the admin side too. What would be the best way to do the admin side? what about setting different user groups (ie group client and group admin) or else?
Any thoughts for Laravel5 package or something?
Thank you
Laravel 5.0 comes with a basic Auth system but doesn't comes with ACL.
ACL can be implemented in so many ways based on user requirements it would not make sense to ship an ACL with Laravel core.
There are many ACL on packagist.
Personally the role based access controlled (RBAC) I've used in past project is:
https://github.com/Zizaco/entrust