SSO

When the SSO feature is activated on your account, ReachFive manages the end user cookie session.

When a user logs in, a session cookie is created on your ReachFive tenant (YOUR_ACCOUNT.reach5.net). This avoids forcing the user to log in again on a later visit, or when accessing another website linked to the same ReachFive account.

On your website, the state of the session must be checked before displaying the login UI. If a session is active, the user must be directly authenticated and the login UI bypassed.

Configure Session duration

  1. In the ReachFive Console, go to Security  SSO.

  2. Set the Session lifetime in days (default is 3 days).

  3. Set the Require log in after in days (maximum value is 365 days in compliance with the GDPR).

  4. If desired, specify the Allowed logout callback URLs.

    This is optional. If URLs are specified here, the user will only be redirected to these whitelisted URLs. See the logout page for more details.

  5. Don’t forget to Save your input.

The setting is active immediately to all clients within the ReachFive account.

Session duration is renewed with the next /oauth/authorize operation or the equivalent SDK method, for instance checkSession or loginFromSession. If the cookie session lifetime expands beyond the Require login after parameter period, then the user will be forced to re-authenticate.

Using the ReachFive authentication widget

When using the ReachFive authentication widget, this process is implemented transparently:

// If a session is active, the widget will not be displayed, and the
// authentication process will be triggered with the specified auth parameters.
reach5('showAuth', {
  container: document.body,
  auth: {
    redirectUri: 'https://mydomain.com/login/callback'
  }
});

Using a custom UI

With a custom UI, you must explicitly check the session state (with the getSessionInfo command) before displaying the UI.

If a session is active, you can use the loginFromSession command to authenticate the user.

var authOptions = {
    redirectUri: 'https://mydomain.com/login/callback'
};

reach5('getSessionInfo', function (err, session) {
    if (session.isAuthenticated) {
        // If a session is active, trigger the authentication process
        reach5('loginFromSession', authOptions, function (err) {
          console.error(err);
          document.getElementById("login-form").style.display = 'block';
        })
    } else {
      // If not, display the login form
      document.getElementById("login-form").style.display = 'block';
    }
});

Silent authentication

Use Silent Authentication to authenticate users on your website’s public pages without triggering a browser redirect.

It allows to retrieve an id token and an access token directly, without a redirect (the authentication process happens in a hidden iframe).

reach5('checkSession',
    {
      nonce: 'abcd' // The nonce links the retrieved id token with the local session
    },
    function (err, authResult) {
      if (err) {
        if (err.error === 'login_required') {
          // No active session
        } else {
          // Unexpected error
          console.error(err)
        }
      } else {
        // Authenticate the current user locally
      }
    }
);

SameSite cookies

The SameSite attribute (set on the Set-Cookie HTTP response header) enables you to declare if your cookies are restricted to first-party clients or same-site context.

At ReachFive, we set SameSite to Lax for all browsers except Safari. For Safari, we use SameSite = None.

What’s the difference?
Lax

Cookies are not sent on normal cross-site subrequests, but are sent when a user is navigating to the origin site.

None

Cookies are sent in all contexts.

For more details, see Mozilla’s SameSite reference docs.

Safari

Apple Safari does not currently handle SameSite=None HTTPS cookies properly, meaning cookies might not be set for Safari users.

This can be mitigated by using Refresh Tokens to handle long-term sessions. To obtain a Refresh Token, make sure PKCE is enforced in your client configuration, and that the requireRefreshToken option is set to true or that your scope includes the offline_access value.