pxUserFrontend.showPasswordForgotForm({
    containerElement: 'pxUserPasswordForgot',
    fallbackTargetUrl: 'https://www.example.com/password-forgot',
    fallbackButtonText: 'Send password reset email!',
    labels: {
        buttonText: 'Send password reset email!',
        email: 'Email-address'
    },
    products: ['sap', 'dam', 'vid'],
    onSuccess: (data) => {
        doSomethingWith(data)
    },
    onError: (error) => {
        doSomethingWith(error)
    }
});

pxUserFrontend.showPasswordSetForm({
    token: 'abc123',
    containerElement: 'pxUserPasswordSet',
    showPasswordRules: false,
    fallbackTargetUrl: 'https://www.example.com/password-set',
    fallbackButtonText: 'Reset Password!',
    labels: {
        buttonText: 'Reset Password!',
        passwordOne: 'Password',
        passwordTwo: 'Password again'
    },
    icons: {
        togglePassword: {
            passwordOne: true,
            passwordTwo: true
        }
    },
    onSuccess: (data) => {
        doSomethingWith(data)
    },
    onError: (error) => {
        doSomethingWith(error)
    }
});

Same flow as Password Set (token from the reset link), but after setting the password the user is logged in: the API returns access_token and refresh_token in data.response (see Activate User and Login).

pxUserFrontend.showPasswordSetAndLoginForm({
    token: 'abc123',
    containerElement: 'pxUserPasswordSetAndLogin',
    showPasswordRules: false,
    fallbackTargetUrl: 'https://www.example.com/password-set-and-login',
    fallbackButtonText: 'Set password and login',
    labels: {
        buttonText: 'Set password and login',
        passwordOne: 'Password',
        passwordTwo: 'Password again',
        mfaInitTitle: 'MFA Setup',
        mfaInitMessage: 'Scan the QR code with your authenticator app or enter the secret manually.',
        mfaInitCodeLabel: 'Token:',
        mfaInitButtonText: 'Set up',
        mfaVerifyTitle: 'MFA Verify',
        mfaVerifyCodeLabel: 'Enter the code from your authenticator app.',
        mfaVerifyButtonText: 'Verify',
        mfaEnabledTitle: 'MFA Enabled',
        mfaEnabledMessage: 'Multi-factor authentication has been enabled.',
        mfaEnabledButtonText: 'Continue',
    },
    icons: {
        togglePassword: {
            passwordOne: true,
            passwordTwo: true
        }
    },
    onSuccess: (data) => {
        doSomethingWith(data)
    },
    onError: (error) => {
        doSomethingWith(error)
    },
    onResetError: (data) => {
        // credentials accepted, additional step required (e.g. MFA) before login completes
        // host should reset any previous onError UI
        clearLoginErrorBanner()
    }
});

Notes:

• MFA init, verify, and enable screens are internal challenge screens. Product integrations should configure their labels on showPasswordSetAndLoginForm; they are not exposed as separate public widget methods.

OIDC-compatible variant of Password Set and Login. Instead of passing tokens to onSuccess, after successfully setting the password the user is logged in and the browser is redirected to the given redirect_uri with an OIDC authorization code (?code=...&state=...&codeType=auth_code&tenant=...&domain=...). The product exchanges that code at the OIDC token endpoint (PKCE required).

pxUserFrontend.showPasswordSetAndLoginWithOidcForm({
    token: 'abc123',
    containerElement: 'pxUserPasswordSetAndLoginWithOidc',
    client_id: 'your-client-id',
    redirect_uri: 'https://product.example/sso/callback',
    state: 'opaque-product-state',
    scope: 'openid',
    code_challenge: 'dEjftdeZ4C...hbUJUXk',
    code_challenge_method: 'S256',
    onError: (error) => { ... },
});

Notes:

