I am writing backend for a mobile app where the login info (user), details of the app and everything used in the mobile app will be on the server side.
That's how I have written the app flow:
The created users are saved on the server side via registration API
The newly created users send credentials and after authentication, I generate a dynamic token which is shared with the user for rest of the API calls
For every other call that a user makes, the token is authenticated and then the response is generated.
Each login generates a new token so at a time the same user won't be able to use the same account on 2 different mobiles. Since on valid login, a new token will be generated for API usage.
Whole of the communication takes place over SSL so everything is already encrypted. I want to know the security threats that would be saved by OUATH 2 in this scenario.
P.S Please write your thoughts in comments if you down-vote this question. Will highly appreciate it.
Related
Background
So I've been researching quite a bit for the past week about API's and have been reading about concepts and also programming one.
Currently I have a website which is programmed in PHP using a popular framework called Laravel. The website has a user database and users are able to log into the dashboard on my website, everything works as I want it to for my website side.
Now for the next project of my business i'm focusing on creating my mobile applications (IOS & Andriod).What I need for these mobile applications is being able to login through the application UI (not being redirected to my site with a callback URL) so they are able to view and manage the dashboard.
The method of authentication and authorization that i want to use for my application will go something like
Client asks user to login through UI
User enters credentials
Client sends a request to login to the API
The API checks if the credentials are correct
API creates a token which is stored in token database linked to user ID
API returns 200 OK with a json response or something like this
{ "token" : "OLS25usJIay81hdy81", "expiry" : 3/06/2016 14:00}
Client remembers token and expiry
Whenever a user/client makes a request such as api/v1/mystuff/orders it sends the token with the request(probably through the http headers?)
API verifies token, gets user ID and finds users orders
Questions
I know this is one hell a question and i'm not asking you people to program my entire software haha but what I need to know is
What should I use to create the API (needs to be PHP, and preferably laravel integrated)
What are some good resources to help me program my API
Is there any suggestions/changes you'd recommend?
Requirements
Username/Password authentication
Token Authorization
Login through app UI (Not on my website with a callback)
Notes
My website has a SSL cert.
Laravel is definitely a very good choice to create your API and your plan for authentication and authorization is pretty solid.
I could recommend for you to use the JSON token authentication package for Laravel https://github.com/tymondesigns/jwt-auth
You can see some tutorials here:
https://scotch.io/tutorials/token-based-authentication-for-angularjs-and-laravel-apps
https://www.sitepoint.com/how-to-build-an-api-only-jwt-powered-laravel-app/
I would also recommend this API package https://github.com/dingo/api which will save you a lot of work.
If you need some help you could watch this series https://laracasts.com/series/incremental-api-development from Laracast, which requires a subscription, but it's more than worth it.
I am developing a backend for mobile app. I have developed a user authentication module where, the app will be sending the username and password as basic auth and if the user is authenticated I will sent back a jwt token which can be used in the rest of the requests.
On the client side, once after a user is logged in, the app shows him a feeds screen which contains some data.
Now do I need to seperate these two APIs? Like once a user is logged in successfully, he will be sent back the jwt token and well some user details. Should I sent the data which is required for the dashboard screen as well as a response for login? In that the case the app will get datas in a single api request (login) and doest have to make another call to my API.
Is this a right approach?
Ideally it should be kept seperately but I think that depends. If making that single request is (and will ever be) the only thing the application does, I see no reason for making 2 requests. You can simplify things by making just 1 request.
But, if your application is going to be extended or if its already got other features i think it is best to keep them seperate. Since then you'll have more flexibility with your application.
Yes ,You should separate those two authentication and dashboard REST API as-
It could be possible that there should be more client app using your Rest API in future and they may not require dashboard data.However you can have mechanism to share user detail in authentication API itself as you are anyway authenticating user .However share access token in authentication api along with it's expiration timestamp .Some of Client app which are using your REST API might have use case of autologout from app based on accesstoken get expire.In such case expiration time would help.
I am developing an android application in which users need to register and log in using Facebook.
Approximately, this would be the flow.
Open the app for the first time, authenticate with Facebook, get their data, send the data to my server to create them an account in my application, start session with their new account in my server, get a cookie to perform later interactions.
So far so good.
What I need to know is wich data i have to send to my server, so i can be able to identify the users when they log in for the seccond time.
This is because i need to start session in my server and send a cookie to the android app to do the further interactions. I'm using PHP as server side language.
I was thinking about getting the getAccessToken() in the android facebook sdk, then pass it to my server on the account creation and storing it in my android app.
But i can't manage how to do it to login the users on the second time they use the app.
Any suggestions ? Thanks in advance !
To uniquely identify the user within your app, you should make a request to /me and get the user's id. This is guaranteed to be unique and remain constant for your user/app combination.
The access token is not guaranteed to remain constant.
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 have been doing research on this Oauth concept and I am still very confused about this concept. One of my main questions is how does one register with a google account or a twitter account.
For example, lets say in order to register to my website, you must provide a Username/Password/Email/GroupName. If you register through my website, than you can provide those fields very easily. However let's say the user wants to register through google. How would those fields populate?
From my understanding once you register with your google credentials, you are redirected to a page on my website where you fill in the required fields. I am not sure if this is correct. Can anyone help me understand this more?
Basically OAuth works like this (depending on the version these points consist of multiple steps):
You redirect the user to a provider, where he logs in
The user is redirected back to you and you receive an access token
Using this access token you can then request the users data from the provider. Typically the providers provide a call which you can use to ask for the user's email address, full name and a (provider-specific) user id, but that is not part of OAuth.
How you now use this information to handle that user as if he logged in to your site is then completely on your own. You probably want to create a new user object on your side each time you see a new user id.
There are couple of basic concepts that needs some clarity before one can understand how a new user registration happens using OAuth2. These are:
Resource Owner (You, the human)
Identity Provider (Google, Facebook, Twitter, etc.)
Resource Server (Same as Identity provider, or some other service)
Resources (Things you want access to)
Client app (The app you are using to access those things)
For new user registration, you will follow the same sequence of client app requesting authorization to be granted access to the resources. This will trigger a login page, user logs in, authorization code is created (by the IdP) and sent back to the client app. The client app exchanges this code for an access token (some encryption signing is involved, read up the documentation - basically allowing client app to prove its own identify).
This access token is then used to request access to resources - in this case, the new user profile. This could be name, email, picture etc. Use this to create a new row in your client apps profile database. A new user account is created.
Then for subsequent logins, the client app will use this access token to validate its life with the Google Auth server - and then create a local session/cookie to login the user.
Hope this is clear.