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.
Related
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.
I've set up a central app (let's call this maindomain.com), where I've setup Passport. This site will be where users register to gain access to all other apps I create.
To test it out, I've followed Matt Stauffer's blog post to create a client app that will use the user data stored on maindomain.com, let's call this app1.com.
I can confirm that my callback and whatnot work fine. When you go to app1.com/login (as per my route) it redirects to maindomain.com and allows you to authorise app1.com to use your login details - beautiful.
As per Matt's post, right now it prints the token to the screen. I need to change this so that it saves to the database - I assume I should just create a column on my user's table and store it there?
I've tested the token and can access the API routes using Postman. However, because at the moment I'm creating web apps that all need to use this centralised user system, I'm not sure how I can use a login form to authorise users and allow them access to their dashboard.
If user's are logging into app1.com do I send a POST request to maindomain.com? Isn't that going to be a problem with CSRF? I've read the documentation but as this is my first venture into Oauth2 I am pretty confused.
If you want your login form to reside on app1.com, your only choice is Password Grant flow - app1.com will get user credentials and make a POST request to oauth/tokens on maindomain.com trying to get an access token. This POST request may happen in front-end or in back-end (more secure - client password will be hidden), that's up to you.
Otherwise, it sounds like your Authorization Code flow is already up and running. You could just keep redirecting users to maindomain.com (Facebook and most other OAuth2 providers choose this way), use the login form there, and then redirect back and fetch access token based on authorization code. Save that code in your app1.com database and allow users to access dashboard using that. When it expires - start the flow again.
Try watching this video by Taylor (the creator of laravel) to get going:
https://laracasts.com/series/whats-new-in-laravel-5-3/episodes/13
I created repos for both project and confirmed them working as they should:
API Server:
https://github.com/jeremykenedy/laravel-passport
API Consumer:
https://github.com/jeremykenedy/laravel-consumer
Try making protected API end-points in the routing file api.php and use token scopes if needed to further protect the API endpoints :)
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 want to register users to my webinars after they submit a form in my site, this is common practice but I'm having problems authenticating my application.
The problem is that according to the documentation Citrix doesn't support username-password authentication flow (where you put your user and pass in a request and you get a token):
https://developer.citrixonline.com/content/username-password-flow
Instead users need to be directed to a login page to complete their Citrix account credentials, supposedly this can be done by me just once and then save the token, however I couldn't find a method to do it safely, I tried once to save the token and just the next day it was expired. So how can I make sure I get a fresh access token without
I'm using this PHP library which is supposed to simplify the login process (maybe there is some clue in it):
https://github.com/jakir-hayder/Citrix-GoToWebinar-PHP-Library
First, read this primer on OAuth workflow to ensure you have the terms and concepts down pat. (You can ignore the fact that the example is for SalesForce -- OAuth is all the same.)
Then, you should understand that you're looking for the Citrix Token Request Endpoint, which they happen to call "Direct Login".
That should let you pass the username/password to get the token to use in subsequent requests. That what you need?
I would use Fiddler or Wireshark to collect the API calls that are made to the Citrix API when you log in. Then add some code in your applicaiton to send the same requests, parse the response that has the access token, and dynamically use that token however you've already got it set up in your application.
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).