• onSuccess is not used to deliver tokens — after successfully setting the password the user is logged in and the top-level page is redirected to redirect_uri.
• MFA challenges are handled inside the widget, exactly like the classic variant.
• All other parameters (labels, icons, showPasswordRules, fallbackTargetUrl, ...) work as in Password Set and Login.

pxUserFrontend.showActivateUserForm({
    token: 'abc123',
    containerElement: 'pxUserActivateUser',
    showPasswordRules: false,
    fallbackTargetUrl: 'https://www.example.com/user-activate',
    fallbackButtonText: 'Set Password!',
    labels: {
        buttonText: 'Set Password!',
        passwordOne: 'Password',
        passwordTwo: 'Activate user'
    },
    icons: {
        togglePassword: {
            passwordOne: true,
            passwordTwo: true
        }
    },
    onSuccess: (data) => {
        doSomethingWith(data)
    },
    onError: (error) => {
        doSomethingWith(error)
    }
});

pxUserFrontend.showLoginForm({
    containerElement: 'pxUserLogin',
    fallbackTargetUrl: 'https://www.example.com/login',
    fallbackButtonText: 'Login!',
    showLoginWithEip: true,
    state: '7YiroLzzn2tmYdF58XlA6UVLjTbFJQRO',
    labels: {
        buttonText: 'Login!',
        username: 'Email-Address',
        password: 'Password',
        loginWithEntraId: 'Or login with your company\'s Microsoft login',
        emailOrUsername: 'Email/Username',
        continue: 'Continue',
        or: 'Or',
        back: 'Back',
        loginWithMicrosoft: 'Sign in with Microsoft',
        mfaInitTitle: 'MFA Setup',
        mfaInitMessage: 'Scan the QR code with your authenticator app or enter the secret manually.',
        mfaInitCodeLabel: 'Token:',
        mfaInitButtonText: 'Set up',
        mfaVerifyTitle: 'MFA Verify',
        mfaVerifyCodeLabel: 'Enter the code from your authenticator app.',
        mfaVerifyButtonText: 'Verify',
        mfaEnabledTitle: 'MFA Enabled',
        mfaEnabledMessage: 'Multi-factor authentication has been enabled.',
        mfaEnabledButtonText: 'Continue',
    },
    icons: {
        togglePassword: {
            password: true
        }
    },
    onSuccess: (data) => {
        doSomethingWith(data)
    },
    onError: (error) => {
        doSomethingWith(error)
    },
    onResetError: (data) => {
        // credentials accepted, but an additional step (e.g. MFA) is required
        // before login completes — host should reset any previous onError UI
        clearLoginErrorBanner()
    }
});

Notes:

• MFA init, verify, and enable screens are internal challenge screens. Product integrations should configure their labels on showLoginForm; they are not exposed as separate public widget methods.

pxUserFrontend.showActivateUserByActivationCodeForm({
    containerElement: 'pxUserActivateUserByActivationCode',
    showPasswordRules: false,
    showUsernameRules: false,
    labels: {
        activationCode: 'Activation code',
        buttonTextActivationCode: 'Next',
        username: 'Username',
        passwordOne: 'Password',
        passwordTwo: 'Password again',
        buttonText: 'Activate',
    },
    icons: {
        togglePassword: {
            passwordOne: true,
            passwordTwo: true
        }
    },
    fallbackTargetUrl: 'https://www.example.com/activate-user-by-activation-code',
    fallbackButtonText: 'Activate User',
    onSuccessActivationCode: (data) => {
        doSomethingWith(data)
    },
    onErrorActivationCode: (error) => {
        doSomethingWith(error)
    },
    onSuccess: (data) => {
        doSomethingWith(data)
    },
    onError: (error) => {
        doSomethingWith(error)
    }
});

