Login Tokens

(Difference between revisions)
Jump to: navigation, search
(Security)
(Security)
Line 47: Line 47:
 
The JavaScript APIs use the session of the user currently logged into the Social Login, or identifiers like connection_id and user_token as authentication parameters.
 
The JavaScript APIs use the session of the user currently logged into the Social Login, or identifiers like connection_id and user_token as authentication parameters.
  
JavaScript APIs required a bigger effort to ensure security because they are used on the visitor's browser (i.e. it's not possible to guarantee JavaScript code validity) and in unpredictable conditions (i.e. in public, non-encripted Wi-Fi networks). As with any browser session, JavaScript APIs may be subject to [http://en.wikipedia.org/wiki/Session_hijacking Session Hijacking] or [http://en.wikipedia.org/wiki/Man-in-the-middle_attack Man-in-the-middle], among others.
+
JavaScript APIs requires a bigger effort to ensure security because they are used on the visitor's browser (i.e. it is not possible to guarantee JavaScript code validity) and in unpredictable conditions (i.e. in public, non-encrypted Wi-Fi networks). As with any browser session, JavaScript APIs may be subject to [http://en.wikipedia.org/wiki/Session_hijacking Session Hijacking] or [http://en.wikipedia.org/wiki/Man-in-the-middle_attack Man-in-the-middle], among others.
  
 
To minimize security risks, we show below a list of good practices. Developers using our APIs need to be aware that the indiscriminate use of connection_id and user_token identifiers may increase those risks.
 
To minimize security risks, we show below a list of good practices. Developers using our APIs need to be aware that the indiscriminate use of connection_id and user_token identifiers may increase those risks.
Line 53: Line 53:
 
=== Good Practices ===
 
=== Good Practices ===
  
* Log off the user from Social Login every time he logs off your application. Use the [[socialid.login.logout]] JavaScript API or the [[DELETE login/connections/:id]] REST API.
+
* Log the user off from Social Login every time he/she logs off your application. Use the [[socialid.login.logout]] JavaScript API or the [[DELETE login/connections/:id]] REST API.
  
* Update user_token periodically using the [[PUT login/users/:user_id/token]] REST API. As the user_token doesn't expires and may be used on critical JavaScript APIs (e.g. to log in or move users), it's advisable to update this token periodically to avoid [http://en.wikipedia.org/wiki/Session_hijacking Session Hijacking].
+
* Update the user_token periodically using the [[PUT login/users/:user_id/token]] REST API. As the user_token doesn't expires and may be used on critical JavaScript APIs (e.g. to log in or move users), it's advisable to update this token periodically to avoid [http://en.wikipedia.org/wiki/Session_hijacking Session Hijacking].
  
 
* Use secure connections ([http://en.wikipedia.org/wiki/Https HTTPS]) on your website to avoid tokens to be intercepted by attackers on unprotected networks. See [http://en.wikipedia.org/wiki/Man-in-the-middle_attack Man-in-the-middle attack].
 
* Use secure connections ([http://en.wikipedia.org/wiki/Https HTTPS]) on your website to avoid tokens to be intercepted by attackers on unprotected networks. See [http://en.wikipedia.org/wiki/Man-in-the-middle_attack Man-in-the-middle attack].
  
* Avoid storing any token in cookies. If you must do it, use the "[http://en.wikipedia.org/wiki/HTTP_cookie#Secure_and_HttpOnly secure]" attribute on the cookie.
+
* Avoid storing any tokens in cookies. If you must, use the "[http://en.wikipedia.org/wiki/HTTP_cookie#Secure_and_HttpOnly secure]" attribute on the cookie.
  
* Use [[RESTful APIs]] only on backend, never via JavaScript (frontend). The API ID and Secret that are used as [[Authentication]] must not be exposed on users's browsers.
+
* Use [[RESTful APIs]] only on backend, never via JavaScript (frontend). The API ID and Secret that are used as [[Authentication]] must not be exposed on a users's browsers.
  
* Use extra authentication (e.g. login / password authentication) in critical operations on your website (financial operations, credit card data management, etc).
+
* Use extra authentication (e.g. login / password authentication) in critical operations of your website (financial operations, credit card data management, etc).

Revision as of 11:36, 6 November 2014

Contents

Tokens

login_token

It is the token generated each time a visitor performs a social login.

The token is returned on the socialid.events.onLoginSuccess event or sent as a parameter to the callback url configured on the Social Login application.

Characteristics:

  • Updates: every time the user logs in.
  • Validity: expires in 1 hour.

APIs:

connection_id

It is an identifier generated for each visitors' active connection. It represents the Social Login session for the current visitor.

The Social Login widgets automatically identifies users logged in, given the connection_id saved on a cookie on the visitor's browser.

Characteristics:

  • Updates: every time the user logs in or using an API call.
  • Validity: expires in 15 days.

APIs:

user_token

It is a token used in a few JavaScript APIs to identify the user in a secure way.

Characteristics:

  • Updates: every time the user logs in or via API.
  • Validity: never expires.

APIs:

Security

The REST APIs use the HTTP Basic protocol for authentication. See the Authentication documentation.

The JavaScript APIs use the session of the user currently logged into the Social Login, or identifiers like connection_id and user_token as authentication parameters.

JavaScript APIs requires a bigger effort to ensure security because they are used on the visitor's browser (i.e. it is not possible to guarantee JavaScript code validity) and in unpredictable conditions (i.e. in public, non-encrypted Wi-Fi networks). As with any browser session, JavaScript APIs may be subject to Session Hijacking or Man-in-the-middle, among others.

To minimize security risks, we show below a list of good practices. Developers using our APIs need to be aware that the indiscriminate use of connection_id and user_token identifiers may increase those risks.

Good Practices

  • Update the user_token periodically using the PUT login/users/:user_id/token REST API. As the user_token doesn't expires and may be used on critical JavaScript APIs (e.g. to log in or move users), it's advisable to update this token periodically to avoid Session Hijacking.
  • Use secure connections (HTTPS) on your website to avoid tokens to be intercepted by attackers on unprotected networks. See Man-in-the-middle attack.
  • Avoid storing any tokens in cookies. If you must, use the "secure" attribute on the cookie.
  • Use RESTful APIs only on backend, never via JavaScript (frontend). The API ID and Secret that are used as Authentication must not be exposed on a users's browsers.
  • Use extra authentication (e.g. login / password authentication) in critical operations of your website (financial operations, credit card data management, etc).
Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox