Why we chose OAuth for eVitabu

Authentication is always a challenge when designing a system, and it's important to consider how your users will access your service.  Back in 2017, Security Magazine wrote an article following some research by LastPass that stated the average business user has 191 passwords.  One of our goals with eVitabu was not to add to the number of passwords a user has, unless we couldn't avoid it.

The problem with passwords

As often as we hear the statement that "the password is dead" it's still here, alive and kicking.  Indeed, even if we replaced the password with something else, e.g. biometrics, all we would accomplish is a password by a different name.  The goal of a password is to verify who a person is purporting to be.  This is achieved because, in theory, only the account holder (person) and the system (e.g. your computer) know the account's password [1].

Unfortunately humans are known to make poor password choices, largely down to poor education (or poor advice) and laziness.  We're not built to remember hundreds of passwords, we're bad at producing good passwords and historical advice is so ingrained that some people still choose weak passwords because they've not been given new guidance yet.  By the time you add passwords constraints such as "must contain upper case, lower case, a symbol and a number" you arrive at a position where the user will just use the password they made last time.  An example of a registration page with password constraints is shown below, with a purple arrow pointing at the constraints.

All is not lost though, and a good password manager like LastPass can generate a good password for you and save it.  Password managers solve a lot of problems and I'd highly encourage making use of one if you don't already.

Password reuse

As I mentioned, people aren't good at remembering lots of passwords, and often just reuse one they already have.  I was speaking to a friend recently who told me she uses the same password for everything (she even gave the password to me [2]), meaning that once you're in possession of that password it's trivial to login to Facebook, Twitter, MySpace (remember that?), email - you name it.

Credential theft can then lead to credential stuffing, where a person's username and password from one site (Facebook) is then tried against another service (email).  On a large number of occasions the attacker will be able to login to the other sites because of password reuse.

Clearly, we didn't want eVitabu to be easily attacked due to someone's reused passwords.

What is OAuth?

OAuth is a mechanism for getting authorisation to use a system, based on using a good username and password belonging to another system.  We call the authorising system (Google in eVitabu's case) the identity provider as they check the identity of the user.  If the credentials are valid the identity provider gives the requesting system (eVitabu) a key that is only for use by the requesting system.  You can read more about OAuth on Wikipedia.

Can the system owner use the eVitabu OAuth key to read the user's email?

No.  When the user registers for eVitabu, which asks Google for an OAuth key, Google only grants the user with a key to be used for eVitabu.  That key couldn't be used to sign in to any other system, so even though the eVitabu administrators can see the keys (just a set of random letters and numbers) these are essentially useless to us (hence the concept of a valet key [4] in the diagram above).

Why Google?

At the moment, eVitabu is an Android only app and it's installed via the Google Play Store.  This is primarily because our target audience, pastors in Africa, have more Android devices than Apple ones - Apple smart devices are significantly more expensive than their Android counterparts.  If you're an Android user, getting apps from the Play Store, then you are guaranteed to have a Google account.  As a result, using Google as an identity provider seemed an obvious choice.

Another option was to use local accounts, created within the eVitabu system.  My coding partner and I rejected this option early on as it would mean we'd need to store passwords (albeit encrypted) and we'd suffer all the complications that go with that.  By not storing user passwords, in any form, we can't lose them in a data breach.  Given the problem of password reuse, discussed earlier, this is a distinct advantage.

It's worth considering that if a Google account is compromised then access to systems that use it to login becomes available.  For example, if you broke into the Google account I use to manage eVitabu you'd be able to "be me" in eVitabu too.  Google offers multi-factor authentication and eVitabu users benefit from that additional layer of protection if multi-factor authentication is enabled on their Google account.  It probably comes as no surprise that Google also monitors login attempts and flags suspicious logon activity - this is another benefit which eVitabu users gain that would otherwise take a lot of development time to build in our own systems.

Facebook, LinkedIn et al...

Google is not the only identity provider available that supports OAuth.  You may have seen "sign in with Facebook / LinkedIn / Microsoft" buttons on other sites.  Eventually this might be an avenue we explore for eVitabu, although it's not on the cards at the moment.

Do you keep the user's Google password?

No.  At no point does eVitabu receive the user's password - all of the user's credentials get passed directly to Google.  As mentioned earlier, we don't want to keep a copy of the password at all, as that way we can't lose it.

The only items that eVitabu keeps, that relate to the user's Google accounts, are their email address and the OAuth token Google provides following authentication.

Conclusion

By using OAuth we simplify things for the user.  There are fewer passwords for them to remember and their device can sign them straight into eVitabu once they've registered.  The added protections that Google provides in terms of login monitoring and multi-step authentication are a very handy added bonus.

Banner image: Our "sign in with Google" button

This post is dedicated to Rosa, one of our partners in Africa.  It was her good question on this topic that prompted this blog post.

[1] In practice, the system should only hold a copy of the hash of a users password.  When the user says "this is my password", the system performs some maths and if the hashes match then the correct password was used.

[2] I introduced my friend to LastPass, and now she's going round updating her passwords!

[3] Image from Wikipedia, https://commons.wikimedia.org/wiki/File:OpenIDvs.Pseudo-AuthenticationusingOAuth.svg

[4] Particularly found in cars, a valet key allows the door to be unlocked and the car to be started, but would not give access to the glove box, boot or storage compartments.