I am reading facebook api and ran into a little confusion, and hope that you might help. I am using the Javascript SDK specifically, and on getting the request.session back from the login callback, I wonder if the field 'sig' is the same as the 'auth_token'? I know the descriptions of both are different, but I wonder if they are the same in reality. If anyone knows, I will be much appreciated. Thanks in advance.
auth_token is a token that Facebook generates for desktop applications that you must send back to Facebook again immediately when logging in.
sig on the other hand is a md5 hash of all session data combined with your application's private key. You can reconstruct the sig from the session data and compare it with the sig passed in, and if it matches the response can be considered authentic.
Consider the following keys stored as a cookie:
a=1
b=2
sig=8a80b0b971da5be75e7197576331b24e
Assume the application's private key is "hello". We can try to reconstruct the sig as:
md5("a=1" + "b=1" + "hello"); // 8a80b0b971da5be75e7197576331b24e
which equals the value of sig in this case. We constructed this by concatenating all key=value pairs in alphabetical order by key ("a" comes before "b"), then concatenate the private key and finally get the md5 of the resulting string.
I wrote a blog post for verifying the cookie set by Facebook in Rails (PHP example is already given on Facebook's website).
Related
I'm in context of managing an openId jws, and I'm not sure about how to verify the aud claim.
In details, suppose that I've an application id myapp.site.com and I receive an aud which value is myapp.site.com|*|ANY. I've not found specifications about this format, but reading the aud specification into https://openid.net/specs/openid-connect-core-1_0.html#IDToken I've supposed to explode the string myapp.site.com|*|ANY using the "pipe" as separator, and then verify if this array contains the aspected client id (ie myapp.site.com).
My question is: whatabout the * and ANY? there's some specifications about this format? where can I retrieve informations?
Thanks in advance,
Sim.
That looks like a custom thing that is not a standard that I have seen anywhere else, so I guess its up to you to parse it as it is. At the same time the purpose of the audience is for the receiver of a token to be sure the token is aimed for it and not someone else. So its a security risk to accept any token even if the signature is valid.
I am attempting to preview a track via the 7digital api. I have utilised the reference app to test the endpoint here:-
http://7digital.github.io/oauth-reference-page/
I have specified what I consider to be the correct format query, as in:-
http://previews.7digital.com/clip/8514023?oauth_consumer_key=MY_KEY&country=gb&oauth_nonce=221946762&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1456932878&oauth_version=1.0&oauth_signature=c5GBrJvxPIf2Kci24pq1qD31U%2Bs%3D
and yet, regardless of what parameters I enter I always get an invalid signature as a response. I have also incorporated this into my javascript code using the same oauth signature library as the reference page and yet still get the same invalid signature returned.
Could someone please shed some light on what I may be doing incorrectly?
Thanks.
I was able to sign it using:
url = http://previews.7digital.com/clip/8514023
valid consumer key & consumer secret
field 'country' = 'GB'
Your query strings parameters look a bit out of order. For OAuth the base string, used to sign, is meant to be in alphabetical order, so country would be first in this case. Once generated it doesn't matter the order in the final request, but the above tool applies them back in the same order (so country is first).
Can you make sure there aren't any spaces around your key/secret? It doesn't appear to strip white space.
If you have more specific problems it may be best to get in touch with 7digital directly - https://groups.google.com/forum/#!forum/7digital-api
Are mojolicious session tokens created in a "standard" way (in a generic sense), or is this up to the individual application? If it is the former, then what is the format?
What I saw so far is a base64 encoded JSON fragment (which by itself is syntactically incomplete), followed by "---", followed by a random looking 40-digit hex-string.
I'm especially interested in the random looking token. Is it randomly generated, or is it the encoding/encryption of something?
Mojolicious session have base64 string (in the begin, first part) and sign (in the end, second part) which separated by "---".
Sign is main part of session which prevent from changes.
So, make a test:
Add to session some value. Make request which get this value in the session.
Get session and transform first part of them (make base64_decode and change value then make base64_encode and put it before "--" in cookies).
Make query to server with new cookie/session. Your new data must be invalid in session.
So, sign it is IMPORTANT part of session.
Read source code to learn more about it
Read this to know how to set secret key for sign cookies
I'm using Jon Crosby's open source Objective-C OAuth library http://code.google.com/p/oauthconsumer/ for some basic http authentication that does not deal with tokens, only consumer key and consumer secret. My code works great for GET, GET with parameters in the URL, and POST. When I issue a POST request that has parameters in the URL, though, the request fails authorization. I'm trying to figure out why.
The server is using Apache Commons OAuth, so I'd like to compare my base string with that library. Here's a contrived example and the base string and signature produced by my library. Can anyone see what the problem is?
consumer key: abcdef
consumer secret: ghijkl
POST request: http://emptyrandomhost.com/a/uriwith/params?interesting=foo&prolific=bar
my base string: POST&http%3A%2F%2Femptyrandomhost.com%2Fa%2Furiwith%2Fparams&interesting%3Dfoo%26oauth_consumer_key%3Dabcdef%26oauth_nonce%3D1%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D2%26oauth_version%3D1.0%26prolific%3Dbar
This data produces the following OAuth header authorization:
Authorization: OAuth oauth_consumer_key="abcdef",
oauth_version="1.0",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="2",
oauth_nonce="1",
oauth_signature="Z0PVIz5Lo4eB7aZFT8FE3%2FFlbz0%3D"
And apparently my signature is wrong. The problem has to either be in the construction of the base string, in the way that the HMAC-SHA1 function is implemented (using Apple's CCHmac from CommonHMAC.h, so hopefully this isn't it), or with my Base64Transcoder, which is open source c. 2003 by Jonathan Wight/Toxic Software. I primarily suspect the base string, since the requests work for GET and POST and only fail with POST with URL parameters as above.
Can someone with lots of OAuth experience spot the problem above? Something else that would be very useful is the base string that is produced by Apache Commons OAuth in their authentication. Thanks.
As per RFC 5849 section 3.4.1.2, the OAuth base string URI does not include the query string or fragment. If either the client or the server does not remove the query parameters from the base string URI and add them to the normalized OAuth parameter list, the signatures won't match. Unfortunately, it's hard to tell which side is making this mistake. But it's easy to determine this is the problem: If it always works without query parameters but always fails with query parameters, you can be pretty sure that one side or the other is generating the wrong base string. (Be sure that it always happens though... intermittent errors would be something else. Similarly, if it never works with or without a query string, that would also be something else.) The other possibility is that normalization was done incorrectly — the parameter list must be sorted and percent encoded sequences must be upper-cased. If it's not normalized correctly on both sides, that will also cause a base string mismatch, and thus a signature mismatch.
you can build and check visually your request at this URL:
http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iv-signing-requests/
Open the boxes denoted by [+] signs and fill in your values, that way you may be able to see if the problem is at your code, or at the provider side.
I searched on Google and StackOverflow to find a answer to my question but I can't find one.
I'd like to store the access_token to my database for offline access and I'd like to be sure to specify the correct length of my column.
I can't even find if it's just a number or a mix between number and strings.
I work at Facebook and I can give a definitive answer about this.
Please don't put a maximum size on the storage for an access token. We expect that they will both grow and shrink over time as we add and remove data and change how they are encoded.
We did give guidance in one place about it being 255 characters. I've updated the blog post that had that information and updated our new access token docs to include a note about sizes:
https://developers.facebook.com/docs/facebook-login/access-tokens/
Sorry for the confusion.
With Facebook's recent move to encrypted access tokens, the length of the access token can be up to 255 characters. If you're storing the access token in your database, the column should be able to accommodate at least varchar(255). Here's an excerpt from Facebook's Developer blog from October 4, 2011:
"With the Encrypted Access Token migration enabled, the format of the access token has changed. The new access token format is completely opaque and you should not take any dependency on the format in your code. A varchar(255) field will be sufficient to store the new tokens."
Full blog post here: https://developers.facebook.com/blog/post/572
This answer is no longer correct, and I can't find a corrected value in FB's docs. We have been receiving access tokens that are longer than 255 characters. We're moving from VARCHAR to a SMALLTEXT instead to try to future-proof things.
From section 1.4 of The OAuth 2.0 Authorization Protocol (draft-ietf-oauth-v2-22)
Access tokens can have different formats, structures, and methods
of utilization (e.g. cryptographic properties) based on the
resource server security requirements. Access token attributes and
the methods used to access protected resources are beyond the scope
of this specification and are defined by companion specifications.
I looked for the "companion specifications" but didn't find anything relevant and in section 11.2.2 it states
o Parameter name: access_token
o Parameter usage location: authorization response, token response
o Change controller: IETF
o Specification document(s): [[ this document ]]
Which seems to indicate that the access_token parameter is defined within this spec. Which I guess the parameter is but the actual access token isn't fully fleshed out.
Update:
The latest version of this writing of the specification (draft-ietf-oauth-v2-31) includes an appendix that defines better what to expect from the access_token parameter
A.12. "access_token" Syntax
The "access_token" element is defined in Section 4.2.2 and
Section 5.1:
access-token = 1*VSCHAR
So essentially what this means is that the access_token should be at least 1 character long but there is no limit on how long defined in this specification.
Note they define VSCHAR = %x20-7E
Facebook access token can be longer than 255 characters. I had a lot of errors like ActiveRecord::StatementInvalid: PG::StringDataRightTruncation: ERROR: value too long for type character varying(255) where the value was facebook access token. Do not use string type column because its length is limited. You can use text type column to store tokens.
Recently, our app has been seeing them longer than 100 characters. I'm still looking for documentation so I can figure out a 'safe' field size for them.
I'll update the answer from the time spend.
From the OAuth2 documentation,
The access token string size is left undefined by this specification. The client should avoid making assumptions about value sizes. The authorization server should document the size of any value it issues.
(Section 4.2.2 of this document)
Note: Facebook is using OAuth2, as mentionned on this page.
So now, no informations seems to be available on the developers portail of Facebook about the length of the OAuth token. Yahoo seems to use a 400 bit long token, so it's best to assume that a TEXT column in MySQL is safer than a varchar.