This is a preview of unreleased docs from main. View the published docs
Skip to main content

Social Login

On desktop, social login uses a popup window flow. The popup navigates through the OAuth redirect loop and communicates the result back to the parent window via window.postMessage, keeping the JWT out of the browser's URL history, server logs, and referrer headers.

On mobile, and anywhere the browser refuses to open the popup, it uses a redirect flow instead: the current page navigates to the provider and comes back when the reader has signed in. See Mobile and in-app browsers.

Supported Providers​

Providers must be configured by the tenant administrator in Organization Settings → Login Providers. Supported providers include Google, Apple, and Facebook.

Using the allegro-login-form Component​

The <allegro-login-form> web component includes social login buttons automatically:

<allegro-login-form></allegro-login-form>

To hide the social buttons:

<allegro-login-form hide-third-party="true"></allegro-login-form>

The component fires allegro:login-form:third-party:authenticated with { provider, session_id, token } on successful OAuth login, whether it used the popup or the redirect flow. On mobile, and when the browser blocks the popup, the component switches to the redirect flow automatically.

Using the SDK​

Call allegro.member.loginWithProvider(provider) to open the OAuth popup and await the result:

try {
    const { session_id, token } =
        await allegro.member.loginWithProvider('google');
    console.log('Authenticated, session:', session_id);
} catch (error) {
    console.error('Auth failed:', error);
}

Pass the provider slug as a string — for example 'google', 'apple', or 'facebook'. The method opens the popup, waits for the OAuth flow to complete, and resolves with the session on success or rejects on failure.

Response shape:

{
    session_id: string; // UUID of the newly created audience member session
    token: string; // Signed JWT for the session
}

Mobile and in-app browsers​

Many mobile browsers, and especially the in-app browsers that open links inside apps, can't open a popup or can't pass a message back from one. The redirect flow avoids popups entirely:

  1. The page navigates to the provider in the same window.
  2. After the reader signs in, the provider returns to Allegro, and Allegro redirects back to the original page with a one-time allegro_social_code query parameter.
  3. On page load, the SDK exchanges the code for the member's JWT, removes the parameter from the URL, and signs the member in.

When the page comes back, the SDK scrolls to where the reader was, and interactions skip their time and scroll delays. A login form inside a delayed interaction, such as a content gate that opens at a scroll depth, opens at once and shows the result.

<allegro-login-form> uses the redirect flow on phones and tablets, and falls back to it whenever loginWithProvider rejects because the popup was blocked. To start it yourself, call loginWithProviderRedirect with the URL to return to:

allegro.member.loginWithProviderRedirect('facebook', window.location.href);

The return URL must be on one of the origins allowed in your browser settings. Because the page reloads, listen for the result on window rather than awaiting a promise:

window.addEventListener('allegro:social:authenticated', (event) => {
    const { provider, created } = event.detail;
    console.log(`Signed in with ${provider}`, created ? '(new member)' : '');
});

window.addEventListener('allegro:social:failed', (event) => {
    console.warn('Social login failed:', event.detail.error);
});
EventDetailWhen
allegro:authenticated{ method: 'social', provider: string }The SDK signed the member in after a redirect.
allegro:social:authenticated{ provider: string, created: boolean, session_id: string, token: string }Same moment, with the session details.
allegro:social:failed{ error: string }The reader canceled (auth_cancelled), the provider returned no email (no_email), or the login failed (auth_failed, exchange_failed).

The SDK also records the outcome on allegro.socialLoginValidation ('pending', 'authenticated' or 'failed') and the error code on allegro.socialLoginError, so code that runs after the event has fired can still read it.

To catch a blocked popup in your own code, check the error's name:

try {
    await allegro.member.loginWithProvider('google');
} catch (error) {
    if (error.name === 'PopupBlockedError') {
        allegro.member.loginWithProviderRedirect(
            'google',
            window.location.href,
        );
    }
}
Google in embedded app webviews

Google blocks sign-in inside embedded webviews, such as a native app's WKWebView or Android WebView, and shows a 403 disallowed_useragent error whichever flow you use. Facebook, Apple, and the other providers work there with the redirect flow. For Google to work inside your own app, open your pages in SFSafariViewController (iOS) or Chrome Custom Tabs (Android) instead of an embedded webview.

Reading the Provider Profile​

After a member authenticates with a provider, Allegro stores the raw profile data returned by that provider (name, email, avatar URL, etc.). You can fetch this data in your templates using allegro.member.externalProfile(provider):

window.allegro.push(async (allegro) => {
    if (!allegro.member.isAuthenticated()) return;

    try {
        const profile = await allegro.member.externalProfile('google');
        console.log(profile.name, profile.email, profile.picture);
    } catch (error) {
        // Member has no Google profile, the request failed, or the session expired
        console.error('Profile not found:', error);
    }
});

Pass the provider slug as a string (e.g. 'google', 'apple', 'facebook'). The method returns the raw attributes stored for that provider — the exact shape depends on what each provider includes in their response. The method throws if the member has no linked profile for the given provider, so always wrap the call in a try/catch.