Skip to main content
This topic outlines the basics of Digital Identity Management’s Social Authentication (commonly known as Social Login). As an alternative to a standard username and password login, ULM users can authenticate themselves using a social media profile that is associated to their ULM digital user ID. Supported social providers follow the OAuth2 authorization framework specification (RFC-6749). The social media authentication scenario follows a standard flow:
  1. A user selects their preferred social media on the UI login page.
  2. The UI calls the Onboard & Authenticate User with Social Account Process. Note: Like most Digital Identity Management Processes, this Process is invoked using the Process Start API.
  3. The browser redirects to the selected social provider, and the user authenticates with that service. The browser redirects to the selected social provider, and the user authenticates with that service.
  4. The social provider prompts the user to accept OAuth scopes (e.g. “ULM needs your email, name” etc).
  5. The user accepts.
  6. The social provider redirects them back to ULM, with an OAuth authorization code stored in the URL.
  7. The performs a backend call to the social provider and exchanges the Oauth authorization code for an access token and refresh token. These tokens signify to ULM that the user is authenticated.
  8. Digital Identity Management creates a user session and stores a JSESSIONID and Remember-me token in the user’s browser.
Subsequent authentication calls to the same social provider will usually skip steps 4 and 5, because social provider remembers the user’s previous consent. If the provider forgets that consent, then the user will need to re-consent to sharing their details with Digital Identity Management. Note: Subsequent authentication calls to the same social provider will usually skip steps 4 and 5, because social provider remembers the user’s previous consent. If the provider forgets that consent, then the user will need to re-consent to sharing their details with ULM Cloud.

​
User Session Cookies

Once a user successfully authenticates with Digital Identity Management, the browser stores a JSESSIONID token and an optional remember-me token (called the mint-sso-token) returned in the API call. JESSIONID cookies are generally short-lived (between minutes and hours) and do not persist between browser windows, devices, or other session demarcation points. Remember-me tokens, conversely, are long-lived tokens (between hours, days, and even months) that are used to transparently recreate a user’s session without the need for the user to authenticate again. Remember-me tokens are optional. If a remember-me token is provided alongside a JSESSIONID, the remember-me token always takes precedence. In other words, if an expired JSESSIONID is provided alongside a valid remember-me token to any REST API, then that API uses the remember-me token to create a new user session and return a new JSESSIONID to the browser. Similarly, if a valid JSESSIONID is provided but does not match the session identifier in a provided remember-me token, then the current session is destroyed and a new session created in its place, with a new JSESSIONID returned that matches the remember-me token. In any instance that a remember-me token is used to construct a new session, the system invalidates that particular remember-me token and issues a new one. This is a security measure to prevent cookie theft attacks from obtaining reusable authentication tokens.

​
Digital Identity Management Process API

Social Authentication is handled by the Onboard & Authenticate User with Social Account Process. This Process is initiated by the Process Start API and if user onboarding and verification is required, the Process is continued and completed with subsequent Process Step API requests. The Process is designed to responsively handle a variety of use cases. It can go in different paths depending on:
  • Whether or not the user already has a Digital Identity Management User ID.
    • If not, then the Process onboards the user first, using information shared from the social provider.
  • What social providers your organization has configured and enabled.
    • Social provider integrations are enabled by creating an app with the provider and then registering that app’s details in the MarketONE Admin console.
  • Whether or not the specific social provider is provided in the initial request.
    • If the Process Start request does not include the providerId in the request URL, then Digital Identity Management responds with a list of available providers and prompts the client to specify one. The client should, in turn, prompt the user with the same list, if this is the desired UI flow.
  • Whether or not the user’s Digital Identity Management User ID is already associated to the selected provider.
  • The data returned from the social provider (e.g., the user’s email or mobile number with that provider).
  • The decisions that the user makes if and when they are prompted to confirm data from the provider.
Once the user is authenticated, Digital Identity Management User details can be obtained via the GET /user API. The user can close their session with the POST /session/end API (with no payload). This invalidates both the current session (identified by the JSESSIONID cookie) and any issued remember-me tokens, but will not invalidate any other sessions the user may have. Note: Access to any protected REST API requires, at a bare minimum, a valid JSESSIONID token. Parent topic:User Authentication