Facebook debug token without using any SDK, just a HTTP GET request - facebook

Instead of using any Facebook SDK, I'm using HTTP Requests.
Here is the URL I'm using to log the user into my application: (Not Real ID or URL)
https://www.facebook.com/dialog/oauth?
client_id=6545941f68498461
&redirect_uri=https://script.google.com/macros/s/hcz-IRoJhm/exec?
&response_type=token
&scope=publish_stream
The documentation is HERE. Official Facebook Login
After the user signs in with Facebook, my website loads with an access token appended to URL. I request a response_type=token so I get a token, not a code or both a code and a token.
According to the Facebook documentation, Confirming Identity
Because this redirect flow involves browsers being redirected to URLs
in your app from the Login dialog, traffic could directly access this
URL with made-up fragments or parameters. If your app assumed these
were valid parameters, the made-up data would be used by your app for
potentially malicious purposes. As a result, your app should confirm
that the person using the app is the same person that you have
response data for before generating an access token for them.
Confirming identity is accomplished in different ways depending on the
response_type received above:
And because I am receiving a token this quote from Facebook documentation should apply to me:
When token is received, it needs to be verified. You should make an
API call to an inspection endpoint that will indicate who the token
was generated for and by which app. You can do this from the client or
from the server, depending on your use case.
For this particular situation, there is a section titled, Inspecting Access Tokens:
Here is the quote from the Facebook documentation:
Whether or not your app uses code or token as your response_type from
the Login dialog, at this point it will have received an access token.
However, for the same security reasons as above, you should perform an
automated check to confirm that the token belongs the person that your
app is expecting it to belong to, and that it was your app that
generated the token.
We provide the following Graph API endpoint that can be used to inspect access tokens:
GET graph.facebook.com/debug_token?
input_token={token-to-inspect}
&access_token={app-token-or-admin-token}
So, I have parsed the access token from the end of the URL, and then made another GET Request from the server as configured in the example for the inspection, and I can not get it to work. I have tried using a generated app token and I have tried using my App ID plus my App Secret, and nothing works. I get an error message:
Execution failed: Invalid argument:
If I use the Facebook Debugger
And paste in the token that was returned from the login, it works fine. I get information back. So the token I'm getting back is valid.
I'm using the exact syntax for inspecting the Access Token, and I've checked every character many times for spelling or syntax errors. There must be something else causing the request to be rejected. For test purposes, I am sending the HTTP GET Request from a different URL, but because tokens are portable, Facebook allows requests from different places, for example, from a server.
Why is my request failing?
I'm wondering if there is something about the Apps Script UrlFetch service that is causing the error. The token I get back is valid. In the online debugger, the token is fine. I keep getting an invalid argument error. GET requests don't have a payload, so trying to use the payload, so trying to use that parameter wouldn't help me.
I muted the HTTPExceptions, and got a response back:
{"error":{"message":"Unsupported get request.","type":"GraphMethodException","code":100}}
In Facebooks Receiving Error Codes table, there is no code 100.
I set the "escaping" : false thinking maybe there might be a character that shouldn't be escaped that was being escaped, but that did nothing.
Maybe there is something in the URL that fetch doesn't like. Maybe I need to manually escape something.
Okay, I have figured something out. Google Apps Script UrlFetchApp.fetch(getAppTknURL, optnAppTkn); does not like the " | " character. If I use that character, I get a Execution failed: Invalid argument: error, which has nothing to do with the HTTP request.
So, using the App ID and App Secret as the access_token, divided by the " | " character will produce an error. And, the App Access token also uses that character to divide the app ID and the App Token. So maybe I can figure out what the escape characters are for that " | " character.

I found the problem. Facebook configures the App Token with a divider after the app ID.
AppID|AppToken
The " | " character is the divider. That character has an escape code of %7C. In my case, the | character needed to be escaped in the URL. As soon as I did that, I started getting responses back from Facebooks server.

Related

Http Security Token after login

I am using OkHttp to login to a website with username and password. After login any attempt to request a resource is followed with a token=xxxxxxaxx-xxax-xxxa-xxaa-axaxxaxaxxxx in the query path.
I am not certain this is a security token, or just a UUID? It follows the format 8-4-4-4-12 in length and is always lower case alphanumeric.
In order to send new requests to the service I need to acquire/generate token after login. In some cases I note in future requests that both the InstanceId=&token= is passed - where they both pass the same value for token and instanceid.
After login I do not see this token in the of the response headers, it just starts to appear in all future requests.
After login the following URLs are accessed:
portal
launch
htmlnavigator
getCSRFTokenVaue
getUserLocale
createToken
I have confirmed that the token returned by the createToken URL is not the same token that is used in later requests.
The various cookies sent by the server I can user with CookieManager, but where does the security token come from (or usually come from?) - What browser tools might help me beyond reading all the headers and responses.
It is a REST service, and each frame within the browser gets its own token, so difference requests in the same frame use the same token, open a new frame and that frame uses a new token.
The token is passed in the URI.
The web application UI has frames/pages within the main page and opening each new page generates a new token specific to that page
Multiple requests to each frame all send the same token so the tokens are not query authentication (like here)
If more information is required I will update the question but I can not name the system.
It may not be possible to know exactly what the url token is used for, but from what you say, different frames (tabs) in the same browser get different tokens, so it could be a frame specific session id (unusual but might be used to permit multiple sessions in systems where auth is stateless while preventing side-channel attacks) or more likely a form of double-submit CSRF token.

Can I use the access token directly from FB.login on my server?

