I've searched a lot and I've read a lot about this thing, but all the solutions were to get the access token by copy it manually.
is there a way to get the access token automatically by an API request?
It is possible. First of all, you have to integrate the facebook login to generate a user access token.
Look here to get started with the facebook login
The problem with this token is, it expires really fast:
Default User and Page access tokens are short-lived, expiring in hours, however, you can exchange a short-lived token for a long-lived token.
However you can use this to generate a long lives access token which expires normally in 60 days. Additionally it will get refreshed when the user uses your app within this 60 days.
This is the URL to generate the Long-Lives Access Token. You have to enter your app-id, app-secret and access-token. All three can be found inside the app you created on the facebook developer page.
"https://graph.facebook.com/{graph-api-version}/oauth/access_token?
grant_type=fb_exchange_token&
client_id={app-id}&
client_secret={app-secret}&
fb_exchange_token={your-access-token}"
Offical documentation to generate a Long-Lives Access Tokens
Hint: You can test all commands through your browser. Just replace the placeholders in the url with your data and put them into the URL-bar. Then you will get an JSON-response from the facebook graph API.
Related
I have an application to save Azure Active Directory users to SQL Server. For this I am using MSAL authentication to get the users.
But sometimes my access token will get expired and I will get 401 unauthorized error from Graph. So I need to add the logic of validating the expiry in my code itself. I searched a lot but couldn't find a good solution.
Could anybody help me how to achieve this?
The default lifetime of an access token is variable. When issued, an access token's default lifetime is assigned a random value ranging between 60-90 minutes (75 minutes on average). I suggest you save the Refresh token instead and then obtain the access token any time you want to query the users resource.
The reason for that is that the Refresh tokens have a longer lifetime than access tokens. The default lifetime for the tokens is 90 days and they replace themselves with a fresh token upon every use. As such, whenever a refresh token is used to acquire a new access token, a new refresh token is also issued. The Microsoft identity platform doesn't revoke old refresh tokens when used to fetch new access tokens. Securely delete the old refresh token after acquiring a new one. Refresh tokens need to be stored safely like access tokens or application credentials.
More about Refresh token in Microsoft identity platform can be found here - https://learn.microsoft.com/en-us/azure/active-directory/develop/refresh-tokens
I am making an API call that requires OAuth2. I initially make the call and authorize it with a login via the web. I'm then taking the supplied Refresh Token and using it to make subsequent calls in my application.
The issue is that in the subsequent calls the Refresh Token is used up and I get a new one. I save this new one in the database and then use that saved one on the next call. This works great for about xx number of calls and then for some reason the Refresh Token goes bad and I have to go and manually grab one through the web login again.
I have no way to tell, that I know of, when the token goes bad or why.
Is there a way to just send the login info or the OAuth2 info or something that'll get me a new valid Refresh Token without me having to "authorize" my own app?
The API that I am using is Constant Contact.
The OAuth standards are based on 2 forms of expiry:
ACCESS TOKENS
These are short lived API credentials and a common lifetime is 60 minutes. When they expire the API client receives an HTTP response with a 401 status code. The client can then try to silently renew the access token.
REFRESH TOKENS
These are long lived credentials that represent a user session, and a common lifetime is 8 or 12 hours. During this time the access token can be renewed silently. Eventually however, the refresh token itself expires and the silent renewal request results in an error with an invalid_grant error code.
USER RE-AUTHENTICATION
There are very good reasons for making users re-authenticate and I would avoid trying to bypass this. Tokens that last for a very long time are not recommended. Usability can be pretty good with only an occasional re-authenticate operation, along with features such as password autofill.
FURTHER DETAILS
See steps 26 and 29 of my Message Workflow
Code that handles 401 checks
Code that handles ErrorCodes.invalidGrant
I have created an app in facebook and I have AppID and AppSecret keys. Now I want to get the authentication token for that app. I can use the graph api tool provided by facebook to get the token but I want to get the token programmatically using facebook api. Also I want to get the token without logging in to the facebook account actually. Is there any way to get it
programmatically using facebook api?
As far as know, you can't get it without actually logging to Facebook.
You can't generate a long-lived access token without going through Facebook's OAuth process (the Graph Explorer tool token expires after two hours).
The OAuth process can be automated to an extent, but there is one part that requires the user to click a button to authorize your application to access their Facebook account. Facebook OAuth is therefore a two step process:
Show the authorization URL and get the user to click 'allow'
Retrieve the access token once the user has clicked 'allow'
The Temboo SDK breaks the Facebook OAuth process down in to two steps - InitializeOAuth and FinalizeOAuth - that you can use in your app. These steps map to the process I outlined above. You can learn more about how to handle Facebook OAuth via Temboo here. To see this behavior in action you can check out a live example (with source code available) on the Temboo examples page.
(Full disclosure: I work at Temboo)
NO, you can't have long lived access token without login in Facebook, because for long lived access token you need to have short lived access token which you will be needed in below Facebook graph API:
STEPS FOR LASTING PAGE ACCESS TOKEN
1- You have to get page access token for a user by this API:
https://graph.facebook.com/{User-id}/accounts?access_token={access-token}
2- Then u have to refresh the save token by below API which will last for 60 days:
https://graph.facebook.com/oauth/access_token?client_id={your-client-id}&client_secret={client-secret}&grant_type=fb_exchange_token&fb_exchange_token={previous-access-token}
We have an audio blogging website which can be configured to publish links to the user's Facebook timeline whenever they make a new blog entry.
To do this, we have the user authorise our app when they set up the link to their Facebook account. We obtain the publish_stream, offline_access and manage_pages permissions (more on that later).
All the code is in C# but the principles apply to any language as it's the workings of the Facebook API we are concerned with. We're using OAuth 2 and the Graph API to achieve all of this.
So, we obtain an app access token using our app ID and secret and use that token to publish to the user's timeline, this works fine (because they have already authorised our app to do this). We can also query the Graph API and get their likes, friends and various other data.
NOW HERE IS THE PROBLEM:
Some of our users want to publish updates to their own timelime and also to the timelines of pages that they manage. In theory this is simple: you query the API for the pages that the user manages using this url: https://graph.facebook.com/{userid}/accounts?access_token={token}
The JSON returned from this call is said to contain the page IDs and the page access tokens for those pages. You then use the page access token to publish to the pages' timelines.
However, when we try to call this URL with the app access token we are getting an OAuthException 102 "A user access token is required to request this resource".
Note this is different to OAuthException 104 "An access token is required to request this resource" (which is what you'd get if you neglected to pass an access token), and also OAuthException 190 "Invalid OAuth access token signature" (which you would get if the access token was not a valid one).
So our access token is valid, but just not valid for this particular url. It seems therefore that we need a user access token and not an app access token for this particular feed (I am long past caring why this is the case, it just seems to be the way it is).
All the Facebook documentation on this subject (and I must have read all of it by now) leads to one place: http://developers.facebook.com/docs/authentication/server-side/, aka the "Server-Side Authentication Flow" page. This page describes how to get the elusive user access token by redirecting the user to the auth dialog and asking for the relevant permissions but we need to achieve this without interaction from the user and the user has already given our app all the permissions we need. All of this automated publishing happens server side in the post-processing of the audio so we cannot interact with the user at this stage anyway.
I don't get it. Why is it we can use the app access token to get almost any data we want from the user (well, whatever they have given us permission to get) but the /accounts data we need a different (user) access token for?
Can anyone shed any light on how we can get a user access token which will allow us to get the /accounts data for our users without any further interaction from the user?
So our access token is valid, but just not valid for this particular url. It seems therefore that we need a user access token and not an app access token for this particular feed
Due to the permissions per type of access token, you do need a valid user access token in this particular case. Read all about access tokens and types. That's just the way it is.
This page describes how to get the elusive user access token by redirecting the user to the auth dialog and asking for the relevant permissions but we need to achieve this without interaction from the user and the user has already given our app all the permissions we need.
If your user already has given his/her permissions, why are you struggling then? I suggest you persist the user access token. From this endpoint:
https://www.facebook.com/dialog/oauth?client_id=..&redirect_uri=..&state=..&scope=..&response_type=..&display=.."
you retrieve a code, like this:
YOUR_REDIRECT_URI?code=OAUTH_CODE_GENERATED_BY_FACEBOOK&state=YOUR_STATE_VALUE
Use this code to generate your user access token, as explained here:
https://graph.facebook.com/oauth/access_token?client_id=..&redirect_uri=..&client_secret=..&code=..
This will result in a response like:
access_token=USER_ACCESS_TOKEN&expires=NUMBER_OF_SECONDS_UNTIL_TOKEN_EXPIRES
There it is, your user access token. Persist it. As you can see it expires after the value indicated in the response. If you are using the new API, it should indicate 60 days (that brings me back to this: offline_access is deprecated and results in short-lived - valid for 2 hours - tokens), link. Whenever your user logs in to your app and uses the Facebook integration, the tokens gets refreshed to again, 60 days. This means, that IF your user should not login to your app and use it for 60 days, it will expire.
You can check whether the user access token is expired with:
https://graph.facebook.com/debug_token?input_token=INPUT_TOKEN&access_token=ACCESS_TOKEN
If that does: renew the user access token by using your app access token, it is well documented right over here. But I'm quoting this part:
Server-side Login
To obtain a fresh [user] access token in this case you must pass the user through the full server-side Login flow again. However, assuming the user has not de-authorized your app, when you redirect the user to the OAuth Dialog, they will not be prompted to reauthorize your app, and will be immediately redirected to the redirect_uri. This means that the re-authentication process can appear reasonably transparent to the user.
Bottom-line: there are no user access tokens that are valid for ever, the app access token however is. Persist your user access token and check whether it is still valid before performing API calls with it. A normal user should use your app within 60 days and should not just de-authorize your app for fun. Hence the use case in which the user should re-authorize is fairly rare, however, you need to expect it.
I am totally lost finding the right API to create a sign up process like Foursquare. I am attaching a document of what I am trying to do. I have already tried OAuth, JavascriptSDK, Facebook.NET API from Codeplex and FacebookToolkit.NET from Microsoft. Nothing looks what I actually need. I think some one experienced can lean me towards where I should go straight.
https://docs.google.com/fileview?id=0B6mlBkccI34zNDNmMGMyNTYtMDY2NS00NmEwLTlkMjQtZjA5NmVmZDMzYzlj&hl=en&authkey=CNPH9LEL
Note: I am trying to achieve this via ASP.NET with C#.
Facebook Graph Api is the best.The url is http://developers.facebook.com/docs/api
The Graph API uses OAuth 2.0 for authorization. Check out the authentication guide for the details of Facebook's OAuth 2.0 implementation.
OAuth 2.0 is a simpler version of OAuth that leverages SSL for API communication instead of relying on complex URL signature schemes and token exchanges. At a high level, using OAuth 2.0 entails getting an access token for a Facebook user via a redirect to Facebook. After you obtain the access token for a user, you can perform authorized requests on behalf of that user by including the access token in your Graph API requests:
https://graph.facebook.com/220439?access_token=...
Check out the PHP example code or the Python example code on GitHub to see a complete example of obtaining an access token for the current user. The steps to obtain an access token are:
Register your application to get an app ID and secret. Your Facebook app ID is your client_id and your Facebook application secret is your client_secret.
Redirect the user to https://graph.facebook.com/oauth/authorize with your client_id and the redirect_uri. The redirect_uri parameter needs to begin with your app's URL. For instance, if your URL is http://www.example.com then your redirect URI could be http://www.example.com/oauth_redirect.
https://graph.facebook.com/oauth/authorize?
client_id=...&
redirect_uri=http://www.example.com/oauth_redirect
After the user authorizes your application, we redirect the user back to the redirect URI you specified with a verification string in the argument code, which can be exchanged for an oauth access token. Exchange it for an access token by fetching https://graph.facebook.com/oauth/access_token. Pass the exact same redirect_uri as in the previous step:
https://graph.facebook.com/oauth/access_token?
client_id=...&
redirect_uri=http://www.example.com/oauth_redirect&
client_secret=...&
code=...
Use the access token returned by the request above to make requests on behalf of the user:
https://graph.facebook.com/me?access_token=...
You are looking for the Facebook Connect API.
More info for the single login process can be found here
You could also leverage OpenID
Your document notes the Yelp signup process, which is very low friction and allows the user's information to be available to the website without having to go through Facebook's authentication process.
Yelp, Microsoft Docs, and Pandora are using a feature of Facebook called Instant Personalization. Instant Personalization is not available to developers as of yet and is only available to those three partners.
That being said, you likely would need to use the Facebook Login Button to allow the user to grant you access to their information (including their friends list).
As far as the process of getting a list of friends, use the graph call "me/friends"
I manage FaceSharp, a .NET open source project to help people get started with Facebook Development and will be adding functionality similar to what you are looking to do in the future, perhaps some of that code will help you in your efforts. It's under the MIT license, so take whatever you want.