Best Practices for Secure Applications

At LinkedIn we take our member's privacy very seriously. When we grant developers API access, we expect them to take member privacy as seriously as we do. By using the OAuth 2.0 authentication protocol we allow an application to access LinkedIn data while protecting the member's credentials. Using this protocol allows applications on our platform to be safe and easy to use for our members; however, there are some security steps that you as a developer will have take to continue to make their experience as secure as possible.

Please read the following guide and make sure that your application follows these best practices:

Access tokens

Access tokens allow a developer to access a member’s private information through our API. To keep them safe do not store them in insecure locations or locations that are easily accessible. Client side files, such as JavaScript or HTML files, should never be used to store sensitive information, as these can easily be accessed. You should also not store access tokens in code files that can be decompiled like Native iOS, Android, or Windows Application code files. When making calls to the LinkedIn platform, access tokens must always be passed over a secure (HTTPS) connection.

A developer should always request the minimal scopes necessary and only request permissions that are needed for application functionality.

API Key & Secret Key

When making calls to the LinkedIn APIs you use two pieces of identifiable information: the API Key (sometimes called the Consumer Key) and the Secret Key (or Consumer Secret).

The API Key is a public identifier of your application and the Secret Key is confidential and should only be used to authenticate your application on the LinkedIn APIs.

Since both the API Key and Secret Key are needed together to confirm your application’s identity, it is critical that you never expose your Secret Key.  Here are some suggestions for proper Secret Key storage:

  • When creating a native mobile application, do not store it locally on a mobile device.
  • Do not expose in any client side code files like JavaScript or HTML files.
  • Do not store it in files on a web server that can be viewed externally e.g.: configuration files, include files, etc.
  • Do not store it in log files or error messages.
  • Do not email it or post it on a message board or other public forum.

Remember that when exchanging an OAuth 2.0 authorization code for an access token, the Secret Key is passed as part of the request. Do not expose this request publicly!

Secure endpoints

To prevent others from reading your requests and man-in-the-middle attacks, all requests to our authentication servers must be done over HTTPS. It is also strongly recommended that your application be hosted on a secure server, particularly for any pages where a member enters private information (such as their password for your site) and for any URLs where you ask LinkedIn to redirect the member as part of the OAuth authorization flow.

The use of HTTPS is required for OAuth 2.0 requests.

Phishing prevention

Cyber-criminals often create websites that look and feel authentic but are really fake replicas with the intention to steal user credentials. Educate your users to look for these signs to ensure they are entering credentials for a real LinkedIn application. Note that browsers may look different and sometimes this may not be enough to differentiate from phishing sites. When in doubt, alert users to not enter credentials and contact you when they suspect suspicious activity.

In Firefox, the real LinkedIn login will have a closed padlock icon and have a URL that starts with "" beware of URLs that try to mimic LinkedIn by using common misspellings or swapping similar characters such as "1" (one) for "l" (the letter "L")

Like Firefox, Chrome will display a padlock but in green, also HTTPS will be highlighted to indicate you're connected to the right place.

Cross-site request forgery

To protect against CSRF during authorization, you need to pass a state parameter. This should be a unique string value (for each request) that is difficult to guess and it should not contain any private or sensitive information.

Sample state value

Upon successful authorization, the redirected URL should look like:

sample callback URL

Ensure that the state parameter in this response matches the one you passed in your authorization request. If the state does not match, that means the request may be a result of CSRF and must be rejected.

Third-Party Libraries

When using a third party library to interact with LinkedIn, use your best judgment to ensure that library is from a trusted source. Read their reviews, glance over the code, and do some background research to make sure it is not malicious or has some unexpected behavior. LinkedIn does not officially support any third party library, so if you run into any technical questions or concerns please contact the library’s development team directly.

Error Handling

Due to the nature of cloud APIs, services can be temporarily unavailable due to reasons outside of your or LinkedIn's control. You should assume that any call you make to LinkedIn or any third party API may not work and always include error-handling logic in your requests. This can include any request such as:

  • Authorization requests GET (
  • Fetching data GET (
  • Posting data POST (