pxUserFrontend.showActivateUserLoginForm({
    token: 'abc123',
    containerElement: 'pxUserActivateUserLogin',
    showPasswordRules: false,
    fallbackTargetUrl: 'https://www.example.com/user-activate',
    fallbackButtonText: 'Activate user and login!',
    labels: {
        buttonText: 'Activate user and login!',
        passwordOne: 'Password',
        passwordTwo: 'Password again',
        mfaInitTitle: 'MFA Setup',
        mfaInitMessage: 'Scan the QR code with your authenticator app or enter the secret manually.',
        mfaInitCodeLabel: 'Token:',
        mfaInitButtonText: 'Set up',
        mfaVerifyTitle: 'MFA Verify',
        mfaVerifyCodeLabel: 'Enter the code from your authenticator app.',
        mfaVerifyButtonText: 'Verify',
        mfaEnabledTitle: 'MFA Enabled',
        mfaEnabledMessage: 'Multi-factor authentication has been enabled.',
        mfaEnabledButtonText: 'Continue',
    },
    icons: {
        togglePassword: {
            passwordOne: true,
            passwordTwo: true
        }
    },
    onSuccess: (data) => {
        doSomethingWith(data)
    },
    onError: (error) => {
        doSomethingWith(error)
    },
    onResetError: (data) => {
        // credentials accepted, additional step required (e.g. MFA) before login completes
        // host should reset any previous onError UI
        clearLoginErrorBanner()
    }
});

Notes:

• MFA init, verify, and enable screens are internal challenge screens. Product integrations should configure their labels on showActivateUserLoginForm; they are not exposed as separate public widget methods.

OIDC-compatible variant of Activate User and Login. Instead of passing tokens to onSuccess, after a successful activation the user is logged in and the browser is redirected to the given redirect_uri with an OIDC authorization code (?code=...&state=...&codeType=auth_code&tenant=...&domain=...). The product exchanges that code at the OIDC token endpoint (PKCE required).

pxUserFrontend.showActivateUserLoginWithOidcForm({
    token: 'abc123',
    containerElement: 'pxUserActivateUserLoginWithOidc',
    client_id: 'your-client-id',
    redirect_uri: 'https://product.example/sso/callback',
    state: 'opaque-product-state',
    scope: 'openid',
    code_challenge: 'dEjftdeZ4C...hbUJUXk',
    code_challenge_method: 'S256',
    onError: (error) => { ... },
});

Notes:

• onSuccess is not used to deliver tokens — after successful activation the user is logged in and the top-level page is redirected to redirect_uri.
• MFA challenges are handled inside the widget, exactly like the classic variant.
• All other parameters (labels, icons, showPasswordRules, fallbackTargetUrl, ...) work as in Activate User and Login.

pxUserFrontend.showPasswordSetByForgotPasswordCodeForm({
    containerElement: 'pxUserPasswordSetByForgotPasswordCode',
    showPasswordRules: false,
    labels: {
        username: 'Username',
        forgotPasswordCode: 'Forgot password code',
        passwordOne: 'Password',
        passwordTwo: 'Password again',
        buttonText: 'Set password',
    },
    icons: {
        togglePassword: {
            passwordOne: true,
            passwordTwo: true
        }
    },
    fallbackTargetUrl: 'https://www.example.com/password-set-by-forgot-password-code',
    fallbackButtonText: 'Set password',
    onSuccess: (data) => {
        doSomethingWith(data)
    },
    onError: (error) => {
        doSomethingWith(error)
    }
});

