I have a PHP web application that I want to make accessible across multiple clients. So, I'm trying to make it more like an API. My question is: How would I handle the creation of new users using the API? If I have a URL like http://example.com/user/signup which takes new user details and creates a new user via a POST request, wouldn't it be a problem that people can misuse it and create fake users easily?
i would recommend only allowing open id in the API, as it would be hard to implement bot preventing schemes into it (captcha ...)
anyway even open id isint that a great idea in the API are you sure you need registration available thru the API ?
What you need to do is use something like OAuth to authenticate access to your system from registered 'apps'. Then the clients can register for access and receive a token key and secret. Then they can use these things to create a request for an access token. Both parties sign the token using the secret and then they can use the encrypted access token to hit the API. Your server verifies the incoming token using the secret that only you and the authorized clients could have. Now it's secure.
Related
I am implementing an api in laravel.
what I want is my api should not be accessible from anywhere except from android/ios app.I googled and came to know that I can make use of API KEY.
But I am not sure is it correct way or not.
Currently using OAuth2 for user authentication.
Please help.
What you want to do is to create a token for each user, save it in the client's device , verify it in each request that the client makes.
So basically you want to:
Make a column for the token in the users table
generate the token when the user registers
make a login route so that the user would login with his email,password and he will getback the token to store in the device
make a middleware that would check for the token in each request ( except for the login )
I wrote an article of the exact same thing you want
https://medium.com/#alhasaniq/how-to-add-token-based-authentication-to-laravel-app-s-to-use-in-api-s-1a0e45f9106#.15e3f9quu
I'm currently building a web application which is an AngularJS frontend that communicates with a RESTful API built using Laravel. I'm making good progress, but finding it hard to get my head around how to handle user authentication.
I've been advised that I should be using OAuth for authentication, and I've decided to use it seen as it could be a learning experience for me as well. The package I'm using to handle this is oauth2-server-laravel.
The basic user story is that users can register their username/password combination for the application, and they then log into the application with that same username and password. They're only authenticated by their username and password, and not by any client secret. After login, they should be given an access token which will be send along with every future request to authenticate them on different API endpoints.
The OAuth2 library has a "password flow" grant type which seems to be what I need, however it also takes client_id and client_secret parameters, which I don't want. The request URI is something like this:
POST https://www.example.com/oauth/access_token?
grant_type=password&
client_id=the_client_id&
client_secret=the_client_secret&
username=the_username&
password=the_password&
scope=scope1,scope2&
state=123456789
But what I want is just:
POST https://www.example.com/oauth/access_token?
grant_type=password&
username=the_username&
password=the_password
How am I meant to provide a client ID and secret of a user that has yet to authenticate?
Is there a different grant I can be using, or is what I want to achieve just not suited for OAuth at all?
Take into account, that client id and client secret aren't parameters that you have to force your end-user to pass. They are static and defined in/for your client app (angular app in this case).
All you need to do is to create a record for your main app in oauth_clients table, and create a scope with full access in oauth_scopes table, and send this values when requesting token.
And that's all in fact.
Also, you may want to consider using implicit grant flow in case of building js-only application, because storing client secret and refresh token in a js app is insecure. Using implicit grant in a final product may look like login window on soundcloud and is more secure as the token is obtained server-side without exposing client secret.
Another way to go, if you still want to use password flow is creating a proxy for refreshing tokens. Proxy can hide your refresh token in encrypted http-only cookie, and your js-app don't ask your api for new token, but the proxy instead. Proxy reads refresh token from encrypted cookie, asks the api for new token and returns it. So the refresh token is never exposed. If you set token ttl for an hour let's say, then stealing a token would be quite "pointless*" in case of a normal application, and stealing refresh token would be "impossible*".
*Of course if someone really want he probably could hack it any way.
And yeah, i know this all looks a bit hacky - modal windows for logging in, proxy etc. But also searching on this topic i couldn't find any better and more elegant way of doing it. I think that's still a lack that all js-apps have to deal with if you want a token based authentication.
You are missing something with the OAuth specification. The client_id and client_secret are really important when asking for an access token when using the password method of OAuth v2. In fact, they are important for every method that gives you an access token. They identify the application or the server that has perform the request.
For example, let's say you have your API, 2 mobile applications and another server that do some tasks with your API. You will create 3 clients with their own client_id and client_secret. If your application has various access levels (they are called scopes in OAuth v2), the client_id corresponding to the other server will be able to call functions of your API that require the scope admin whereas your mobile application will only be able to call functions of your API that require the basic scope if you have defined scopes like this.
If your API grows up in the future, this is really essential. Another example, let's imagine you have given an API key (a pair client_id and client_secret) to one of your friend and he has build a nice mobile app with your API. If one day he starts doing naughty things with your API, you can't stop him very easily. Whereas you could have just removed his key pair if you had followed OAuth v2 principles.
OAuth v2 is not an easy thing to understand, take the time to read specifications and good tutorials before developing your API.
Some useful links :
The official RFC : https://www.rfc-editor.org/rfc/rfc6749
A tutorial on Tutsplus : http://code.tutsplus.com/articles/oauth-20-the-good-the-bad-the-ugly--net-33216
Just to add a bit to plunntic's excellent answer: remember "client" is not related to "user", so when I use a password flow I just define the client_id and client_secret as constants on the AngularJS app to tell the api backend: hey, this is the browser app that is being used to request a token.
i want to create an Api for my own mobile App to access data that is stored in a MySQL-Database. However i read a lot of articles about the 3-legged OAuth approach and i think this is not the solution i'am looking for. When i understand it correctly the 3-legged approach is more usable when for instance i create a new twitter client and want to use the twitter Api.
But my app is not a third party app, my app and the website incl. the database are from me. So i assume, that the user starts the app enters his user id and password, then the api has a function that checks whether userid/pw are correct and sends "true" as a result back to the app. The app then offers the user the possibility to access the functions for which a login is necessary. So the user should not be redirected to a website and "allow" the access to userid/pw.
If i understand it correctly the 2-legged approach is more likely for my purpose. But i am confused by this also. I assume that the user enters his id and pw, these credentials are looked up in the database by the web service a token will be looked up in the database for this user and will be send to the app. Additionally an app-token is saved in the app from the beginning and will be send with the request also. The app will save this user-token from the DB internally and will use this token everytime the user does something with the web service. With every request to the web service the token will be send to the service and the service checks whether the token is a valid one otherwise an error is send to the app.
I looked up this example:
http://code.google.com/p/oauth-php/wiki/ConsumerHowTo#Two-legged_OAuth
But there is nothing mentioned that the userid/pw from the user are looked up in the database...
Can anybody explain how i can solve this?
Two legged OAuth is similar to Client-Server. It is a client app requesting full access to the data from a server. The client would have full access to all data allowed by it's credentials regardless of which user is accessing the client
Three legged OAuth is a User-Client-Server. It is a Client requesting to get access to the User's data from a server. The Client would only have access to that an authorized user's data (until the user revokes access).
I'm working on an API and considering using OAuth (3-legged approach) for authentication and authorisation.
This is the basic idea:
In order for clients (mobile app or web app), to use this RESTful API the user will have to be logged in using identity providers/servers such as Google, Facebook e.t.c
Essentially 3 parties will be interacting here:
The mobile / web app: The one trying to access my API
The API: The site that contains data for the app to run
The identity server: The site that will allow the user to login in order to access the API
Now, the way that I understand this process (assuming I do). This would be the flow (summarised):
The user will try to access data from the API (consumer);
The consumer finds that the user is not logged in;
The user gets a page (with service provider buttons such as Login with Google);
The user clicks the button, and the service provider returns a login form;
The user logs in;
The service provider returns a page asking for specific permissions;
The user grants permission;
The service provider returns an access token to the user;
The user uses the access token to try the request again to the consumer (API);
The consumer takes the token and verifies it against the service provider;
The consumer grants access to the user.
First
Is this process correct (on a higher level), or have I completely misunderstood the whole thing. If it is not correct: Could you offer some tweaks?
Second
After this whole process. How does the consumer communicate with the user? Will I have to be passing around a token on every request made (between the mobile app and the API)? Or can I just use the user details from the service provider to identify the user?
Third
How exactly does the consumer (API) verifies the token provided by the user against the server? Is this already implemented in OAuth, or will I have to do it myself?
Forth and last
In terms of implementation, what would be the difference between the client (mobile app / web app) and the consumer (API)?
I'm new to this, and I am trying to implement it in PHP (the API). If you have any references to PHP code (sample implementations) or external resources, I'd really appreciate it :-)
I am also new for oauth but I'll try to help.
First you could look here for appropriate libraries which could help.
As for me your oauth flow is correct. A good explanations you can also find here.
Keep in mind that authorization server should return an authorization code which you use for obtaining access token.
So your questions:
1) Follow the second link and there - "Authorization Code".
2) With every request to you API you should send your access token. Something like
http://<your api>?access_token=7f813af1-381d-4dd7-b70b-b6a8399b2c00
3) Just use the libraries from the first link. I hope that they have already implemented this. :)
4)Can't exactly understand what you mean. Your client must be able to obtain access token, store it and send it with requests. Your API server must be able to receive access token from client, and give access to api if the access token is correct.
I am making a mobile application, and I have created an API to send JSON data to the app. The thing is if we called the API with www.domainname.com/example.php?listid=1 this will bring all the list information that has the id of 1. The issue I am having is figuring out how I can prevent an unauthorized user from accessing the API. I want the users to only be able to view the lists that they have created.
I am using PHP
You need to include a secure authentication token with all API requests.
(and validate it on the server)
You should probably also use SSL.