Securely Storing Facebook / OAuth Access Tokens

March 31, 2011

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.

Share Button

18 Responses to “Securely Storing Facebook / OAuth Access Tokens”

  1. Thank you for the post. This was useful.

  2. 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.)

  3. 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.

  4. Thanks for your post, it really helps.

  5. Thanks so much for this post. I have been researching this exact topic with no clear answer until now.

  6. Script kiddies eh… what are you like? You are barely out of pubity so what would you know about security?

    You would never need this additional layer to protect what is essentially a proven system [OAuth] that protects the user identity.

    The issue you are talking about is a breach of a server / database and in any case (as you point out yourself) having this additional burden [encryption] would be mute if such a breach happened.

    Ignore this pointless post folks as this boy ain’t got a -beep- clue. Like I said, “Script kiddies eh?”.

  7. 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.

  8. 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.

  9. Is this storing the access token is still in scope. What i am seeing for every session, access token keeps changed. Any suggested would be much appericated.

  10. 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.

    Any tips or advice would be greatly appreciated. Appreciate it

  11. Hi there, its nice post regarding media print, we all understand media is a great source of information.

    Here is my web-site – allister garage door opener

  12. You could certainly see your expertise within the article you write.

    The world hopes for more passionate writers such as you who are not afraid to say how they believe.

    All the time follow your heart.

  13. 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.

  14. It’s an amazing post for all the online people; they will
    obtain benefit from it I am sure.

  15. Thiss excellent website definitely has all the information and facts I needed about this subject and didn’t know whho to ask.

    Also visit my weeb page hort uurl (Warren)

  16. It’s awesome designed for me to have a site, which is good in favor of my
    know-how. thanks admin

  17. Piece of wrіting writing iѕ also a fսn, if you know afterward you can write ߋtҺerwisᥱ it
    is complicated to write.

  18. 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!

Leave a Reply