pxUserFrontend.showPasswordSetByForgotPasswordCodeLoginForm({
    containerElement: 'pxUserPasswordSetByForgotPasswordCodeLogin',
    showPasswordRules: false,
    labels: {
        username: 'Username',
        forgotPasswordCode: 'Forgot password code',
        passwordOne: 'Password',
        passwordTwo: 'Password again',
        buttonText: 'Set password and login',
        mfaInitTitle: 'MFA Setup',
        mfaInitMessage: 'Scan the QR code with your authenticator app or enter the secret manually.',
        mfaInitCodeLabel: 'Token:',
        mfaInitButtonText: 'Set up',
        mfaVerifyTitle: 'MFA Verify',
        mfaVerifyCodeLabel: 'Enter the code from your authenticator app.',
        mfaVerifyButtonText: 'Verify',
        mfaEnabledTitle: 'MFA Enabled',
        mfaEnabledMessage: 'Multi-factor authentication has been enabled.',
        mfaEnabledButtonText: 'Continue',
    },
    icons: {
        togglePassword: {
            passwordOne: true,
            passwordTwo: true
        }
    },
    fallbackTargetUrl: 'https://www.example.com/password-set-by-forgot-password-code-login',
    fallbackButtonText: 'Set password and login',
    onSuccess: (data) => {
        doSomethingWith(data)
    },
    onError: (error) => {
        doSomethingWith(error)
    },
    onResetError: (data) => {
        // credentials accepted, additional step required (e.g. MFA) before login completes
        // host should reset any previous onError UI
        clearLoginErrorBanner()
    }
});

Notes:

• MFA init, verify, and enable screens are internal challenge screens. Product integrations should configure their labels on showPasswordSetByForgotPasswordCodeLoginForm; they are not exposed as separate public widget methods.

OIDC-compatible variant of Password set by forgot password code and login. Instead of passing tokens to onSuccess, after successfully setting the password the user is logged in and the browser is redirected to the given redirect_uri with an OIDC authorization code (?code=...&state=...&codeType=auth_code&tenant=...&domain=...). The product exchanges that code at the OIDC token endpoint (PKCE required).

pxUserFrontend.showPasswordSetByForgotPasswordCodeLoginWithOidcForm({
    forgotPasswordCode: 'abc123',
    username: 'jane.doe@example.com',
    containerElement: 'pxUserPasswordSetByForgotPasswordCodeLoginWithOidc',
    client_id: 'your-client-id',
    redirect_uri: 'https://product.example/sso/callback',
    state: 'opaque-product-state',
    scope: 'openid',
    code_challenge: 'dEjftdeZ4C...hbUJUXk',
    code_challenge_method: 'S256',
    onError: (error) => { ... },
});

Notes:

• onSuccess is not used to deliver tokens — after successfully setting the password the user is logged in and the top-level page is redirected to redirect_uri.
• MFA challenges are handled inside the widget, exactly like the classic variant.
• All other parameters (labels, icons, showPasswordRules, fallbackTargetUrl, ...) work as in Password set by forgot password code and login.

    pxUserFrontend.showConfirmNewEmailForm({
        token: 'abc123',
        containerElement: 'pxUserConfirmNewEmail',
        fallbackTargetUrl: 'https://www.example.com/confirm-new-email',
        fallbackButtonText: 'Confirm New Email',
        onSuccess: (data) => {
            doSomethingWith(data)
        },
        onError: (error) => {
            doSomethingWith(error)
        }
    });

Shown to a customer whose Fulfillment subscription collided with an existing account under the same email address. The customer receives a mail with a token link; the widget checks the state of the correction and renders the form (one field: the alternative address) or a closing sentence when the link is invalid, expired, or already used. Submissions are throttled per token and per client IP.

    pxUserFrontend.showAlternativeEmailForm({
        token: 'ale_abc123',
        containerElement: 'pxUserAlternativeEmail',
        fallbackTargetUrl: 'https://www.example.com/alternative-email',
        fallbackButtonText: 'Send',
        onSuccess: (data) => {
            doSomethingWith(data)
        },
        onError: (error) => {
            doSomethingWith(error)
        }
    });

A hosted page that embeds the Alternative Email widget, for customers whose domain does not offer a page of its own. Which of the two the customer's mail links to is decided by the domain setting mail.placeholders.alternative_email_url: empty means this page, and a URL means the product's own page. Either way the link carries the token.

