I'm working on developing a native android application to retrieve data for a user from my company's website.
Because the data is specific to the user, I need to authenticate with our web server, but I'm unsure of the best way to go about this. I've been reading about REST/SOAP/HTML form auth, but I can't really find any definite 'this is how its done' anywhere. I know mobile apps do this kind of thing all the time - just look at facebook/skype/any email app - you have to login before you can do anything.
My question is - how should I architect the server side code (php) to easily allow me to authenticate a user from my android device?
I'm fairly new to the 'web service' arena - does this fall into that category? Are there any tutorials you guys would recommend looking at?
Thanks!
While I haven't developed for Android, I can suggest that you simply rely on some stateless authentication scheme, such as HTTP Basic or Digest. This means that the credentials will be passed with each and every request, and you avoid having to keep track of state, which means you can keep your API nice and RESTful.
I suspect if I were writing an android app, in most cases, I'd probably first try to get communication working with something at-least-vaguely RESTful, using HTTP Basic auth, and JSON encoding (just because PHP makes (de)serializing JSON so easy).
Of course, depending on your problem domain, that might not be ideal, but it's a good architecture to try first, because it's pretty easy all-around. If it fails you, you can go back and start swapping parts out, until you find the right architecture.
Some mobile apps use OAuth to authenticate with a web server, such as twitter has. This may not be exactly what you're looking for, but none-the-less here's an example: You would log in to web service and authenticate the mobile app (which would have requested access) to be able to utilize your data on web service, like an access key (actually called a token) with which the mobile app then utilizes to communicate with the web service on your behalf; the token could be then passed as part of the url. You'll still likely want to consider SSL or some level of encryption.
This post may also be of help for you
Related
I'm planning on creating a multi-page web app using Laravel as a back-end REST API and a Vue.js front-end to consume this API.
To be clear up front, I'm not interested in code snippets of exactly how to set this up, unless some will help visualize the architecture.
What I would like to know is how this 'Split-Stack' can be deployed in a completely separated manner. I.E. neither stack shares a codebase, and are stored in completely independent repositories.
I'm not very familiar with JavaScript frameworks beyond jQuery, so I think my lack of understanding lies mainly in the Vue.js department. Some questions which stand out in particular are:
Can a Vue.js application be hosted by a web server to serve static HTML files, if so, which one is compatible?
Can both the front and back end services run on the same server, on different ports for example, and what would be any best practices for this?
And how is login authentication affected by running a web app in this way, and should I be looking into creating some kind of OAuth authentication between the front and back ends?
After reading many blog posts, it is obvious that this architecture is possible, but I'm struggling to find details on how exactly this is configured to be completely separate.
The tools and technologies don't necessarily matter here, but any specifics for Vue.js and Laravel are appreciated.
I have a VueJS Front-End set up with an ExpressJS Back-End, which is very similar to what you are talking about. And yes, it is entirely possible. So let's take a look at each of your questions individually.
Can a Vue.js application be hosted by a web server to serve static HTML files, if so, which one is compatible?
Yes, when you run VueJS, you can either build it as a static application or serve it as a NodeJS Application.
See the Deployment section of the Vue CLI 3 documentation here. It explains how the /dist directory is used to serve the VueJS Application in the manner you are intending to.
Can both the front and back end services run on the same server, on different ports for example, and what would be any best practices for this?
I recently posted an example of how to host both your Front-End and API on the same server here. (Includes Coding Examples and Explanation). This answer references ExpressJS as the API, but the principles are the same. Really, just have your Front-End listening on port 80 and have your API operating on a different, unused port (ie: 8081).
And how is login authentication affected by running a web app in this way, and should I be looking into creating some kind of OAuth authentication between the front and back ends?
I handle all authentication on the back end. Basically, in the Vue Router, you can set a secure parameter. Then declare a router.beforeEach((to,from,next) => {}); call towards the end. This call should then check to see if the user has a valid login token and redirect them to the applications login page after setting a cookie with the URL the user was asked to login from so that they can be sent back to it after logging in.
In our case, we have the user redirected to the VueJS Route /saml/login. The /saml/login component. This component makes a call to the API and returns the address the user should be redirected to to login. In our case, it is the API (which is running on the same server, but a different port [see answer above]), www.example.com:8081/api/v1/saml_login. This then works with the IDP and receives the token and user data. This is also where you would perform you ACS functions (provisioning the user, updating the login time or user data, etc.) After receiving the token, it is placed into a cookie or other placeholder so that it can be used to validate against the token stored in the Database when the user was validated initially. (It is a best practice to set expiration's on your tokens). The user is then redirected to the url stored in the cookie that lets us know where they were asked to sign in from so they can view their content without having to look for it again. (Happy to share code on this if you want)
I think using Firebase or Auth0 Authentication is one of the best ways to do this. Firebase or Auth0 will take care of all the authentication for you and allow your backend to verify the authenticity of your front end. So that makes it much easer to separate the two.
There is an admin SDK for connecting Laravel to Firebase and there are templates and existing authentication SDK's for Vue. There are a few articles which sort of describe it but I haven't seen anything that pieces it all together yet. I was able to figure it out from 2 or 3 different articles and it ended up being easier than I thought it would be.
My question is not deeply technical but more of a system architectural one.
I'm designing an API backend in Go Lang. I'd like to have several clients, like a web server, cell phones etc.. I imagine that all these clients should have a secret API key so to validate that they can use the API. At the same time the web frontend is going to have a lot of users with different restrictions. I'd like for these users to be able to log in with their facebook or Google account. That should require OAuth authentication as I understand. My question is now where should I add the OAuth. Only in the frontend and then save the user in session or also between the frontend and the backend. I'm highly confused about how I should set up this communication and authentication.
I'm building the web server in PHP and I'd like the web frontend to be really light weight and more or less only function as en empty shell/view for the Go API. I've build systems in plain PHP/MySQL before but I'd like to make a shift to Go based APIs.
How would a URI look like to the API from the web server frontend for let's say a show profile page? I imagine something like a GET call to "http.//backend.com:3000/[api-key]/[api-secret][oauth-token?]/profile. Then some middleware to authenticate the web client and another piece of middleware to authenticate the user. Would that be "the right" approach?
I hope you guys can point me in the right direction.
Thanks in advance.
If you look at your facebook or google developer docs, you will find examples on how to integrate with their oauth login systems.
OAuth, or at least the last step of it, really must be done on the back end as you have to assume your front end is a bad guy hitting your system.
For go oauth, take a look at: https://github.com/golang/oauth2
You will likely have a http.HandlerFunc("/oauth/google",yourGoogleFunc)
and http.HandlerFunc("/oauth/facebook",yourFBFunc)
type thing, then you register that URL on your dev account with those companies.
while testing, it's easiest to use localhost:8080 (or whatever) as the callback url so it works on any machine as long as you are using a local browser.
I'm currently working on a mobile application with an Objective C developer. Because of the nature of mobile devices and how they work, all data is retrieved through an API I have created.
For example, if the user is trying to find something specific to do with the application on a page (a search maybe), the application would make a request:
http://mydomain.com/api/search?param1=hello¶m2=world
If these calls are made from the mobile device through the application I know they are legitimate requests (what I class as legit, anyway). If they're coming from somewhere else I really need to stop that. For example, another developer could copy the exact same application and use the API I have built on my server and there is no way I know of that can stop them doing that.
Is there a way I can secure the API some how to stop the API from being accessed outside the app?
Assuming there are no user accounts for authentication, the only way to secure the app is to hardcode a security token in the mobile app. And even doing so, it won't be 100% secure, because of reverse engineering.
Your API only receive HTTP requests, so the only way to differenciate a legitimate with a non-legitimate request is to send a further information that will be considered as valid on your server side (as OAuth tokens), but if there are no user accounts, you will have to send an identical token shared by all apps (or following a commnon rule).
I think that the best solution here is to hardcode the security token, it will at least force "hackers" to reverse engineer your app and not just sniffing the network.
Recently I programmed a little app for my android device. As the datastorage for the app, Iam using a mysql database, which can be accessed via different php scipts. So all the app does, is it sends POST requests to the php scripts to communicate to the database.
But now I consider about the security aspect. These php scripts can be accessed by every webclient. So every webclient has the possibility to compromise my database, which is of course not the ideal case.
So I was wondering if there is a way to just allow authorized clients to use these php-webservices?
Does php provide any kind of authentification that can be used by an android client?
Cheers
You simply need to require an authentification when invoquing the service:
simple and dirty: http basic auth, like Twitter used to do
a better solution is OAuth, like Twitter now does
There are of course other possibilities (WS-Security, but you don't seem to use SOAP).
for security, you should prefer to interact through an API to your mysql...isn't it?
A few points:
Use a different port (i.e: not 80 or 8080) for the web access
Add authentication with a username and password. Inside your application, you can get these from a secure config file.
On the server side, you can also do some checking on user agents, IP addresses and maybe even device ids.
This is just a start
I'm developing a social networking website. This service will be available across various mediums, for example: the web, iPhone, Facebook application etc.
My idea for this application was to have all of these properties interact with one central point for fetching and saving data: an API. My various applications would then interact with this API, sending a GET request to fetch some data; a POST request to submit some data; DELETE requests and so on.
This API will be web-accessible, so I need a way to authenticate only white-listed applications. This API will never be available for third parties to interact with or build third-party applications with; it's to facilitate my applications only so I can cut out re-coding solutions across various platforms and focus only on the logic (controllers, essentially).
Therefore, would OAuth be suitable to be used as the authentication method for the above scenario?
My knowledge of OAuth isn't great, but if it is deemed a viable solution then I'll obviously read up on it before implementing. But as far as I know it works on tokens. A consumer (for example, my website) would request a token from the application (the API in this instance) and then the application would return a token to use in subsequent requests. Or something.
When a request comes in to my application, am I then able to accept/deny requests based on the requesting application? I.e. can I deny access to applications that aren't my own? How do I differentiate between applications? Do I retain a whitelist of IP address or URLs, and compare upon incoming requests?
Any help on the above would be most appreciated.
OAuth is not designed to authenticate some applications the way you want to.
Juste create your own private way to authenticate, because you're the only one to know about your API. Dont forget to pipe the authentication in SSL and everything will be ok !
I don't think OAuth is the best solution for your problem. OAuth is great when you plan to give your API to the 3rd parties as it allows to authenticate user without giving users's credentials to the 3rd party. If you have all control over the API there is no need for this.
It's still a good idea to read about it thou. :)