Developer tips

Securely Storing Facebook / OAuth Access Tokens

Facebook and all OAuth applications (facebook is sort-of OAuth) provide access tokens for applications to do things on behalf of users. I’ll not go into details of how to obtain them and how to use them, but in most cases you would want an eternal token – i.e. one that can be used for offline access. OAuth 2 defines a way to obtain new tokens by passing an expired token, but facebook does not support that, and it is mostly the same as an eternal token.

So you have to store the token in the database (for web applications, that is) so that you can use it the next time the user comes without asking him to authenticate again and again. But if an attacker gets hold of your database, then he can do whatever he likes on behalf of all your users. And that’s something you don’t want.

So you must store them securely. Each guide tells you that, but they don’t make it clear how. What are the options when the “security” is mentioned:

store a hash – not feasible in this case, because you must be able to obtain the original token

encrypt with an asymmetric algorithm (RSA) – not needed – both encryption and decryption is done by the application

encrypt with a symmetric algorithm (3DES, AES) – this seems to be the best option. Prefer AES.

So, you now have the access token encrypted and stored in the database. Each time you need it, you decrypt it, and use it? No – decrypt it and store it in the user session (and transient, so that it does not get persisted if the session is)

So where do you store your AES key? Somewhere in your application. Is that completely secure? No, because if an attacker gets access to your system, he will be able to get the key and decrypt the database values. But it is still better than storing them in plaintext in the database.

The thing is, you can’t actually make it more secure. You can go through another X layers of key/password storage systems each of which gives you a key/password based on another key/password, but once an attacker gets to your system, all of that is “security through obscurity”. It’s because your application must be able to obtain the access token somehow. And if an attacker owns your application, then he can obtain the tokens as well.

So what you should do is – report breaches into the system, so in case an attacker gets access to your system (not only the database, but the application/file system), you can disable your facebook/twitter applications, or invalidate the tokens (if the service allows it), so that no harm is done.

18 thoughts on “Securely Storing Facebook / OAuth Access Tokens”

i am a beginner, so i may be wrong, but only access token is of no use. its of use with your application key and secret and your website domain (assuming attacker can’t access ur facebook or twitter account and change website url.)

The access token seems to be sufficient. Check for example the facebook Graph API page: http://developers.facebook.com/docs/reference/api/ Obtaining the token is what requires app credentials. Perhaps facebook are doing it wrong – twitter indeed requires the API key as well. But the API key is also obtainable, so the extra security isn’t redundant.

I might as well delete your comment, because it is an obvious trolling, but I won’t.

First, I don’t see how my age (25 btw) has any relation to what I know about security, and the current problem.

And having your tokens in plaintext means the attacker can immediately post spam via the affected users. And this has happened many times on twitter and facebook. On the other hand, if you encrypt yout database, the attacker might not be prepared and you will have an additional period of time to invalidate all your tokens. It’s not a perfect solution, but it is better than plaintext.

What about doing it the way that Apache does it in the case of startup requiring a password-protected private key? The app prompts the user for the password upon each startup. You could do something similar like requiring a hand-typed password from the administrator upon startup. The obvious drawback would be that unattended startup is impossible, but you would then get around having to store the decryption key in your application.

I know this if off topic but I’m looking into starting my own weblog and was
wondering what all is needed to get set up? I’m assuming having
a blog like yours would cost a pretty penny? I’m not very web smart so I’m not 100% sure.

I loved as much as you will receive carried out right here.
The sketch is tasteful, your authored subject matter
stylish. nonetheless, you command get bought an nervousness over that you wish be delivering
the following. unwell unquestionably come further formerly again since exactly the
same nearly very often inside case you shield this hike.

I do not eѵen understand how I ended up here, however I thought thiѕ put up was great.
I don’t understand who yоu’re hoԝever certainlү you’гe going to a weⅼl-known blogger in the eᴠent yoᥙ
aren’t already. Cheers!