I have a CodeIgniter App that is made of 3 parts:
The API, basically is a separate entity, with its own location
The CodeIgniter back-end that renders the pages
The FrontEnd of the app, mostly jQuery.
I have a login system based on session and cookies. Basically the authentification data is stored on the client (browser).
A user authentificates with email and password. The backend looks for a authentification cookie and knows if it is logged in or not. If I make an AJAX request to the API directly, the API also knows if the user is authentificated.
Problem: I want to render some data server-side (That means I need to make a call to the API from the backend. It's a server to server communication. They are located on the same machine. ).
The API tells the backend that it's not authentificated, because obviously no cookie is set on the backend.
How do you pass authentification data from backend to api?
I might pass the userID via a secure endpoint that can be accessed only via the server to server communication, but I don't like the idea.
Any solutions to this? I read about oAuth and JWT but don't understand how they might help me.
the API should be built on top of the back-end. meaning the request is handled by API, then activates a function in the back-end and sends a response back to the client who sent the request(according to the result of the function in the back end). JWT json web token, is a token provider which means once you log in you get back a token "string" that is stored in the data base, in the request for the API you add the token to the header named Authorization instead of sending user and password everytime and you can extract the user info out of the token itself.but still there is need to check the validity of user and pass somehow at the first time.
basically you should send from client to API, API to server and then for response server to API and API to client. by server i mean back-end.
Related
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'm working on a Single-Page-Webapp (SPA) with angularjs (JavaScript) in the frontend and a php rest api in the backend.
I do a lot of ajax calls to the server for example to submit a new story. There the security question came up. The server needs to identify the request. Since it's an SPA only one client (the frontend) should be have the permission to do this request.
I've been googleing for days to find a way to identify the client. I saw that i could send a clientid in the header of the ajax call but that would not be secure since the frontend is in JS and all the JS code can be seen by the user.
Example:
$http.post("some/url", somedata, {
headers: {
"ClientId":"someidforthisclient"
}
});
a hacker could look into the JS code and copy the ClientId. With that he could make ajax calls and the server would think this request is valid.
So my question is:
How can i identfiy the client in the server but with the guarantee that the ClientId (or a security token etc.) can not be seen by the user?
How can i identfiy the client in the server but with the guarantee that the ClientId (or a security token etc.) can not be seen by the user?
You cannot. It is absolutely impossible. For all intents and purposes, as far as the server is concerned, the client application and the user of it are one entity.
You have to trust your users, not their software.
All you need to do is expose the api of login and registration to the users. For any other api access, first you need to authenticate if user is logged in/active.
For authentication you can store user credential in session :
Now user credential will be sent to the api on each request and you will be able to authenticate before processing the request.
You should at the same time encrypt user credential being saved in session so that no one can read that from browser console.
I'm building a mobile app for my website using Phonegap and I am using PHP Codeigniter framework to create my REST API. I need to allow users to log in to the app and retrieve information but I am little confused on the authentication part.
Right now this is what I have in mind:
User logs in with username/password (they will be send to the server using HTTPS)
My API will check the db to see if the user exists
If the user exists generate a random string (token) and send it back to client
On the client side (mobile app), store the token somewhere
Every time user requests information from the server, send the token for validation
I decided to go with token method because I needed to allow users to stay logged in to the app once they login for the first time (I read that storing username/password on client side is bad).
So here are my questions,
Is my method valid/safe? If so how is token stored on phonegap? Will localStorage do the job?
Is there a better & simpler method?
Are there libraries that could help me do this easier/faster? especially with building REST API?
Lastly, I heard about OAuth2 but is this only for when you want to allow 3rd party logins (google, facebook etc)? I've looked into it and there seems to be an OAuth for PHP and OAuth for Phonegap. If I implement this, will I need to do it in my REST API AND phonegap side?
I'm fairly new to all this so any explanations with examples will be helpful.
I suggest to use your token method.Every time app launches check the localstorage for user token is set if not set up http request and store the token in localstorage.
Here is sample code
function validateUser(username,password){
//get the user token from local storage
if(window.localStorage.getItem('usertoken')==null){
//set up the http request
$.ajax({
url:'www.example.com/login.php',
method:post,
data:{'username':username,'password':password}
success:function(data){
//set the token in localstorage
window.localStorage.setItem('usertoken',data);
}
});
}
}
}
I am working with PHP and Laravel at the moment, I have a restful api that the user needs to authenticate with to make sure they can only access things they own etc.
What I want to know is where should the token from the server be saved on the client? In a session a cookie? The servers database?
I suggest to go the following route:
the user logs into your site and requests a API usage token
when a new request to your API comes in, compare the token from the incomming request, with the token in the db. if it is found, it's a valid request. the REST client could use the Authorization header to send the token.
send the answer for the request
While the login system of your website, might be session-based with cookies on client-side, the REST API is token-based and doesn't need a cookie or session.
Please take a look at this for more details:
https://softwareengineering.stackexchange.com/a/141434/111803
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).