Please excuse my stupidity but is it possible to use something like OAuth2 so that users can log into my app securely even though the app doesn't use any features of Facebook or Google+ etc. So simply I just want something to authenticate my users.
My app makes calls to a database server but currently I have no security what-so-ever and I haven't got a clue as to what to even google for. I want to hold encrypted passwords for the users on the database and pass back some kinda of token to say they're now logged in, but I don't know how to go about this and just wondered if there was something more simple?
I had a long read in the threads here at stackoverflow. I would recommend having a read through this one. If you read the post, what you are looking for is a two-legged authentication, since you already trust the application (your own) you can trust it with the username and password. So, all you need is to authenticate those with your own database at the server and provide an access token to the user.
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.
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.
My web server has a REST API. I need to add user authentication to my app, and my thought process behind it is this:
Get the user's username and password from the app form
Encrypt the password and Base64 encode both the username and password
Send the data to the REST API over HTTPS
Web server verifies credentials, returns errors or success
Is this secure? I see a lot of mentions of OAuth2. What is it? What does it do better than my process?
The fact that you used the word "encrypt" for the users password instead of "hash" demonstrates you have fairly limited knowledge about this. This will almost certainly result in you messing up your authentication procedures somewhere along the line and put your users private information at risk.
A really important point about OAuth2 is that it can be used with many existing third party providers (Google, Facebook, Twitter, etc) with minimal effort from you.
You don't need to do anything to store credentials or even authenticate users. The third party takes cares of all of this and simply provides the client with a token (long random string) which is then passed to your server. Your server then talks to the third-party server to make sure the token is valid (and gain any info you need, like the users' name, email address or other information).
You really should consider using it if you can. The big companies put a lot of effort into securing their authentication methods and you gain all of that by making use of it.
A final nice point is that users don't need to create and remember credentials for (yet) another account.
Google has some docs to get you started and includes an OAuth playground to test how it works in practise.
A very basic explanation of OAuth2 is that the user will log into your system, with it encrypting both username and password before sending it, then if it gets authenticated, it will send back a token to the user.
Thereafter, whenever the user tries to contact the web server, it will send this token along with each API call. This is how it makes sure that non-authenticated people can't access your web server.
So basically your current method includes parts of the OAuth2 standard, but not the most important part (The token).
In your situation, how would you stop non-authenticated people from accessing your web server? If the project is small, then the risk of this is not that large.. But for larger companies, this is a real threat that needs to be dealt with.
You should really try to understand the difference between encryption and hashing before providing an authentication portal for your users. There are many different hashing algorithms you can use. I've personally used BCrypt in the past and I have a related SO Question about it as well. You can find implementations of pretty much all the popular algorithms in pretty much all the major high level languages these days.
Obviously if you don't want to do all that you can use an OAuth provider, who will take care of all the hard bits like storing the passwords securely, protecting the database and all the other security aspects for you. There are many reliable OAuth providers, Google, Facebook, Yahoo, etc. etc.
One thing to bear in mind would be the environment in which your app is hosted. OAuth does depend on having a connection available to the OAuth provider's servers every time a user wants to access your app. So, if you are behind a corporate firewall or similar which may block access to websites like Facebook, this might be a big problem.
I personally prefer token based authentication for my API projects. If you're not familiar with token based authentication you can read this SO Question and this link.
The general concept behind a
token-based authentication system is
simple. Allow users to enter their
username and password in order to
obtain a token which allows them to
fetch a specific resource - without
using their username and password.
Once their token has been obtained,
the user can offer the token - which
offers access to a specific resource
for a time period - to the remote
site.
I'm intested in building some kind of password-less login between a mobile app and an API (assuming I can control both). The motivation is that having to login is very annoying for users and has security risks (eg. users will reuse existing passwords) and I want the users to be able to get started with the app immediately.
I'm wondering if there are some techniques that could work. For instance:
Generate and random login/password on the mobile device and store the password in the keychain.
Signup with the API using this login/password combination. This returns a token.
Token is used in subsequent calls
The drawbacks are:
Login/passwords can be lost if user deletes app (this could maybe be mitigated by using iCloud to store the login - but that would be bad for the password?)
Password is stored on the device (however it's in the keychain)
So my questions: is something like this feasible and secure enough? Are there known techniques to do that?
Here's what we did:
Basically, the idea is pretty similar to the "forgot password" most services offer:
Ask the user for an email
Send an email with an activation link. The email contains a deeplink with a one time token, something like myapp://login?token=......
User opens the email on the device where the app is installed this is crucial for the deep link to work, but it what happens on 99% of the cases anyway. The user clicks the button with the deeplink
User is redirected back to the app, you extract the token from the deeplink on the app and send it to the server api to authenticate. After authentication is done, create a session for the user so they won't need to authenticate again
The good:
More secure: Users don’t have to think of new passwords (which are usually too simple) and there is no risk of users reusing passwords. For us as developers, it offers a solution that has only one (and simple!) path of authentication that is easier to understand and hence to protect. Also, we don’t have to touch any user passwords / hashed passwords.
Smoother onboarding flow to the user: if you pre-enter the email in the input field the login flow can be as short as 2 button clicks and they're in. (unless you wanna take their name / other details as well but that requires additional input fields in traditional login as well)
The less good :)
Users might not be used to this flow very well and might wonder why they don't need a password. I would add a small link explaining "why we don't need passwords?"
If app is deleted or the user logs out, they will need to use their email to log in again. This is less of a problem for mobile apps where users don't occasionally log out and in etc
I've already implemented this flow into our app, you can read a more in depth explanation here:
http://www.drzon.net/passwordless-login-in-mobile-apps/
Some more considerations:
To make it more secure, make the token available to use one time only and also put an expiration on it (like an hour). You can also tie the token to the specific device by sending the server a unique device id of some kind along with the email address. This way the user can't simply forward the email to another person and he will open it instead
About the deep link - I found that some email providers block the use of links with custom url schemes like app://. The way to overcome this is by making the link point to your server instead and redirect there to the actual deep link
https://myserver.com/login?token=... ---> myapp://login?token=...
Mozilla wrote about it as well here
This is very open ended, but generally: don't reinvent the wheel, use a standard solution such as OAuth and/or OpenID Connect (uses OAuth). This has the drawback that users might required to login via a WebView or similar to get a token, but you won't have to store the passwords.
Things to consider:
you can't really generate a random password, since the server needs to know it as well
Android doesn't have a public keychain-like API, so you have to take care of securing the password yourself.
As for 'secure enough', pretty much everyone uses OAuth nowadays(Twitter, Facebook, etc), so it's at least proven. The actual security will depend on your particular implementation.
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.