|
|
Security
From $1
In this page you will learn how to incorporate security functionality into your integration with Gigya Socialize.
The security features provided by Gigya Socialize include:
- 1. Using Socialize in Secured Pages (Https) - learn how to communicate with Gigya Socialize over a secure connection (SSL).
- 2. Cryptographic Signatures - learn how to generate and check cryptographic signatures to verify the authenticity of Socialize processes and prevent fraud.
Note: This page discusses security features in the context of integrating Gigya Socialize on client application (web pages or flash widgets). When integrating Gigya Socialize on Server Side ( Socialize REST API), Gigya requires that every API call will be signed. This subject is discussed in the Server Side API (REST) page under Signing requests.
Using Socialize in Secured Pages (Https)
Gigya Socialize supports https, meaning - you have the choice to communicate with Gigya Socialize over a secure connection (SSL).
If you choose to integrate Gigya Socialize within secured pages, you are encouraged to communicate with Gigya Socialize over a secure connection.
Implementing that is very simple, all you need to do is to including the Socialize JS file from our https domain:
Every page that uses the Gigya Socialize API should include the GS Java-script library in the <HEAD> section (refer to Getting Started, for the complete guide).
On non-secured pages, the line of code is:
<script type="text/javascript" src="http://cdn.gigya.com/JS/socialize.js?apikey=INSERT-YOUR-APIKEY-HERE" ></script>
And, on secured pages, the line of code should be:
<script type="text/javascript" src="https://cdns.gigya.com/JS/socialize.js?apikey=INSERT-YOUR-APIKEY-HERE" ></script>
Note: This feature applies to integrating GS in web-pages (JavaScript API). This feature is currently not supported for ActionScript environment (when integrating GS in Flash widget).
Cryptographic Signatures
Gigya Socialize supports a mechanism to verify the authenticity of Socialize processes, to prevent fraud.
When Gigya sends you information about a user, your server needs to know that it is actually coming from Gigya. Also when you send authentication information to Gigya, Gigya needs to make sure that the information came from your server, and not from a malicious hacker.
The key to verification is your partner's "Secret Key" (Your secret key, is provided, in BASE64 encoding, at the bottom of the Site Setup page on the Gigya website). There are only two parties that know the secret: your application server, and Gigya. Whenever Gigya sends data to your server, it includes a signature that is encoded using your secret key. You can perform the same encoding, and check the signature to make sure it matches. A hacker can't generate that signature because he doesn't know your secret key.
We use the HMAC-SHA1 algorithm for generating the signature.
Your site will receive the cryptographic signature provided by Gigya in methods' callback function as part of the response object / User object / Friend object (corresponding to the relevant process).
We highly recommend verifying the authenticity of the signature to prove that it is indeed originating from Gigya, rather than somewhere else.
In addition we require every socialize.notifyLogin call and socialize.linkAccounts call to be signed using a HMAC-SHA1 signature. The signature is passed as a method parameter. Gigya will verify the authenticity of the signature parameter to prove that it is in fact coming from your site and not from somewhere else.
The "signIDs" Field in the Conf Object
If the Conf object's "signIDs" field is set to "true", all User object and Friend objects returned by various API methods or events will be signed by Gigya. The default value is "false".
The Secured Processes and Objects:
- socialize.login -
Your site will receive a cryptographic signature, a timestamp and UID in the login method's callback function as part of the response object (please refer to the Response object Data Members table). To verify the authenticity of the login process, follow the instructions in the section below, using these three fields. - socialize.showLoginUI (the onLogin Event) -
When using the Login Widget, the onLogin global event may be triggered (the onLogin global event is fired, when a user successfully logs in to GS). If you register to the onLogin global event, you will receive the onLogin event data in the onLogin event handler function. The onLogin event data includes a cryptographic signature, a timestamp and UID fields. To verify the authenticity of the login process, follow the instructions in the section below, using these three fields. To register an event handler use the socialize.addEventHandlers API method. Refer to the Events page in the Developer's Guide - to learn more about how to handle events generated by Gigya socialize. - socialize.notifyLogin -
Gigya Socialize supports a mechanism to verify the authenticity of the notifyLogin call. This mechanism is used to prove that the call is in fact coming from your site, in order to prevent fraud. We require every notifyLogin call to be signed using a HMAC-SHA1 signature. The "signature" parameter (see notifyLogin's table of parameters) is defined for this objective, and is a required parameter. Gigya will verify the authenticity of the signature parameter to prove that it is in fact coming from your site and not from somewhere else. Follow the instructions in Constructing a Signature to set the signature parameter of the notifyLogin call, and make the API call as soon as possible after that to prevent the signature from expiring. -
socialize.linkAccounts - Gigya Socialize supports a mechanism to verify the authenticity of the linkAccounts call. This mechanism is used to prove that the call is in fact coming from your site, in order to prevent fraud. We require every linkAccounts call to be signed using a HMAC-SHA1 signature. The "signature" parameter (see linkAccounts's table of parameters) is defined for this objective, and is a required parameter. Gigya will verify the authenticity of the signature parameter to prove that it is in fact coming from your site and not from somewhere else. Follow the instructions in Constructing a Signature to set the signature parameter of the linkAccounts call, and make the API call as soon as possible after that to prevent the signature from expiring. - User object -
If the Conf object's "signIDs" field is set to "true", Gigya will sign with a cryptographic signature the User object which is returned by various API methods or global events. The following API methods return a User object in the method's callback function as part of the response object: socialize.getUserInfo, socialize.connect, socialize.disconnect, socialize.notifyLogin. If you register to one of the following global events, you will receive a User object, in the corresponding event handler function as part of the event data: onLogin, onConnect, onDisconnect. The User object includes the following three data members, which are relevant for the security process: UID (A unique ID for the person represented by this object), UIDSig (which holds the cryptographic signature) and timestamp. To verify the authenticity of the User Object, follow the instructions in the section below, using these three fields. - Friend object -
If the Conf object's "signIDs" field is set to "true", each Friend object which you receive from Gigya will be signed with a cryptographic signature. Your site may receive a list of friends (Collection of Friend objects) by one of the two methods: 1. If you call socialize.getFriendsInfo API methods, you will receive the list of friends in getFriendsInfo's callback function as part of the response object. 2. If you use the socialize.showFriendSelectorUI and register to the onSelectionDone event, you will receive the list of friends in the onSelectionDone event handler function as part of the onSelectionDone event data. Each Friend object includes the following three data members, which are relevant for the security process: UID (A unique ID for the person represented by this object), friendshipSig (which holds the cryptographic signature) and timestamp. To verify the authenticity of the Friend Objects and the getFriendsInfo process, follow the instructions in the section below, using these three fields.
Verifying the Authenticity of Socialize Response - Signature and Timestamp
To verify the signature: First, reproduce a signature in the exact same manner as Gigya produced it (as described in Constructing a Signature below). Then, compare your reproduced signature with the signature produced by Gigya and received as part of the method response. If the signatures are not identical, the request should be considered forged!
In addition, we recommend verifying that the timestamp is within a few minutes of the current time on your server. The recommended time difference is 5 minutes the most, to compensate for possible time skewing between Gigya's servers and yours. If the time difference is longer than 5 minutes, the request should be considered forged. The timestamp received from Gigya is the response GMT time in "yyyy-mm-dd HH:mm:ss" format where HH is in 24 hour time format.
Please follow these steps to produce a signature:
- Construct a "base string" for signing: "%Timestamp%_%UID%" replacing %Timestamp% and %UID% with the corresponding values.
baseString = timestamp + "_" + UID - Convert your "Secret Key" from its BASE64 encoding to a binary array.
Your partner's "Secret Key", is provided, in BASE64 encoding, at the bottom of the Site Setup page on the Gigya website (please make sure that you have logged in to Gigya's website and that you have completed the Socialize Setup process).
binaryKey = ConvertFromBase64(secretKey); - Use the HMAC-SHA1 algorithm to calculate the cryptographic signature of the "base string" constructed in step 1, with your binary "Secret Key", calculated in step 2.
The HMAC-SHA1 algorithm is implemented in many standard libraries and is readily available in any web development environment. The HMAC-SHA1 method usually receives two parameters: a binary key, and a buffer to be signed. It returns the signature as a binary array, which represents the signed buffer. Depending on your development environment you may have to convert the baseString to a binary buffer before calling the hmacsha1 method. As the first parameter - use the binary "Secret Key" calculated in step 2 above.
binarySignature = hmacsha1(binaryKey, baseString); -
Encode the binary hash generated by the HMAC-SHA1 algorithm to a BASE64 string.
mySignature = ConvertToBase64(binarySignature);
Notes:
- Signature construction should be implemented on server side.
- When sending the parameters from your client to your server, please make sure you encode the UID parameter using the encodeURIComponent() function, before sending it to your server, and then decode it on your server before calculating the signature.
- The code snips above are illustrative, and do not constitute functional code.
Implementation Examples
The following are code examples of generating a signature:
C# PHP 5.1.2 onward PHP up to 5.1.2 Java
public static string calcHmacsha1Signature(string secretKey, string UID, string timeStampStr)
{
byte[] chlngData = Encoding.UTF8.GetBytes(timeStampStr + "_" + UID);
byte[] keyData = Convert.FromBase64String(secretKey);
System.Security.Cryptography.HMACSHA1 hmac = new System.Security.Cryptography.HMACSHA1(keyData);
byte[] macReciever = hmac.ComputeHash(chlngData);
return Convert.ToBase64String(macReciever);
}
<?php
$secretKey = 'e9iOIUrvO+gdXZxddOTtVTP0uUaLRZ7pzr65aN+636Y='; // Note that the secret key is the BASE64 key
$timestamp = '2009-06-21 09:23:07';
$UID = '_gid_JzJbawKx/a7CTEuufrQ03A==';
echo calcHmacsha1Signature($secretKey, $UID, $timestamp);
function calcHmacsha1Signature($secretKey, $UID, $timestamp) {
$base_string = $timestamp.'_'.$UID;
return base64_encode(hash_hmac('sha1', $base_string, base64_decode($secretKey), true));
}
?>
<?php
$secretKey = 'e9iOIUrvO+gdXZxddOTtVTP0uUaLRZ7pzr65aN+636Y='; // Note that the secret key is the BASE64 key
$timestamp = '2009-06-21 09:23:07';
$UID = '_gid_JzJbawKx/a7CTEuufrQ03A==';
echo calcHmacsha1Signature($secretKey, $UID, $timestamp);
function calcHmacsha1Signature($secretkey, $UID, $timestamp) {
return hmacsha1(base64_decode($secretkey), $timestamp.'_'.$UID);
}
function hmacsha1($key,$data) {
$blocksize=64;
$hashfunc='sha1';
if (strlen($key)>$blocksize)
$key=pack('H*', $hashfunc($key));
$key=str_pad($key,$blocksize,chr(0x00));
$ipad=str_repeat(chr(0x36),$blocksize);
$opad=str_repeat(chr(0x5c),$blocksize);
$hmac = pack('H*',$hashfunc(($key^$opad).pack('H*',$hashfunc(($key^$ipad).$data))));
return base64_encode($hmac);
}
?>
public static String calcHmacsha1Signature(String secretKey, String userId, String timestamp)
throws java.security.SignatureException {
String signature;
String baseString = timestamp + "_" + userId;
try {
byte[] secret = org.apache.commons.codec.binary.Base64.decodeBase64(secretKey.getBytes());
// get an hmac_sha1 key from the raw key bytes
javax.crypto.spec.SecretKeySpec signingKey = new javax.crypto.spec.SecretKeySpec(secret, "HmacSHA1");
// get an hmac_sha1 Mac instance and initialize with the signing key
javax.crypto.Mac mac = javax.crypto.Mac.getInstance("HmacSHA1");
mac.init(signingKey);
// compute the hmac on input data bytes
byte[] rawHmac = mac.doFinal(baseString.getBytes());
// base64-encode the hmac
signature = new String(org.apache.commons.codec.binary.Base64.encodeBase64(rawHmac));
} catch (Exception e) {
throw new java.security.SignatureException("Failed to generate HMAC : " + e.getMessage());
}
return signature;
} // Written by Mark Gilbert
< Back to 'Authentication' | Next to 'Share Content' >
|