Social Login

Enables users to authenticate via social identity providers (Facebook, Google, X) or with their email and password: all from a single login page. Social and credential paths share one Web Page node and fan out to separate verification nodes.

Authentication

How to import

In the Admin Console go to Workflows → New Workflow → From Template, select Social Login, and click Import.

Node Topology

How the Flow Works

1. Entry: every request first hits Has Session.
2. Already logged in: Has Session True routes directly to Success Final, bypassing the login form.
3. No session: Has Session False renders the Login Web Page, which contains both credential inputs (Email + Password) and social provider buttons (Facebook, Google, X).
4. Email and password path: the user fills the form and submits. The Web Page Output feeds into Auth.
   • Auth True: credentials valid; user is redirected to Success Final.
   • Auth False: invalid credentials; the flow loops back to the Login Web Page and the error is shown inline.
5. Social path: the user clicks a social provider button. Each social button triggers the Social Auth node directly.
   • Social Auth True: OAuth handshake succeeded; user is redirected to Success Final.
   • Social Auth False: OAuth handshake failed; flow terminates at Failure Final.

---

Nodes Used & Why

Node	Role	Key config
Has Session	Skips login for already-authenticated users	No config needed
Web Page	Renders the combined login form	Web Page Header defaults to "Social Login"
Email (child)	Collects the user's email address	No change needed for standard flows
Password (child)	Captures the login password	Default type is login
Facebook / Google / X (children)	Social provider buttons	Each requires App Name, API Key, and API Secret matching the provider's OAuth app
Auth	Verifies email and password credentials	Enable error edges for account-locked and similar statuses
Social Auth	Validates the OAuth handshake result	Wire error 4111 if you need a recovery path for misconfigured providers
Success Final	Terminates on successful authentication	Set Redirect URL to your post-login destination
Failure Final	Terminal failure for Social Auth False	Set Redirect URL to a suitable error page

---

Key Design Decisions

SOCIAL AND PASSWORD PATHS SHARE ONE WEB PAGE

Social provider buttons and the email/password form live in the same Web Page node. Social buttons each carry their own output handle that routes directly to Social Auth, while the form submit goes through Auth. You can keep them on one page for a unified experience or split them into separate Web Page nodes for distinct user journeys.

Unified (default)Single Web Page → Auth (form) | Social Auth (buttons). Simpler graph, one page for all login methods.

SplitTwo Web Pages: one for credentials → Auth, one for social → Social Auth. Useful when login methods need different page layouts or branding.

SOCIAL AUTH FALSE TERMINATES AT FAILURE FINAL

Unlike Auth (which loops on False so the user can retry), Social Auth False routes to Failure Final. Social authentication failures (cancelled OAuth flow, revoked token, mismatched state) are terminal conditions with nothing to retry on the same page. Set the Failure Final Redirect URL to an error page that tells the user what happened and offers alternative login options.

CONFIGURE EACH SOCIAL PROVIDER BEFORE DEPLOYING

Each social child node (Facebook, Google, X) requires its own App Name, API Key, and API Secret. These must match the OAuth app credentials from each provider's developer console. The Password Attribute field controls which LR profile field stores the auto-generated password on first social sign-in.

FacebookCredentials from Meta for Developers: Apps

GoogleCredentials from Google Cloud Console: Credentials

X (Twitter)Credentials from X Developer Portal: Projects & Apps