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.
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 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).
I am building an iOS application and I need to be able to make authenticated requests to a php 5 application for various bits of data. The php 5 application is using codeigniter framework and URLs like https://example.com/controller/function to, for example, authenticate users via twitter... and once authenticated, stores the authentication in a secured cookie named "auth.""
What I want to know is how to authenticate my users from the iOS/iPhone application, persist the authentication token and send it along with future requests to the codeigniter application?
The big picture is that you need to implement something like an api controller in the code igniter app. This controller should have an "auth" method. At some point, you're going to want to pass a hash of the twitter cookie to the ios app. Then, for each subsequent call to the api controller, send along the hash, your code igniter app will associate the hash with the properly authenticated user and allow it access. If anyone else tries to access the api calls, they will either fail to do it, and be denied, or they will supply a guess and be denied.
So from your ios app's perspective, all its subsequent calls (after authentication) will look like:
https://example.com/api/<function name>/<session hash>
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.