Cross-Origin Authentication using Javascript APIs

From Social ID Developers
Jump to: navigation, search

Most Javascript APIs depends on the current login session to manage information regarding the user logged in. The login session is implemented using cookies to store information about the current user’s connection and track the user's session status in the browser.

In the context of customer’s website, the domain is considered a third-party application, so the cookies managed by Social-ID Platform are defined as third-party cookies. When the authentication is performed by customer's website using the Social-ID Platform, it's considered a cross-origin authentication, when two different domains need to share resources. Many standards support these cross-origin sharing, like CORS, JSONP and Web Messaging.

Cross-Origin Authentication

The Javascript APIs implements cross-origin authentication in the following APIs:

  • socialid.login.startLogin: used to initiate the social login process. It redirects to the Social-ID Platform, that performs the login by redirecting to the social provider and creating the user's session.
  • socialid.login.startSession: used just to create the user's session given a connection_id. It redirects to the Social-ID Platform, that validates the connection_id and creates the session.
  • socialid.login.loginConnection: used just to create the user's session given a connection_id, but do not redirect to the Social-ID Platform. It's not fully compatible with Safari browser.

Browser Support

The Javascript API is supported on all modern browsers with third-party cookies support enabled, that is the default behavior for most of them, like Chrome and Firefox, except for Safari.

When third-party cookies are disabled (either by the user or default), the Javascript APIs that depends on the current login session will not work.


Safari browser implements a different mechanism: Intelligent Tracking Prevention. Intelligent Tracking Prevention collects many statistics and applies Machine Learning to identify potential risk to cross-site tracking, periodically deleting tracking data unless the user visits the third-party content provider. In practice, it blocks cookies from third-party applications unless the user interacts with these applications at the top domain, that is, if the user access the third-party application as a first-party application.

It affects how Single Sign-On is managed in Safari browsers, since customer's sites use as the central user session for all sites. The Single Sign-On could not work properly with the API socialid.login.loginConnection, because Safari browsers (desktop and mobile) would require the user to have accessed the domain in order to accept cookies from it. The APIs socialid.login.startLogin and socialid.login.startSession redirect the user to the domain as a first-party application, therefore the cookies for the user's session can be properly created and can be accessed later in the customer's site as third-party cookies.

Besided that, the sessions will be limited to 24-hour expiration, until the user interacts with the top domain ( again.

Personal tools