Best Practices for Secure Applications
At LinkedIn, we take our members' privacy very seriously. When we grant access to APIs, we expect developers to take members' privacy just as seriously as we do. The LinkedIn platform uses permissions to protect and prevent abuse of our members' information. By using the OAuth 2.0 authentication protocol, we allow an application to access LinkedIn data while protecting members' credentials. Because of this protocol, members are ensured that applications on our platform are safe and easy to use.
You should always request the minimal scopes necessary and only request permissions that are needed for application functionality.
Ensure your application follows these best practices.
Using access tokens, you can access a member's private information through the LinkedIn APIs. To keep access tokens safe:
- Do not store access tokens in code files that can be decompiled such as Native iOS, Android, or Windows Application code files.
- When making calls, always pass access tokens over a secure (HTTPS) connection.
API Key and Secret Key
Two pieces of identifiable information are required to make calls to the LinkedIn API: Client ID (also known as Consumer Key or API key) and Client Secret.
The Client ID is a public identifier of your application. The Client Secret is confidential and should only be used to authenticate your application and make requests to LinkedIn's APIs.
Both the Client ID and Client Secret are needed to confirm your application’s identity and it is critical that you do not expose your Client Secret. Follow these suggestions to keep the secret safe:
- When creating a native mobile application, do not store it locally on a mobile device.
- Do not store it in files on a web server that can be viewed externally. For example, 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 forums.
Remember that when exchanging an OAuth 2.0 authorization code for an access token, the Client Secret is passed as part of the request. Make sure you do not expose this request publicly!
To prevent others from reading your requests and to prevent man-in-the-middle attacks, all requests to our authentication servers must be done over HTTPS. Additionally, OAuth 2.0 requests require you to use HTTPS. Your application should also ideally be hosted on a secure server, particularly for 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.
Cybercriminals often create websites that look and feel authentic but are really just replicas created to steal user credentials. Educate your users to look for signs to ensure they are entering credentials for a real LinkedIn application. Note that browsers may look different and this may not always be enough to differentiate a legitimate site from a phishing site. Alert members not to enter credentials when in doubt and to contact you when they suspect suspicious activity.
In Firefox, the real LinkedIn login has a closed padlock icon and a URL that starts with "https://www.linkedin.com/...". 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").
Similar to Firefox, Chrome displays a green padlock near the URL and highlights HTTPS in green to indicate legitimacy.
Cross-Site Request Forgery
To protect against CSRF attacks, during authorization, you must pass a state parameter. This should be a unique string value (for each request) that is difficult to guess and should not contain private or sensitive information.
Sample State Value
On successful authorization, the redirected URL should look like:
Sample Callback URL
Make sure that the state parameter in the response matches the one you passed in your authorization request. If the state does not match, the request may be a result of CSRF and should be rejected.
When using a third-party library to interact with LinkedIn's APIs, make sure that the library is from a trusted source. Read reviews, look at the code, and do some background research to make sure the library is not malicious and does not behave unexpectedly. LinkedIn does not officially support third-party libraries. Contact the library’s development team if you have technical questions or concerns.