I am game programmer with limited web experience that was tasked to figure out how to make our game interact with Facebook. We are building a Unity Windows standalone app (maybe MacIntosh later), and our publisher wants us to enable the player to post in-game selfies to their wall in Facebook. That is all we need to do, we do not need to touch their friends list or anything else like that at all.

I have been digging to find out exactly how to do this, and the available advice online or prebuilt Facebook API Asset Store packages rely on the mobile API which we can't use. So, looks like we have to roll our own for the time being. I have been reading the developers.facebook.com section on Login Flow and it says that we should

  1. Request a login dialog for the player with our App ID
  2. Take the Access Token out of the response
  3. Then combine it with our App Secret to make API calls

Facebook also says that for security reasons, we should never embed the App Secret into the source of our client exe, so that hackers can't disassemble the exe and pull our secret out for them to use for their own purposes. That makes sense. Instead, they recommend that the App Secret remain on a server and that our client delegate API calls to that server. Seems like a smart way to do it.

However, we don't have a server, our publisher won't pay us to make a server or maintain the hardware, and even if they did, we don't have time to make one. So, what is the best practice for a client-only native Unity standalone app?

  • \$\begingroup\$ The other issue you may come across is the URI - FB requires the parameter passed as an arg to the Graph/Link/Feed share to be an actual URL, so you can't just pass a texture and byte encode it, you need to upload it somewhere and be able to pass the URI ... \$\endgroup\$ Feb 18, 2016 at 23:02
  • \$\begingroup\$ That's a good point to remember - I looked into that and it seems like I should be able to upload the photo using an API call (with something like a "nostory" flag to prevent feed spam) and then use the URI from that upload with the Graph/Link/Feed call ... of course, this all theoretical at this moment because I haven't gotten that far. \$\endgroup\$ Feb 18, 2016 at 23:07
  • \$\begingroup\$ Well, ultimately it turns out that what I need to do for my pedestrian use case doesn't require anything more than an access token. I have left the app secret out of the picture and don't miss it; but I imagine that someone else in a similar circumstance will need to do more than I did, so I'll leave the question up for them and my own curiosity for what the answer would've been. \$\endgroup\$ Feb 23, 2016 at 17:18
  • \$\begingroup\$ @MikeGonzales if you're still around this site, I'd recommend writing up your comment above as an answer. \$\endgroup\$
    – DMGregory
    Oct 31, 2018 at 12:31

1 Answer 1


I guess this is the closest thing to an answer for the question:


TL;DR: OAuth is not designed well for the non-web experience, and they have discussed ways to fix this (and Twitter & Yammer have their PIN method for this problem), but for right now, there is effectively no answer.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .