I am building an app with an iOS and Android version. I want to create or implement an existing REST authentication process that can be used by both apps. I know that I can accomplish this with a simple Get service but this would pass the password in the clear. Is there any API that handles authentication for mobile apps?
I don't want to use OAuth because I don't want the user to have to take the extra step of having to allow access to their data. I want the user to seamlessly enter a user name and password and be authenticated like in most mobile apps that I have used.
If you're sure you don't want anything like OAuth then you just need two things :
1) https only - this prevents username:passwords being intercepted (easily)
2) A POST URL to send the username:password to
POST is important! If it was just GET then the username and password would be stored in your server logs and the request might be cached.
You will ned up with something like :
https://www.example.com/myaccount/login
with the POST parameters
username=deanWombourne&password=hunter2
I would then store the logged in state as a property on the server for that session for all future requests.
If you use a secure connection (HTTPS) sending username/password won't be an issue. Other things to think of are, session timeout and session caching on the mobile devices, and the security steps needed for that, intermittent network connectivity issues etc.
Could you show us some of your code so we can get a better idea, it is now ok to use OAuth as users are more familiar with this method and it is more secure without having you to use HTTPS because there is a part of users (me too) who don't accept to write their password on non-official apps, so they may ignore you .
HTTPS is your first choice,.. if possible.
I recommend you to look at amazons S3 auth.
http://docs.amazonwebservices.com/AmazonS3/latest/dev/RESTAuthentication.html
Also look here.
Related
I'm trying to consume a rest services from android.
I want the username and password is entered only once. Then the system can work without having to reapply username and password.
I do not know what would be the right way to do this.
Save the password on the phone seems a bit insecure, maybe it's just my paranoia. applications like facebook, store the password in the phone?
What I'm trying to do is generate a token, store the token on the phone, and send the token in the header in each request.
I do not know if it is the right solution. I can not find how to do this without the token lose the session.
I have also read about OAuth2, but I have not got any example of a small application That Demonstrates the use, not that of Facebook, Google, Twitter.
I used a Spring Server to communicate with my Android app.
I think you need to use OAuth2.0.
for more information refer to this.
I have a background in web development but I am very new to the mobile world. So, I'm not sure how to proceed with this situation:
The user login in the app
The credentials are sent to the server through a POST request.
If the response is ok, it redirects to the main activity.
Now, I want to know if I have to keep the user's ID or not. I know that when we are using a browser the server saves a "session" so the client doesn't need to send the ID everytime to request data. Is that also true with mobile apps (Android)?
By the way, I'm also responsible for building the REST API but don't have any experience targeting mobile devices.
Big question to answer, and it depends and not sure what server technology you are using. However I can describe an approach I implemented (.Net background).
It seems you are writing a mobile app?
The mobile app would first make an authentication call passing id and password to your login api, over https of course. Often the url would be something like
//yourwebsite/Account/Token
Your api would validate the user and if ok, issue a bearer token.
The mobile app needs to remember this token and on subsequent calls pass this in the request header. That's how the server will know who this is. You don't need to send the user id and password any more. And there may be a strong security argument for not storing the user id and password on the mobile device at all.
Now, your server code will validate the token, and you will know who and what the user can do. The token typically expires, so any mobile client needs to check for this and re-authenticate to get a fresh token.
But how will the server know this token, who it belongs to?
In an MVC world for example, there's framework code to help here. There's plenty of MVC template code. If you happen to be developing .Net api services, see this http://www.asp.net/web-api/overview/security/individual-accounts-in-web-api
If you are not .Net on the server, I'm sure there will be something else to help you along the same principals.
As for developing RESTful API's, ServiceStack is seriously worth considering. If too expensive, at least consider their approach and roll your own (especially when it comes to versioning of your api's).
You misunderstand the case with browsers, therefore your conclusion is flawed. Let me explain: When you log in to a website using a web-browser, a session is saved indeed, but not only on the server. It is saved at the client-side as well. Whenever you send a request from there on to the server, you have to send that stored information as well, called cookie to identify yourself.
Let's think about this more deeply: How would a server identify your session as being your session without getting a cookie? By IP address? Nope, the IP address can be used by many and it might change. By browser session? Yes, by browser session, which includes the cookie as well.
Now that you understand that the session is saved by both the server and the client, you surely already know that you need the very same for mobile apps as well. The client logs in, therefore a cookie is generated for the client. This should be difficult to guess. From there on, the client uses the server using the cookie created for it.
If you do not believe me, visit a website where you are not logged in, and then run console.log(document.cookie);, log in, then run console.log(document.cookie) again, then log out andd run console.log(document.cookie) again.
I have a server side script which gets some data that my application uses. Naturally, I don't want anyone else access the data aside from my app. I've heard it's possible to see which url's the device connects when using a certain software. How can I prevent these programs seeing the url's I'm calling to? Or is there a better way of securing the requests?
Only thing I can think of is using a password key in the url (and check if it matches on the server side):
http://example.com/getdata?key=897ihrduiuyqewudiew&get=something
but that probably isn't enough for a secure authentication. And the sniffer programs could still get that url. Any simple way of doing this more securely?
The easiest way is to use HTTPS. This way, only the server to which you connect to can be known by the sniffer.
There are other methods that use complex challenging to have a unique key only valid for a short period of time / a single request, like WSSE (see this article http://www.xml.com/pub/a/2003/12/17/dive.html )
There is very little you can do in order to protect the server requests. Someone will always be able to see the URLs your application hits and using a password in the query string won't help. In order to secure your application you need to use HTTPS and some form of authentication. The user will need to provide a username and password in order to connect.
If I understand you correctly, you should implement mutual authentication. Basically, you have certificates on both your client and server. When a request is made to the server, the server verifies that request is signed by a known client.
So, even if a sniffer knows the url and attempts to issue the same request to the server, it would be rejected since it is not signed by a known client. I am quite new to this as well, but that is the general concept. This blog has the basic steps.
http://blog.callistaenterprise.se/2011/11/24/creating-self-signed-certificates-for-use-on-android/
http://blog.callistaenterprise.se/2011/11/24/android-tlsssl-mutual-authentication/
I have a question which is not really related to android. but because i'm android developer i have taged this post as android post.
In my application i have a login page. in this page i take user name and password from user, then encrypt the password and after that i'm sending them to server for validation. according to response of server, i'll do what i should do.
i think this process is risky. if someone hacks my code s/he can easily do cheat. and also because this project is stock market based project therefore it needs higher security. I afraid that if somebody hack this code, me as a developer or my company be responsible for this issue.
Now, the thing that i want is, the login page should be under control of my client's server. this is my idea:
1- I'll open a connection (the URL should be given to me by client)
2- I'll open another connection to listen to the feedback from server
3- If server says OK, I let the user to go into application.
Is this a good way? Is there any other way?
If someone hacks your code, generally all bets are off. If you want to really protect something, you need to keep it on the server side.
As for not sending the username/password, you can have the client's server act as an identity provider by using a standard protocol such as SAMLv2, OpenID or OAuth. You'll have to select which one fits your needs, but the general idea is that users will login and authorize your app to see their data using you client's server, and your app never needs to see their actual password.
I am in the planning phase a new project. I want to be able to control multiple relays from my android powered phone over the internet. I need to use an HTTP based server as a middleman between the phone and the relays. Django is my preferred platform because Python is my strongest skill set. This would not be a "web app" (with the exception of the admin interface for managing the user and their access to the relays). Rather, the server would simply provide an API in the form of HTTPS requests and JSON encoding. Though, I should note that I have never done any web development in my life, so I don't know best practices (yet). The authentication method should meet the following criteria:
Works over HTTPS (self-signed SSL)
Provides multi-factor authentication (in the form of something you have and something you know)
Be reasonably secure (Would be very difficult to fool, guess at. or otherwise bypass)
Is simple in implementation for the server operator and end user on the mobile client
Is lightweight in in terms of both CPU cycles and bandwidth
I plan to use the following scheme to solve this:
An administrator logs into the web interface, creates a user, and sets up his/her permissions (including a username and a password chosen by the user).
The user starts the client, selects add server, and enters the server URL and his/her credentials.
The client attempts to authenticate the the user via HTTP auth
(over SSL). If the authentication was successful, the server will generate an API key in the form of a UUID and sends it to the client. The client will save this key and use it in all API calls over HTTPS. HTTP auth is only used for the initial authentication process prior to reviving a key, as a session scheme would not be nessessary for this application. Right? The client will only work if the phone is configured to automatically lock with a PIN or pattern after a short timeout. The server will only allow one key to be generated per user, unless an administrator resets the key. Hence, simple, mobile, multifactor authentication.
Is this sound from a security standpoint? Also, can anyone point me to an example of how to use the HTTP auth that is built into Django? From a Google search, I can find a lot of snipits witch hack the feature together. But, none of them implement HTTP auth in the wayit was added to Django in 1.1. The official documentation for REMOTE_AUTH can be found here, but I am having difficulty understanding the documentation as I am very new to Django.
I'm not entirely sure of how basic auth would work on Django, but I can take a shot.
The basic auth article on wikipedia covers a pretty standard usecase for logging in. For Android I've personally skipped the first part (401) and just pass my credentials in right away.
With your auth request you will have to just grab the user credentials from the request headers (WWW-Authenticate) and then do all the necessary work for that. With the credentials you can then just use the authentication framework provided in Django to verify that the user then generate their UUID (I guess).
As for basic auth on Android it's a little bit tricky at first and may leave you pulling your hair. I've found this article on Basic HTTP auth for android which helps explain how to do it.
As for the security part of it, I'm not too sure. It's pretty simple, which I'd say is a good thing :)