Are there security concerns with displaying an access token my OAuth 2.0 app has obtained? Maybe not necessarily display, but even echo it to a website's source code where it's essentially "findable" by the user. Assume everything is HTTPS.
Example: I have a website where I want to allow people to log in with Facebook. Once they log in, I get an FB API access token back from an identity provider or the Facebook PHP SDK. This token is tied to the user that just logged in. I want to make the user feel at home by displaying their profile picture, is it safe to render some HTML similar to the following?
<img src='https://graph.facebook.com/me/picture?access_token=USERS_ACCESS_TOKEN'>
Edit:
I know there are other options for displaying a profile picture, I'm not necessarily asking for a better way to do that. I'm more interested in the security that needs to be taken with these access tokens. Most of the resources I've seen don't seem to mention anything about it.
The access token should have a minimal set of permissions associated with it, i.e. just enough to actually display the users picture. In that case there's no increased risk wrt. XSS attacks since each solution to display the picture would involve the same risks in the case that an attacker manages to steal the session cookie and/or the token.
Only when the access token has additional permissions associated with it that are not used as a part of your front-end it would be a less preferred from a security standpoint to present it in the front-end.
Well, if the OAuth token is tied to the user session then there is nothing simpler for the attacker to steal users cookie (for instance by XSS) and use it together with the access token to make some actions on his FB on behalf of his account in your app. I would say rule of thumb in security related stuff is to disclose only the information you really have to and nothing else.
Ahh i see what you're doing. Instead of the oauth token do this: http://graph.facebook.com/1477079525902964/picture and ta-da
Related
I am the administrator of a Facebook Page. I am building a web app which, under certain circumstances, will post on Facebook as that Page.
With most APIs, I would just get an API key, and supply that when connecting to the API from my app. But Facebook expects an access token instead of an API key. (Specifically, in this case, it needs a "page access token".)
I am trying to figure out how to get a page access token that will be as permanent as possible.
After jumping through a bunch of esoteric, undocumented hoops (see here and here) in order to get a token that wouldn't expire, I had this working. When I ran the token through Facebook's Access Token Debugger, the "Expires" field read "Never". All was good in the world.
But, the next day, my token became invalid anyway. The Access Token Debugger, and my app's calls to Facebook's PHP SDK, both started returning this error:
Error validating access token: Session does not match current stored session. This may be because the user changed the password since the time the session was created or Facebook has changed the session for security reasons.
It seems that a token can become invalid for a variety of reasons (but this article is five years old, so who knows – Facebook changes things every two weeks). I had not changed my password. (I might have logged out of Facebook, though.) Facebook offers no specifics about why this particular token might have become invalid.
I've also seen a few references to a permission called offline_access, but Facebook seems to have removed this.
I suppose my question is twofold:
In general, I've found Facebook token authentication to be incredibly brittle when calling the Facebook API from the server. The token system seems to be designed mainly to allow other users to grant (or revoke) various kinds of account access to my apps. But that's not what I'm doing – I'm trying to get a token that will let me post to a page that I own. And for that scenario, Facebook's aggressive invalidation of tokens becomes a serious liability. I can't launch my app if my access token (and therefore my Facebook integration) could randomly stop working at any moment, requiring me to generate a new token and update the app. This seems absurd. Is there an alternative method of authenticating to Facebook for my purposes?
If a page access token is, in fact, the best way to authenticate my app to Facebook in order to post as my Page: how can I ensure that my token doesn't spontaneously become invalid?
I hate developing for Facebook :/ Thanks for any insight you can offer.
Extended Page Tokens are valid forever. They only get invalidated if you change your password or if you change the App Secret of your App. There´s really no magic in it, checking if the Token is still valid is obviously not a bad idea but that´s up to you. For example, you can send yourself an automated Email when there is an error using the Token, so you can refresh it. But it will really just happen if you change your password.
Links:
https://developers.facebook.com/docs/facebook-login/access-tokens
http://www.devils-heaven.com/facebook-access-tokens/
I have persisted to database some very important page access tokens to our application. Now we need to change the login site url. Will this have any impact on our page access tokens, will they still be valid? I need to know because we do not wish to involve our very important clients with this, since we are actually using these tokens and it will be very difficult for us to involve the clients to get new tokens right now.
Will this have any impact on our page access tokens, will they still be valid?
Yes, the token will still be valid.
The page access token will be invalidated if the user de-authorized your app/ changes password; it has nothing to do with the site url.
So I'm building my app around facebook oauth, and was hoping to use the fbsr_ token to identify logged-in users (so that the facebook-js stuff stays in sync with my site).
Unfortunately, it appears that these fbsr_* cookies are set to expire within a day. Which means if the user comes to my site a day later, they have no cookie and are shown a logged-out experience.
The facebook-js then runs, recognizes them, creates the fbsr_* cookie, and gives me a callback. I can choose to do a hard page refresh (rather jarring), or try to do fancy in-place ajax updating (tons of complex code, still slightly jarring). Is there a reason these cookies don't have a longer expiration so the user stays logged-in seamlessly? Most websites allow you to "remember me" when you log in to avoid constant cookie expirations, so I'd rather not have my facebook-enabled website keep logging me out.
Is there anything I can do about this? I suspect I can probably switch to serverside-oauth where I manage identity and cookie expiration myself (yes?). But it seems strange that clientside-oauth would have such a limitation, so I'm hoping I'm missing something.
Is there anything I can do about this?
No, not really.
The only way to determine, if a user is currently logged in to Facebook, is to look at the cookie set for the domain facebook.com.
The JS SDK is capable of doing that, because it runs client-side, and can make a cross-domain request to check if these cookies are set.
But there is no way to check for those cookies server-side from your domain – your server only has access to cookies set for your own domain.
I suspect I can probably switch to serverside-oauth where I manage identity and cookie expiration myself (yes?)
If your set your own cookies on your domain, you are implementing your own login system.
And even if you “fake” the cookies that the JS SDK sets under your domain, it would not bring the same results.
There might be a cookie on your domain, that says, “yes, user XYZ is logged in to Facebook” – but that would not have to be the case. I could have logged out of Facebook in the meantime, and your cookies would not reflect that at all. So whatever you’ll try to do next, like f.e. posting something on my behalf from your app, will most likely fail, because you only think I was still logged in to Facebook, but in reality you do not have a valid access token for me any more, since I am not really logged into Facebook.
The facebook-js then runs, recognizes them, creates the fbsr_* cookie, and gives me a callback. I can choose to do a hard page refresh (rather jarring), or try to do fancy in-place ajax updating (tons of complex code, still slightly jarring).
Those are your only viable options.
On my app the user can sign to Facebook and the app then has the user's access token (say it's 'abc'), I want to use this token to create a user on my own server.
Is it safe to send this access token to my server (using SSL), then get the user's username and ID using https://graph.facebook.com/me?access_token=abc on my server and check that the application the token belongs to is mine with https://graph.facebook.com/app?access_token=abc. If it is my application I then store the user in my user's database and/or log them in.
Can this system be fooled? Can you think of a way someone could log in as someone else?
You should check out all of the Authentication documentation and the Oauth spec to see the different auth flows available
Broadly speaking, you can create a user on your server based on the access token, and be reasonably certain that when you get an access token from Facebook for the same user ID that it's the same person.
If you require very high security for the app you can take steps to ensure the user's access token wasn't produced via malware or the Facebook user being tricked, there's an example showing protection against CSRF in the Server Side Authentication documentation, and there's also a reauthentication flow you can use
I assume that you are using facebook sdk for this, if so the facebook sdk takes care of the security for you and you don't have to worry about a thing.Supposing that you are accessing the api without the sdk then there are two things that must be noted:
1) Auth token expires frequently(facebook has taken great pains to ensure that the user is protected)
2)Making a request with just auth token is not enough there are some other parameters that are needed that can't be faked especially if you are doing this server side since an extra layer is added that fb calls server flow authentication
3)On top of that there are a lot of permissions that are in place that the user has to give in order for an application to access some data.The link below provides a nice article on authentication you can take a look
https://developers.facebook.com/docs/authentication/
So long story short it is safe.
My scenario is somewhat like this: A user logs into my website with his FB credentials. I capture his ID and the FB access token (say, a long-lived access token). He exits my website, and returns back later. However, this time, his browser has FB open with a different ID. Would I be able to load facebook details of this old id (with which he had registered on my site) using the stored access tokens? Is it possible, or would it result in a clash between the old and the existing FB id?
Correct me if I'm wrong, but he/she should stay logged into your website, regaurdless if his authID changes.
First of all, why would you want to do that? Since Facebook does not allow multiple user accounts for one and the same person, the only case where this would normally come into play is when another user is using my computer/browser – and why would I want you to read my info while that other person is using my device …?
Second of all, as long as the first user is still considered logged in to your site, it makes not much difference. But lets say some client-side method is called that updates the cookie information, then that’s where trouble might start. You might still be able to read the old user’s info, since you have his valid access token – but you’d have to use that token in your requests explicitly, and also address the account specifically, since the Graph API’s /me would point to the new user.
But as I said, I can hardly imagine a real, practical use case here …