Tenant and domain are one path segment, tenant:domain. Missing or invalid parameters render the standalone error page with HTTP 400 instead of the widget.

    GET https://user-frontend.api.preprod.pl-x.cloud/vnr:px_teach/alternative-email
        ?token=ale_abc123
        &locale=de
        &css_url=https://example.com/widget-custom.css
        &logo_url=https://example.com/brand/logo.svg
        &favicon_url=https://example.com/brand/favicon.png
        &form_title=Acme%20Konto
        &show_spinner=true

The link in the customer's mail carries only the token, so in practice these theming parameters apply only to a domain that overrides mail.placeholders.alternative_email_url with this page's own address.

The widget auto-detects whether the owner already has an EIP configured and adjusts itself — no change to how you call showEipConfigForm is needed:

• Not configured yet: a blank form (Tenant ID, Client ID, Client Secret, Group ID, optional Secret valid until).
• Already configured: Tenant ID, Client ID and Group ID are prefilled and read-only. The stored secret is never sent to the browser, so Client Secret must always be re-entered to submit — even if you only want to change the validity date. Secret valid until is prefilled with the stored value and stays editable.

Both cases render the same Test/Save buttons and post to the same endpoint — Test validates the entered secret against Entra without persisting anything; Save persists it (creating the EIP config on first save, overwriting it afterwards).

pxUserFrontend.showEipConfigForm({
    token: 'abc123',
    containerElement: 'pxUserEipConfig',
    fallbackTargetUrl: 'https://www.example.com/eip-config',
    fallbackButtonText: 'Save config',
    labels: {
        tenantId: 'Tenant ID',
        clientId: 'Client ID',
        clientSecret: 'Client Secret',
        groupId: 'Group ID',
        secretValidUntil: 'Secret valid until',
        testButtonText: 'Test',
        saveButtonText: 'Save',
    },
    onSuccess: (payload) => {
        const source = payload.source;
        const data = payload.data;

        if (source === 'test') {
            showAlertSuccess('Config is valid. Found ' + data.response.userCount + ' users.');
        } else {
            showAlertSuccess('Config saved');
        }
    },
    onError: (error) => {
        showAlertDanger(`Error: ${error.data.message}, Source: ${error.source}`);
    }
});

{ source: "test", data: { success: true, code: 200, http_code: 200, message: "Tested successfully.", response: { userCount: 450 } } }

{ source: "save", data: { success: true, code: 200, http_code: 200, message: "Credentials stored.", response: null } }

