At the moment, my app (Android and UWP) uses Azure Easy Tables. To upload/update/delete items in the easy table, a user has to be authenticated. But I only want them to be able to authenticate in the app.
Is there a way to restrict this authentication process to only accept authentication requests coming from my apps?
There's really no reliable way to authenticate your client. You can use and validate an application key as documented here, but if you're shipping your application with that information, those wouldn't be difficult to extract.
Alternatives are available (different ways to "fingerprint" your app) and while make it a bit more difficult for other clients to use your API, but none of them are foolproof.
Properly authenticating and authorizing the user is sufficient to guarantee that data is only accessible by users with the required permissions, but there's not a way to absolutely guarantee this is done from your client.
As the figure below, did you enable the App Service Authentication option of the Authentication / Authorization tab of your Mobile App to ON and with non-anonymous authenticate way on Azure portal?
If not, please enable it to protect your Mobile App backend endpoints which include Easy Table, and you need to do the more authentication for calling your Mobile App backend. Please see the details at here.
Related
I'm writing an android app that is a client of a multi-player game.
I need a reliable way to authenticate users in order to connect users with their game account, store their in-game progress and allow them to re-login later and continue playing just where they left off.
An easy solution would be to implement a password-based login and manage passwords all "by myself" (in my app and game server). However, typing passwords on a mobile device is quite inconvenient. Reading up on the topic, they say the best login is a login without password prompt (and generally as little user interaction as possible).
I would expect that the best way to achieve a solid passwordless login in an android app is a google account based login. Every android device is connected with a google account already, right?
Searching around the web and stackoverflow, I was extremely surprised that I was unable to find good documentation about my problem, which I thought to be a standard problem that many must have faced before me.
Some things that look pomising to me:
Google Sign-In Api
Use Google Smart Lock to sign in with a google account (Is this in any way better than sign-in api?)
Use Google Smart Lock to automatically create my own login/password credentials and use them "behing the scenes"
So, what ist the best way to implement a convenient login without password?
My definition of "best" in that context is:
Most convenient to the user. As little interaction as possible.
Reasonably secure to prevent account highjacking.
Depends on how you need to identify your users. If email address is enough, you are probably looking for OpenID Connect. You will get a signed ID token, if the signature checks out, you can trust the info inside, which includes Gmail address. Google has libraries to make this easy, and Android devices already have a token, so users don't have to enter a password.
More info here:
https://developers.google.com/identity/protocols/oauth2/native-app
Google Games login could be a better fit for you, and Firebase makes it easier to manage user data without running your own servers.
I had a similar problem with my app and found that the best solution is to implement the FIDO protocol which allows users to sign-in using a private key stored securely in their mobile device:
During registration with an online service, the user’s client device creates a new key pair. It retains the private key and registers the public key with the online service. Authentication is done by the client device proving possession of the private key to the service by signing a challenge.
To visualize it, here's an explanation with a graph of how FIDO works.
Why is this the best solution?
It's very convenient because your users don't need to do any interaction to log in as long as your app is accessed from the device that holds the private key. You can authenticate them silently from the app. If the user is accessing the app from a different phone, you can send a push notif and show a prompt in your app to approve the login request.
This method is secure because:
It avoids bad passwords from your users.
The private key never leaves the device. This means you never need to store passwords in your database.
The asymmetric cryptography ensures that only the device that holds the private key can make a valid signature.
How to implement it in Android:
For an Android app, the easiest way to implement this is to use Cotter, an authentication service like Firebase but focusing on passwordless login. You can make a free account to get your API keys.
Documentation: This is the guide on implementing the FIDO protocol above for Android.
If you'd like to do it yourself, you can check out the Android Keystore System.
Users sign up in my platform from the mobile app (Android & iOS). Once they have completed a form, I do a RESTful call to my server with the username and password and an API key.
https://api.example.com/v1/users/register
I assume that the API key is not protected since it is embedded in the app, so anyone can actually make that RESTful call and register as many users as they want.
How can I protect this call so that users can sign up ONLY from the mobile app? How do other apps (e.g. Facebook, Twitter,...) solve this problem?
How can I protect this call so that users can sign up ONLY from the
mobile app? How do other apps (e.g. Facebook, Twitter,...) solve this
problem?
There is no way to restrict your RESTful call just for mobile phones. Anybody could emulate that call impersonating a device manipulating headers or whatever. The only way to face this problem is to have a good security protocol design between your app and your backend.
As you mentioned, Facebook and other big companies do not store any API Key since the beginning in their app, instead they allow users to sign up through a website or mobile setting up specific user credentials. These signing ups are protected agains massive registration attacks using anti-bot techniques both from client (CAPTCHA) and server side (source IP + timings). Once those credentials are created and authenticated, their endpoint will return a client specific token which would be valid to make further REST API calls, and only this very user will be authorized to use that token for a limited period of time. One typical approach nowadays is to use Oauth 2.0 as you can see in many public API specifications like: Paypal, Twitter, Facebook, etc. I suggest to research other famous REST API specifications, you can learn a lot from them.
Almost all of known techniques mentioned before like CAPTCHA, server side checks and so on could be defeated by a hacker. However, if you still want to add some additional barriers to avoid unlimited user accounts, one good idea can be to add two-step verification process to verify an account. Unless this process is finished correctly, the user won't be able to use your backend API (apart from the one to authorize the account). Thus, a user may be able to create a few accounts with different phone numbers, but never an unlimited amount of them.
I think you have to devise a flow like reCAPTCHA. Its documentation may give you a hint.
How do all these mobile apps login users? I did a lot of research and read tutorials but I can't find a definitive answer...
I created an API for my Codeigniter web app using Phil Sturgeon's REST server. Now I need to create a mobile app (for Android and ios) that works with remote data from my web server. (I decided to build my app with Appcelerator.)
My goal is to allow users to log in from my mobile app and make CRUD operations via the REST server API. The API uses HTTP digest access authentication but I'm concerned about security because it sends a username and password over HTTP. Is there a more secure way to authenticated users?
After a user is logged in how will they perform CRUD operations without logging in again?
Security is a matter of trade-offs. You need to answer several question.
How much pain can I put the user through to protect the content?
How valuable is the protected content?
What are the consequences of breached security?
Unless you are storing banking information, confidential/personal information, or the content can be irrevocably altered/deleted, HTTPS with digest authentication are fine.
NOTE: digest does not transmit passwords.
I'm currently designing a service that will be half web app, half android app. Each user will need to be able to log in from either the android app or the web app, using an openID account. I'm hoping to target Google first for easiest integration with Android, but I'll also need some OAuth stuff later so that I can integrate with Google contacts.
The bit I'm having trouble with is how to authenticate users. The structure I've planned is that the server (probably using web.py, although that's flexible right now) serves data for the client in JSON, whether the client is the javascript browser client or the android client. However, each call needs to make sure the client is allowed access to that data.
What would be the easiest way to standardise this across the platforms?
Should I be using a session system to authenticate after logging in? Can that be made to work from an Android app? Otherwise, should I simply authenticate with google for every request?
When authenticating from the app, where should the authentication happen, through the server or straight from the app? Where should the auth token be stored in this case? (I'm assuming for a straight webapp the token should just be stored in a table in the user database?)
Sorry for the barrage of questions, but I haven't really found any resources online that clarify these issues very well.
As long as you are using HTTP, the platform doesn't matter. You can use the same form of authentication and/or sessions. The only difference would be that on Andorid you might be able to get an authentication token using the platform's AccountManager, without having to type the username and password in Google's login page.
There's a subtle difference between Authorization (OAuth) and Authentication (OpenId). Make sure you know what you are doing.
I'm developing an android app that consumes a webservice that I will develop too (I'm thinking in using a RESTFul webservice)..
and I want to secure the connection between the app and the server but I need to authenticate users too..
My problem is in the last part, to secure the connection I think the best way to do it is to use SSL (https), am I wrong?
I don't know what's "the best way" to authenticate users, to make sure that a user cannot consume the webservice as another user..
I have some ideas, like using a authenticate(login,pass) method on the webservice that returns a token.. And for any operation that requires authentication the user would need to pass that token as a parameter.. The thing is, is this a good way to do this? whats the most common technique used to auth users in a situation like this?
If a token based auth is a good idea how should I generate the token?
Sorry for this long text..
Any help will be usefull
Thanks
Make sure you understand a trendy standard like OAuth before you go down that path. Most OAuth flows are centered around a user logging in to your server through a web browser. This can lead to pretty bad user experience for a mobile app. The standard does allow for alternatives. Here's a decent introduction.
You could also use an existing identity provider like Google, Facebook, Twitter, etc. instead of implementing your own authN/authZ. On Android, you can ask for a Google auth token using the AccountManager. This usually works because the user needs to be logged in to their Google account to access the Android Market. Anyway, this will prompt the user to grant authorization to your app. You could then use the Google auth token to login your user to your service with your own token. The login would essentially be your server verifying the Google token is valid (by contacting Google's servers) and then issuing its own token to be used for calls to your web services. If you don't like Google, you could use the Facebook SDK, etc.
As for what to use for tokens... The OAuth spec has stuff on that as well. You could do something as simple as a random string or something as complex as encrypted SAML assertions.
You should implement a token based OAuth, which will require the users to log in once, and then permanently have access.
You can use Google App Engine which already provides user authentication services for you (your Android users most likely already have google accounts) But this is only one of many options.
You can also look into Amazon's Identity Access Management (IAM) which will allow you to manage the users who have access to your web service, and authorize them accordingly.
I think the best way to do it is to use SSL (https), am I wrong?
This only prevents certain types of malicious use, but not everything. There is still nothing to prevent people from accessing your database on the phone, and retrieving credentials that way.