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've developed a website with the usual crud functionalities in Codeigniter and MySQL. I'm now tasked with creating a mobile app (with the same functionalities ) in Ionic 2.
To access my database with Ionic, I created a REST api -- which I was able to manipulate smoothly.
My questions are:
How, or can I, use my MySQL users' credentials to log in on my Ionic 2 app?
How can my web and mobile can share the same database?
I've been reading a lot about Fire base,etc. However, my tiny brain is unable to comprehend whatever I read. If anyone can point me to right direction, I would highly appreciate it. Thanks!
When developing an Ionic App you have to think of it as if you were developing a regular website. The only difference is that you have access to native device features with cordova plugins, but the whole flow is almost exactly like in a regular website (it is an angular application after all).
This means you can use your API just like you use it in your website. There is no need to use firebase. (Firebase is kind of like a database itself that you could use INSTEAD of your MySQL backend)
Totally agree with #Andreas. When you build a modern application that supports on the different platforms such as web or mobile, you need to design a standard API and then next step is to build a web application/mobile app to consume this API. And because of all the web/devices are all consuming from the same API, they are interacted with the same database. Unless they are using different API.
Can refer to the image below for easy understanding.
So talk about how authentication and authorization can be done from the mobile app or from the web app. You should take a look at OAuth2. It is a protocol for securing API services from untrusted devices, and it provides a nice way to authenticate mobile users via what is called token authentication.
The workflow will look like below, on both web and mobile app.
A user opens up your mobile app and is prompted for their username or email and password.
You send a POST request from your mobile app to your API service with the user’s username or email and password data included (OVER SSL for sure. If you don't know about it, google it).
You validate the user credentials, and create an access token for the user that expires after a certain amount of time.
You store this access token on the mobile device, treating it like an API key which lets you access your API service.
Once the access token expires and no longer works, you re-prompt the user for their username or email and password.
Reference
REST API from PHP
The ultimate guide for Mobile Security
I'm working on a project where I'm developing a platform. As a solo-developer I made the decision to use Lumen as a PHP back-end and create an RESTful API.
Web shops should be able to install a plugin so they can access the API without having to code themselves.
I need to keep track of the web shops that use the API. I just need the same way to retrieve access tokens like Twitter and Facebook do when you register an app.
So I was thinking about OAuth2 Server but I have never used it before so I'm not sure if I'm on the right path...
If you want your own OAuth2 system then yes you will need a server running it.
The idea of OAuth2 is to authenticate your clients where a shop equals one client.
OAuth2 is not about individual users but clients. With that idea in mind you can setup an OAuth2 server and its only job would be to authenticate each request, make sure it belongs to a recognized client and then issue a token.
With that token you can then go on and issue more requests to actually interact with the system you are building. This is a very high level view of the entire system, of course.
There can be multiple variations on this, how tokens are issued, what type they
are etc. I prefer JWT ( JSON Web Tokens ) as it's JSON and thus lightweight.
A quick search revealed this: http://bshaffer.github.io/oauth2-server-php-docs/overview/jwt-access-tokens/
I do have my own article on building your own OAuth2 system, however it is based on dot net not PHP. You are welcome to use it though maybe it will help clarify the concept.
Here's the link : https://eidand.com/2015/03/28/authorization-system-with-owin-web-api-json-web-tokens/
I'm building a REST API using Symfony2 (FOSRestBundle and FOSOAuthServerBundle) and I'm unsure on which grant type to use for this service.
I will have other developers register as users. I was looking at GitHub, and for each user they have a section called 'applications' in their settings which allows adding an application and it gives back client_id and client_secret. But AFAIK GitHub uses the authorization grant type which means you're sent to GitHub to accept and then redirected back to your application with the auth code (does the auth code live forever or what?). I'm not sure if this is what I'm looking for.
What I want is a way to allow developers to consume my API with me knowing who is accessing (FOSUserBundle integrates pretty well here) and what they are allowed to do.
Also, I'll have my own browser based application, Angular.js probably which is the main website where developers can register. It will make API calls to present data for whichever dev logs in. I could use a Node.js backend (need it for some other stuff) so the actual calls are made from there instead as it seems browser only applications aren't really safe. I was thinking of using client credentials grant type from the Node.js backend.
And last, I'll have my own mobile app interacting with the API. Since it's a trusted service it should use Resource owner credentials grant, right?
I'm not sure I understand what you ask for here. As I understand it your developpers will have an account on which they will have to log in in order to use your API. In this case Client Credentials does not seem appropriate, since it would not identify a developper but a client. A client does not represent a user, it represents "an application that accesses your API" (it, in your case you would have one client for your mobile App and one client for your Angular website). I would use a password grant type, that does not redirect you to an external service.
When I had to implement a OAuth2 authentication for my API, I found this article very helpful, it is based on a Symfony2 example but most of the explanations apply everywhere.
I am developing rest apis in symfony application.
Right now my apis are used by my application only on frontend (ajax requests by Angularjs). In future I would like to expose same APIs to third party applications as well.
Also I will be having have Android, IPhone apps etc in future.
I have integrated FOSOAuthServerBundle, and have tried all grant type workflows. Its all working. But I am confused about can these be used by my application or are they for only 3rd party applications who like to integrate with my application ?
I understand how these workflow can be used by 3rd party apps. But really can't understand how can I authenticate my native application users ?
I want to know how to use this bundle to authenticate users on my website through rest apis from my frontend app ?
Currently I am usnig FOSUserBundle and form_long to authenticate user but I am changing frontend to use Angularjs and rest based. So ideally authentication should just work like form_login authentication but it should be rest based.
I did research on it and people suggest to use "Resource Owner Password Credentials" But it needs client secret to be exposed in javascript which may not be secure
It should work e.g. user submits username/password credentials like it works in case of form_login but instead of redirecting it should just return access_token.
Do I need to write my custome authentication provider which uses UsernamePasswordToken and firewall listener like OAuthListener which returns access_token ? Would that be secure to use?
The similiar question with some discussion here:
Symfony2 FOSOAuthServerBundle grant type password requires client secret
If you don't want to expose secret, use a proxy beetween your front-end angular code and actual OAuth server. Anyway, if you expose secret it still needs user credentials.
You can set allowed grant types to each OAuth client, so in case you create mobile apps, you'll want to generate a separate pair of client_id & client_secret for the app and for the front-end, with the only allowed grant type of "password" for the front-end app.