{ source: "test", data: { success: false, code: 422, http_code: 422, message: "Test not successful", response: null }

{ source: "save", data: { success: false, code: 500, http_code: 500, message: "Credentials storing failed.", response: null } }

Secret valid until — optional field, shown in both modes.

• Format: German DD.MM.YYYY (e.g. 25.11.2026).
• Leave empty to clear/skip it; a filled-in date must not be in the past and at most 2 years from today.
• It is not verified against Entra's actual secret expiry — it's stored as declared.
• The submitted value is authoritative: a date sets it, blank clears a previously stored one.
• An invalid value fails client-side validation the same way an empty required field does ({ validation_code: 422, message } via onError), before any request is sent.

Single Sign-On Widget follows OAuth 2.0 Authorization Code Grant. See https://datatracker.ietf.org/doc/html/rfc6749#section-4.1 for more information.

pxUserFrontend.showLoginSsoForm({
    // OAuth 2.0 + PKCE
    client_id: 'abc123',
    state: '7YiroLzzn2tmYdF58XlA6UVLjTbFJQRO',
    redirect_uri: 'https://user-frontend.api.pl-x.cloud/preview/dashboard',
    code_challenge: 'ZjBhZmE1YjQxMzEzYjY4NjQzMjM0YzcyM2I3M2JiMDY2MzQ0NTlmOGY1YjM2ZmZmOTIyNzJhY2I1YTliYjY2ZA',
    code_challenge_method: 'S256',
    // widget configuration
    containerElement: 'pxUserLoginSso',
    fallbackTargetUrl: 'https://www.example.com/login',
    fallbackButtonText: 'Login!',
    showLoginWithEip: true,
    eipLoginRedirectUri: 'https://www.example.com/login',
    selected_account: 'ten:domain:user-id',
    messages: {
        ssoLoginFailed: 'Custom error message must be defined here.'
    },
    labels: {
        buttonText: 'Login!',
        username: 'Email-Address',
        password: 'Password',
        loginWithEntraId: 'Or login with your company\'s Microsoft login',
        emailOrUsername: 'Email/Username',
        continue: 'Continue',
    },
    icons: {
        togglePassword: {
            password: true
        }
    },
    onSuccess: (data) => {
        doSomethingWith(data)
    },
    onError: (error) => {
        doSomethingWith(error)
    },
    onResetError: (data) => {
        // credentials accepted, additional step required (e.g. MFA) before redirect
        // host should reset any previous onError UI
        clearLoginErrorBanner()
    }
});

References

[1]: See https://datatracker.ietf.org/doc/html/rfc6749#section-2.2 for more information about the client_id parameter.

[2]: See https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2 for more information about the redirect_uri parameter.

[3]: See https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.1 for more information about the state parameter.

[4]: See https://datatracker.ietf.org/doc/html/rfc7636#section-4.2 and https://datatracker.ietf.org/doc/html/rfc7636#appendix-A for more information about the code_challenge parameter.

[5]: See https://datatracker.ietf.org/doc/html/rfc7636#section-4.3 for more information about the code_challenge_method parameter.

Open ID Connect Widget follows OIDC 1.0 Authorization Code Grant. See https://datatracker.ietf.org/doc/html/rfc6749#section-4.1 for more information.

pxUserFrontend.showLoginOidcForm({
    client_id: 'abc123',
    state: '7YiroLzzn2tmYdF58XlA6UVLjTbFJQRO',
    redirect_uri: 'https://user-frontend.api.pl-x.cloud/preview/dashboard'
    code_challenge: 'ZjBhZmE1YjQxMzEzYjY4NjQzMjM0YzcyM2I3M2JiMDY2MzQ0NTlmOGY1YjM2ZmZmOTIyNzJhY2I1YTliYjY2ZA',
    code_challenge_method: 'S256',
    // widget configuration
    containerElement: 'pxUserLoginOidc',
    fallbackTargetUrl: 'https://www.example.com/login',
    fallbackButtonText: 'Login!',
    showLoginWithEip: true,
    eipLoginRedirectUri: 'https://www.example.com/login',
    scope: 'openid profile email',
    prompt: 'login',
    labels: {
        buttonText: 'Login!',
        username: 'Email-Address',
        password: 'Password',
        loginWithEntraId: 'Or login with your company\'s Microsoft login',
        emailOrUsername: 'Email/Username',
        continue: 'Continue',
    },
    icons: {
        togglePassword: {
            password: true
        }
    },
    onSuccess: (data) => {
        doSomethingWith(data)
    },
    onError: (error) => {
        doSomethingWith(error)
    },
    onResetError: (data) => {
        // credentials accepted, additional step required (e.g. MFA) before redirect
        // host should reset any previous onError UI
        clearLoginErrorBanner()
    }
});

References

[1]: See https://datatracker.ietf.org/doc/html/rfc6749#section-2.2 for more information about the client_id parameter.

[2]: See https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2 for more information about the redirect_uri parameter.

[3]: See https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.1 for more information about the state parameter.

[4]: See https://datatracker.ietf.org/doc/html/rfc7636#section-4.2 and https://datatracker.ietf.org/doc/html/rfc7636#appendix-A for more information about the code_challenge parameter.

[5]: See https://datatracker.ietf.org/doc/html/rfc7636#section-4.3 for more information about the code_challenge_method parameter.

Single Sign-On Standalone follows OAuth 2.0 Authorization Code Grant. See https://datatracker.ietf.org/doc/html/rfc6749#section-4.1 for more information.

When embedding the widget via PxModUser, set mode: 'standalone' to ensure production uses https://sso-login.pl-x.com.

    OAuth GET https://user-frontend.api.preprod.pl-x.cloud/plx:pxc/oauth2/v2.0/authorize
        ?response_type=code
        &client_id=demo_user_frontend_preview
        &redirect_uri=https%3A%2F%2Fexample.com%2Fdashboard
        &state=vHH_GWJv.-REfY~X
        &code_challenge=ZjBhZmE1YjQxMzEzYjY4NjQzMjM0YzcyM2I3M2JiMDY2MzQ0NTlmOGY1YjM2ZmZmOTIyNzJhY2I1YTliYjY2ZA
        &code_challenge_method=S256
        &css_url=https://example.com/widget-custom.css
        &logo_url=https://example.com/brand/logo.svg
        &favicon_url=https://example.com/brand/favicon.png
        &form_title=Acme%20Login
        &show_spinner=true
        &messages={"ssoLoginFailed":"Custom message here"}
        &labels={"emailOrUsername":"Email-Adresse","buttonText":"Anmelden"}
    OIDC GET https://user-frontend.api.preprod.pl-x.cloud/plx:pxc/oidc/v1.0/authorize
        ?response_type=code
        &client_id=demo_user_frontend_preview
        &redirect_uri=https%3A%2F%2Fexample.com%2Fdashboard
        &state=vHH_GWJv.-REfY~X
        &code_challenge=ZjBhZmE1YjQxMzEzYjY4NjQzMjM0YzcyM2I3M2JiMDY2MzQ0NTlmOGY1YjM2ZmZmOTIyNzJhY2I1YTliYjY2ZA
        &code_challenge_method=S256
        &css_url=https://example.com/widget-custom.css
        &logo_url=https://example.com/brand/logo.svg
        &favicon_url=https://example.com/brand/favicon.png
        &form_title=Acme%20Login%20OIDC
        &prompt=none
        &scope=openid%20profile%20email

    EXAMPLE redirect to: https://example.com/dashboard?code=eyJpdiI6IjBT..yI6IiJ9&state=vHH_GWJv.-REfY~X&mode=

Responses

The endpoint can return two types of responses:

1. Success Response

   • Renders the login widget when all parameters are valid
   • Shows the platform X login form with:
     • Email/Username field
     • Password field
     • Login button
     • Optional EIP login section

2. Error Response

   • Renders an error page when validation fails
   • Shows detailed information about what went wrong
   • HTTP Status Code: 400 Bad Request

Common validation errors:

• Missing required parameters
• Invalid response_type (must be 'code')
• Invalid code_challenge_method (must be 'S256')
• Invalid redirect_uri format
• Mismatched client_id and redirect_uri
• Invalid tenant or domain

Important note: the authorization code appended to the redirect_uri is short-lived and single-use. Exchange it for tokens immediately after the redirect.

After successful login, the user will be redirected to the specified redirect_uri with the authorization code and state parameters.

References

[1]: See https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.1 for more information about the response_type parameter.

[2]: See https://datatracker.ietf.org/doc/html/rfc6749#section-2.2 for more information about the client_id parameter.

[3]: See https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2 for more information about the redirect_uri parameter.

[4]: See https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.1 for more information about the state parameter.

[5]: See https://datatracker.ietf.org/doc/html/rfc7636#section-4.2 and https://datatracker.ietf.org/doc/html/rfc7636#appendix-A for more information about the code_challenge parameter.

[6]: See https://datatracker.ietf.org/doc/html/rfc7636#section-4.3 for more information about the code_challenge_method parameter.

The MFA Setup widget allows a logged-in user to enable or disable multi-factor authentication. If MFA is not enabled, it renders a button to start the setup. On successful setup initiation, the widget automatically proceeds to the MFA initialization flow (QR code/verification step).

pxUserFrontend.showMfaSetupForm({
    token: 'abc123',
    containerElement: 'pxUserMfaSetup',
    labels: {
        mfaSetupTitle: 'MFA Setup',
        mfaSetupSetupButtonText: 'Setup MFA',
        mfaSetupAlreadyEnabled: 'MFA already enabled',
        mfaSetupDisableButtonText: 'Disable MFA',
        mfaSetupUserNotFound: 'User data not found.',
        mfaInitTitle: 'MFA Setup',
        mfaInitMessage: 'Scan the QR code with your authenticator app or enter the secret manually.',
        mfaInitCodeLabel: 'Token:',
        mfaInitButtonText: 'Set up',
        mfaSetupCompleteTitle: 'MFA Setup Complete',
        mfaSetupCompleteHeading: 'MFA is ready',
        mfaSetupCompleteMessage: 'Multi-factor authentication has been enabled.'
    },
    onSuccess: (payload) => {
        // Called on successful actions (e.g., disable completed or flow progressed)
        doSomethingWith(payload)
    },
    onError: (error) => {
        doSomethingWith(error)
    }
});

Notes:

• If the user has MFA disabled, the widget starts the setup and then automatically navigates to the MFA initialization widget.
• If the user already has MFA enabled, the widget renders a button to disable MFA.
• MFA initialization and setup completion are internal screens of this setup flow. Product integrations should configure their labels on showMfaSetupForm; they are not exposed as separate public widget methods.

Lets a logged-in user change their own password: current password, new password, new password again. The new password has to follow the same policy as in the other password widgets, and the policy can be shown in the widget with showPasswordRules. A successful change revokes all refresh tokens of the user, the one of the current session included, so the host has to expect a new sign-in once the current access token expires. No email is sent.

The access token never reaches the browser. The host passes the preferred username of its logged-in user to the widget. The user is identified by username and current password, and the change is only accepted while the user has an active session.

    pxUserFrontend.showChangePasswordForm({
        preferred_username: 'preferredUsernameOfTheLoggedInUser',
        showPasswordRules: true,
        containerElement: 'pxUserChangePassword',
        fallbackTargetUrl: 'https://www.example.com/my-account',
        fallbackButtonText: 'Change password',
        onSuccess: (data) => {
            doSomethingWith(data)
        },
        onError: (error) => {
            doSomethingWith(error)
        }
    });

Notes:

• Users that sign in through an external identity provider (Entra/BFD) cannot change their password here. The change is refused for them (400, code 1006); the host should show its own explanation instead of the widget.
• The password policy cannot be configured per widget; it is the one of the domain.
• The error (#errorMessage) and success (.successMessage) texts inside the iframe come with a default red and green box. Restyle them in your cssUrl stylesheet, either with your own rules or by setting --plx-message-error-color|bg|border and --plx-message-success-color|bg|border on :root.
• Wrong current passwords count on the same attempt limit as the login, so a locked-out user cannot log in either until the limit has passed.

pxUserFrontend.showALS({
    hostUrlsParams: new URLSearchParams(window.location.search),
    redirect_uri: 'https://www.example.com/endpoint',  // <-- The product URL with login widget
    base_uri: 'https://www.example.com/endpoint', // <-- The product URL were the ALS widget is integrated
    ...({}),
    containerElement: 'pxUserAls',
    onSuccess: () => {},
    onError: () => {}
});

The ALS Widget knows which products to connect with each other. When using the ALS widget and start linking user accounts, you will first redirected to the login of the first product. After the user successfully logs into the first product he or she is redirected to the base_uri which must lead back to the page with the ALS Widget, which then recognize the first auth. Then it will redirect to the second product where the user has to sign in also. After the second successful login the user is once again redirected back to the base_uri where the ALS Widget will show him or her a confirmation that the accounts have been connected. There a Button will display which links to the provided redirect_uri. This Button and thus the redirect_uri should Link to a page where the OIDC Login Widget will display. The Login Widget will notice that the user has logged in during the ALS process and log the user into the portal.