What about auth tokens? OAuth and security

A friend asked me, after the last book review, what is my point of view on authentication tokens like OAuth gives out. In particular, it seems like lots of services nowadays allows you to login via either Facebook or Google+ without requesting explicit authorization to post for you or inspect your profile. Why should we trust them at all?

The answer is to be found in a different post of mine from a few months ago, about blogs and passwords. In that post, I was complaining about blogs and websites that require you to register even to read the content. The reason is that if you’re not careful, you risk exposing your usual passwords to what is most likely an even less secure storage than, well, Target. But I don’t want to go back to discussing the false impression of security that self-hosting gives you in this post.

If instead of requiring me to register with a new password, a website allows me to login with either Facebook, Google+ or Twitter, I have fewer doubts — while some privacy advocates will complain that this ties you with a single identity, well, I don’t care and I’d rather not have a malicious actor figuring out my password.

The first important part to understand is that while I know some people are skeptic about it, if properly implemented, OAuth 2 allows fine-grained control on what the apps that link to it have access to — this means that if you’re only trying to get a hold of a registration identity, the basic profile information (name and email address) is all you need. Of course you have to trust that the implementation on Google’s, Facebook’s and Twitter’s side is correct, but I’d rather trust that than trust some self-hosted system somewhere.

Of course it’s still possible for an attacker to get a hold of the tokens used for authentication, which gives them access to your personal information in that case — but that means very little, given that the same would have happened if the attacker got a hold of the registration data. Since the service itself would then not have my password at all, if compromised there will be at least one datum less.

There is one more interesting feature of OAuth2 that helps you in this respect: the specifications make it clear that you should never provide an unlimited-time token; instead you should provide a “refresh” token that the service can use to re-authenticate the user when the actual authentication token expires. This is a good thing: as long as you’re using the service, the token will be refreshed, but if you stop visiting the service for months, well, you don’t have to remember that it had your authorization a while back.

Yes of course there are still plenty of corner cases and situations where OAuth2 does not stop an attacker getting persistent access to a service and using said access to access your data — this is especially bad if the service has access to, say, your whole email history or your contacts’ list. But this was true before as well, so the only solution is to ensure that the OAuth2 providers have the right limited accesses, and security features such as 2FA.

So if I ever decide to work on replacing my stupid blog software I would probably use OAuth2 for authentication, against my Google account, and allow user comments through the same integration — but still allow anonymous comments, I think that works very well already. Who knows, maybe I can remake Typo into Refuso, and a nerdy, self-hosted, secure hosting platform… even though I don’t like self-hosting in general.