Protecting app secret for extendAccessToken usage

Question

I'm developing for Android and currently use facebook-android-sdk for authentication. From what I can see there is no use of the app secret in that code which is great.

Now that Facebook are going to remove the offline_access permission I need to extend the access token. Unfortunately the sdk's extendAccessToken method isn't stand alone and requires the official Facebook application to be installed which is unacceptable for me.

So I decided to implement extendAccessToken directly (similar to the iphone sdk implementation). The problem is the HTTP request for extending an access token requires the client_secret field which means I need to put the app secret in the code itself. This doesn't feel safe at all for an Android/Java application that can be reverse engineered easily.

Are there any alternatives?

Santosantonica

Your question interests me. Is the risk created by putting the client secret in the http request or is it created by having the client secret in your android.apk? – Deteriorate

You're right, it's included in the GET request so it is not possible to protect it without a 3rd party server. Makes me wonder why so many posts say you must not expose it if there are no ways to really protect it. As for my initial issue, it seems like oauth/access_token can't be used for Mobile/Desktop apps and auth.extendSSOAccessToken can't be used without SSO which on Android requires the official app anyway. Bottom line, Facebook must add proper extendAccessToken implementation to its Android SDK before removing the offline_access permission. Of course this won't happen. – Santosantonica

For completion, here is a feature request regarding extendAccessToken: developers.facebook.com/bugs/… A separate report should be added for the protection of client_secret. – Santosantonica

I have been asking a few questions about extending tokens but while some people have answered I haven't had any responses from android developers (despite 100 point bounties). I'm really quite surprised this isn't more of a issue in the Android developer community. – Deteriorate

Answer 1

Why not host the code for doing this on your own server, and have the client extend the token via a call to your server?

Crosshatch

The application is client side only, no server is involved. also assuming hypothetically I do add a server it would require sending the current token (which may still be valid) to me, so its a real security issue for users. – Santosantonica

Not if it's over HTTPS - it's certainly more secure than having your app secret in client-accessible code – Crosshatch

OK. Is there any other alternative? I really don't want to add a server. – Santosantonica

Don't the access tokens returned to the iOS SDK already have 60 day expiry? – Crosshatch

I'm using Android SDK and not iOS SDK. I'm trying to add the same functionality to the Android SDK myself as their current implementation isn't good enough. In iOS they use the endpoint of the old REST API (auth.extendSSOAccessToken) for extending tokens instead of using the new graph endpoint plus they can safely use the app secret in code because it's written in objective c which is much harder to decompile. Initial tokens returned by standard authentication will expire after a few hours if I understand it correctly. The app must extend it to 60 days on its own. – Santosantonica

Answer 2

So here's what I've discovered so far about Android/iOS sdks in regards to generating/extending tokens.

I've found 2 methods to generate the tokens client side with the SDK's and 3 methods to extend the tokens.

Generating:

1) Facebook app. Produces a SSO token

2) Web browser(iOS)/web dialog(Android/BB). Produces a SSO token on iOS and non-SSO token on Android/BB

These tokens are all long term tokens.

Extending:

1) iOS/Android app. In the Android case only if the user is signed into the app, otherwise the call to the bound service never returns anything, not even an error. Haven't tested iOS for that scenario.

2) auth.extendSSOAccessToken. This is the endpoint for the old API which, as far as I can tell, the iOS SDK still uses if the official app isn't present. Now if you use this endpoint on a token that wasn't generated with SSO (Android popup dialog) you get an error code 10 with a msg telling you the token wasn't generated with SSO. This might lead you to suspect that it could work as long as your token was generated via SSO. Your suspicion would be wrong, it gives you an error code 100 with a msg of "Access token for the Facebook application not supplied". This leaves this method completely useless on Android as far as I can tell.

3) oauth/access_token. This is the endpoint that FB tells us to use in their roadmap. Of course this method a) exposes your APP_SECRET (which FB strongly suggests not to) via apk decompilation/unpackaging and b) only works for extending short term tokens into long term tokens. So if you're starting off with a long term token, which is the default returned when on Android/iOS, you need to generate a short term token first and then extend it with this method client side (unsafe) or server side (not for everyone). How do you generate a short term token from a long term token? Wish I knew =(.

So far haven't been able find any ideas for accomplishing this anywhere. If anyone does know, Please Share!

This would at least give the people with servers a safe method for extending long term tokens.

Hargreaves