What advantage does facebook's new encrypted access_token have?

Question

When a user on facebook grants an app access to their account, an API key is issued to the app. This key is app and user-specific. This process is described in Facebook's developer documentation.

Until recently, API keys could be parsed- they contained the app's numeric ID, the user's ID, and other information (timestamps, validity, etc) encoded and used by Facebook to track the app and grant/revoke permissions.

As described in Facebook's documentation, https://developers.facebook.com/docs/oauth2-https-migration/, the access tokens given to apps are now encrypted. What does Facebook accomplish by encrypting the access token? Other than the fact that you can no longer tell by looking at it what user and app it belongs to, nothing is changed from what I can tell. If the token is stolen, it can still be used, encrypted or not, to access the user's account.

Answer 1

Disclaimer: I am writing this based only on what you write and my own guesswork.

Last I saw something about "encrypted tokens", it was about server load. When an app uses such a token, the token must be verified against what can be described as a big database of all existing valid tokens. Possibly, some people could have begun to try "random tokens" just in case it works (cost of trying a random token is about 0 for an amateur who will just try out a dozen or so, but the perceived potential gain is high). Risks of hitting a valid token are negligible (if the token includes enough secret random bits) but each such token must still be validated against the Big Database, and given the size of Facebook's user base, one can surmise that this implies a tremendous extra load on that database.

A way to reduce such load is to use a MAC: a keyed integrity check. Facebook's servers would first verify the MAC (with the secret key used to generated the MAC in the first place) and only tokens with a proper MAC would be forwarded to the database for the more expensive verification.

There are several methods to make a keyed integrity check; one of them is to add some "redundancy" in the token structure (e.g. a field consisting in a sequence of zeros) and then encrypting the whole with a pseudo-random permutation (a block cipher, using the whole token as a single "block"). To verify, the token is decrypted and the presence of the redundancy is verified. There is ample room for doing it wrong (e.g. if the token is longer than a cipher block, and an inadequate chaining mode is used) but it is still a possibility.

Therefore, without any other information, I find it possible that the "encrypted token" could be a keyed integrity check in disguise, meant to reduce server load.

Answer 2

I hope you don't take this as a glib answer, but I think you have already stated most of my answer in your question.

1. The token is encrypted so if it is sniffed or read by someone that is not authorized none of the information is exposed. This could make an attackers job slightly more difficult.

2. By encrypting the token they can put data in the token that they don't want the website that uses the token to see. For example they could be a field such as "make_api_requests_really_really_slow=true" and anyone that has that token will suddenly find that facebook is really slow for them. Or possibly they want to roll out and test new features and they don't want to reveal them to anyone.

3. Encrypting the token with AES is much cheaper computationally (esp. given the AES instruction set in new intel chips) than digitally signing the token to prevent users from altering them. This is speculation, I have no idea what cipher they are using.