I'd like to implement a Facebook authentication that does not perform traditional oauth redirects. It doesn't play nicely with my single-page-application and GraphQL API.
On the JS side, I can invoke FB.login to trigger a dialog for the user to login. If this is successful, I receive an object containing an accessToken and a signedRequest.
signedRequest can be decoded on the server and it spits out a code for me. I can use code with /oauth/access_token to get an accessToken.
However, I already had the accessToken this whole time from the FB.login response. So my question is: is there any point of me decoding the signed request, if I had the access token this whole time?
Bonus: Why does the FB API provide a signed request in the first place, and why does the oauth redirect by default forward the code and not an accessToken?
Yes, you can use the token you got from the client-side login, directly on the server.
It might however be a short-lived one, whereas the server-side login flow should give you a long-lived one right away. If you only need to perform API calls while the user is active on your page, the short-lived one will probably do. (And it could still be exchanged for a long-lived one with a server-side API call, https://developers.facebook.com/docs/facebook-login/access-tokens/refreshing)
Why does the FB API provide a signed request in the first place
It also contains a bit more info, that might be useful for a client-side app (user id, token expiry, externally passed in data in case of the old “Canvas” type apps), and might save on one additional API call to get that kind of info. https://developers.facebook.com/docs/reference/login/signed-request/
and why does the oauth redirect by default forward the code and not an accessToken?
General security measure. The token contained directly in the return URL, could easily be stolen by 3rd-party scripts that might be embedded on that page (ad servers etc. can get hacked from time to time, too), or leaked as part of the HTTP referrer.
The code parameter requires your app secret for the API call that exchanges it for a token, so if the code were to leak in any such way, whoever else got their hands on it, can’t do anything with it.

Why google-oauth API requires redirect-url?

I'm trying to set up an authorization flow with google-oauth2 API.
The task is to authorize users with google accounts in my web-application which consists of frontend and backend parts.
The flow according to the documentation consists of 2 steps:
1) obtaining an auth code
2) exchanging an auth code for a token
In my flow, FE client obtains an auth code from google and submits it to BE, which then exchanges it for a token, so no redirect URL (or sometimes called callback URL) is used.
I do not understand why google API requires me to provide redirect_uri for the second step? Since this step is performed by a server, not a browser, I don't see any sense in this piece of info. The server just calls the POST /oauth2/v4/token google endpoint and receives token in response.
see step 4 at https://developers.google.com/identity/protocols/OpenIDConnect
According to this, it's to guard against stealing the access_token. If a service doesn't check the initial redirect_uri, the authorization code is sent to the hacker's redirect_uri, which can then exchange it for an access_token, i.e. illegal access to the user's account. To actually get the access_token, the redirect_uri is specified again and this time must be checked by the server against the ones that are registered for that application. At that point, the hacker is foiled as the fake redirect_uri doesn't match any of the legal ones. Apparently some servers don't check the redirect_uri during the authorization stage and sending the redirect_uri again when requesting the access_token is meant to provide a final safey check.

"Developer Inactive" on Beats Music server-side auth token request

I'm working on a project and a new Beats Music API library for Clojure, but in my testing I'm finding it difficult to get write access authentication, but read-only user authentication works fine.
In testing my library I set up a HTML page to do the OAuth and get the OAuth code and then feed that code in to my library to fetch the actual authentication token. The first part works flawlessly, the second part has the dreaded "Developer Inactive" error:
URL: /oauth/token
PARAMS: client_secret, client_id, redirect_uri, code, grant_type=authorization_code
METHOD: post (application/x-www-form-urlencoded)
I've double checked my redirect_uri is the same as defined in my app settings and is the url of the HTML page I generated the code with. I even checked with the support folks to double check that my application wasn't throttled or something, but that took too long and I made a second application and had the exact same results. I've looked at other support questions like this and nothing has helped, so unless I'm missing something in my auth request, my only other thought was that my user account is still on it's 14-day trail and maybe that is affecting my auth token in some way?
Any ideas or suggestions would be greatly appreciated.
From https://developer.beatsmusic.com/docs/read/getting_started/Client_Side_Applications
"The scope of an access token using the implicit flow is limited to read only since client side applications cannot keep a secret. You'll need to request the authorization grant flow via the Web Server Authentication for write permissions, such as updating a playlist."
I hope this helps.
As #jsd pointed out in a comment on my question, there was a typo in the url endpoint. The correct endpoint is (which I had in the other function and that's why it was working correctly):
/oauth2/token

Logging into Facebook XMPP with encrypted access token format

Problem with my accessToken!!
accessToken is all right all the time.
It's standard format: AAA|BBB|CCC
I can get available current user's uid and session secret from a given accessToken( AAA|BBB|CCC)
BUT today fb server give me a strange accessToken unexpectedly.It's not useful for xmpplogin.
eg. AAACmERnbMSwBAB3XnOt4hnR71agtbo3CE8w2Xd7jD7QEURSiiOFV1Eg85tHsaHvVNobiUFppqzQcaXKjWOVSZCIFKvVsEJ4llZBfNI6AZDZD
could you give me a clue?I'm crazy to find answers whole day.
As per https://developers.facebook.com/blog/post/572/ the access token format changed recently to an encrypted format. All the APIs should work fine using this encrypted token including XMPP but it requires a minor code change to your XMPP code.
There was a blog post showing how to use the access token for XMPP auth on Sep 10.
Replace the session_key and sig parameters with the access_token parameter which should be the user access_token which has the xmpp_login permission - also note that it needs to be passed over SSL (which I believe was optional when you were only passing only the session key and sig)
If you can't get XMPP login working when you pass the encrypted access token, please file a bug in Facebook's bug tracker, but make sure you have the parameters changed per the note above and the chat docs.
The format of Facebook access token has changed recently. Now it is encrypted. At present if you want to get the user id of the owner of an access token issue a request in the following format
https://graph.facebook.com/me?fields=id&access_token='accesstoken'
This will return the Facebook User id of the owner of access token as a Json string. This request works even when the user is not logged in.