Thou Shalt Not Use OAuth

TL;DR: Do not use OAuth to “Sign in with…” without a second factor.

OAuth is the mechanism with which a third party (a “client” or “App”) can be delegated a level of authority on an account (the “first party”, most commonly you) with an OAuth provider (the “second party”). This usually includes allowing an app access to some of your user information, and sometimes, to post on your behalf.

With a web application that uses OAuth to authenticate the user with the help of a third party, i.e. OAuth, you — that is, the user being authenticated — have to take the following in to account;

  1. The third party is the party that controls the authentication and authorization process for the user,
  2. The third party issues the second party, that application you are authenticating against, with the necessary tokens, both the public and the private one,
  3. The third party sends the second party the yay or nay on the authentication and authorization for the user accounts.

As such, it is an exploit path. Not an attack surface, not an attack vector, but right-out an exploit path.

Provided the kind of knowledge stored with a third party, and their ability to just fake it, there’s literally no way to stop those third parties from abusing that power and gain access to the second party account you have just been “authorized” to use.

I’ll back up for a second, because it isn’t all that bad — it’s bad, just not that bad. The title of this blog post could therefore be considered misleading, because “Thou Shalt Not Use OAuth … to sign in with third party websites without a second factor” would have been more accurate. Also, by no means is the website itself absolved from all responsibility, but there’s billions of them and only one of you — so it’s easier to start with you.

Like I said, OAuth is supposed to give third party applications a level of access to the information you have given the OAuth provider and/or permission to act, with the OAuth provider, on your behalf. This includes, for example, this blog post getting spread via Twitter, Facebook and Google+. It is I who has authorized and authorizes WordPress to post such messages — on my behalf — and for this WordPress uses OAuth and becomes an “app” in my respective accounts. So far, so good.

The real problem is “Sign in with…” functionality on websites. It lowers the barrier for a website significantly, allowing a visitor to sign in with an existing identity, and thus without that visitor needing to go though a separate registration process. In that, it is genius. However, it is also a sole authentication factor originating and ending with a single source. Not so bad when you want to comment on a blog post, but very bad if your level of privileges on the website using OAuth includes entitlements to services and information.

To further illustrate, your OAuth providers (Facebook, Google, Twitter, Dropbox, Github, Weibo, Douban, QQ, Linkedin) can already act on your behalf if a website only requires you to “prove” your identity using OAuth. For such places where the level of privileges directly associated with is very, very limited — like leaving a comment on a blog post perhaps — this isn’t too bad. But as a login to a password vault, you can see it’s very, very bad.

In short, we are considering adding OAuth-based authentication to Kolab Now, in a new software development project you’ll hear about more later. One intention is to lower the barrier for sign-up as far as we reasonably can. We’re working under an assumption that everyone has a Twitter, Facebook, Google, Github, Linkedin, Weibo, QQ, Dropbox or Douban account they could sign in with initially, and get to exploring products and services. An in case you do not, don’t worry. A more traditional email address / username and password sign-up should also be available, as would an SMS-based solution we have yet to design.

It is now clear (to us) that no further privileges or entitlements can be assigned to an account that authenticates solely using a third party OAuth provider. We will either require a second factor authentication token and suggest you switch your login account to the first product or service you purchase or subscribe to when you log in.

I hope it is also clear (to you) what exactly could be the results of using “Sign in with…” on websites, when used without a second factor.

PS: The fallacy of using one-time passwords are to be addressed later.

Advertisements

One thought on “Thou Shalt Not Use OAuth

Comments are closed.