Embed login or registration forms securely on your site
Use Logto authentication parameters to embed sign-up or sign-in forms or buttons directly anywhere on your website. Appropriately integrate authentication into your product context while maintaining robust security standards, leading to increased registration conversion rate.
RanProduct & Design
Stop wasting weeks on user auth
Launch secure apps faster with Logto. Integrate user auth in minutes, and focus on your core product.
OpenID Connect Fundation:
In OpenID Connect (OIDC), browser redirects to an Identity Provider (IdP) are a key part of the authentication process. This happens because the Relying Party (RP) outsources the user authentication to an IdP. Once the user provides credentials to the IdP, it returns tokens (like ID and access tokens) back to the RP through the browser. This redirect mechanism ensures that sensitive user credentials are only handled by the IdP, not the RP.
According to the criterion of OIDC, users must be redirected to an Identity Provider (IdP) to securely complete authentication. This ensure sensitive credentials are handled by the IdP, not the application (RP). Non-redirect sign-in can expose user credentials, making them vulnerable to attacks like credential theft, phishing, or session hijacking.
When using OIDC-based Logto, users are redirected to a secure, verified Logto domain to complete the sign-in process. However, many customers want to embed login or sign-up widgets directly on their site, known as “embedded sign-in”. This is a common practice to enhance user coversion by blending email sign-up forms or social login buttons into the site context.
Is embedded sign-in and redirect sign-in in conflict? — Not at all. They comlement each other in the authentication flow.
Many websites display a simple email input and sign-up button (e.g., "Sign Up," "Get Started," or "Free Trial") prominently on the homepage. After submitting their email, users are redirected to a new page to continue the regisration process.
For blogs or content sites, anonymous users can browse some content but are encouraged to sign in for full access. Sign-up forms often appear next to or below the content.
Example:
Medium: Displays a sign-up prompt when a user wants to read the full article.
X (Twitter): Prompts users to sign up to access personalized timelines and features.
In these examples, only the initial sign-up options (email input or social login buttons) are embedded. The user is then redirected to the IdP for secure authentication. Since both Medium and X act as their own IdPs, they handle authentication through modals rather than redirects, providing a similar user experience in both cases.
Use Logto’s authentication parametersdirect_sign_in , first_screen , and login_hint to implement embedded sign-up or sign-in. Here are two best practices:
Display social login buttons (e.g., Google, Facebook, Apple) or enterprise login buttons (e.g., Google Workspace, Azure AD, Okta) on your site and redirect users directly to the relevant provider. Supported formats include:
The current supported formats are:
social:<idp-name> (Use a social connector with the specified IdP name, e.g. social:google)
sso:<connector-id> (Use the specified enterprise SSO connector, e.g. sso:123456)
Apart from skipping to third-party identity providers (e.g., Google or Facebook login), other authentication methods must be redirect to Logto’s sign-in screen to continue. Essentially, all authentication flows require a redirect — either to a third-party IdP or to Logto as your first-party IdP.
This first_screen parameter allows you to customize the first screen that users see when they start the authentication process. The value for this parameter can be:
sign_in: Allow users to directly access the sign-in page.
register: Allow users to directly access the registration page.
single_sign_on: Allow users to directly access the single sign-on (SSO) page.
identifier:sign_in: Allow users to direct access a page that only display specific identifier-based sign-in methods to users.
identifier:register: Allow users to direct access a page that only display specific identifier-based registration methods to users.
reset_password: Allow users to directly access the password reset page.
As mentioned ealier, you cannot collect users’ password or email/SMS verification codes directly on your website. These must be handled and verified by the IdP.
However, you can collect users’ email addresses or phone numbers as identifiers and pass them along when redirecting to the appropriate first screen (e.g., register or identifier:register). To achieve this, use the login_hint parameter to send the identifier from your website to Logto’s sign-in screen. The URL might look like this: https://auth.example.com/identifier:[email protected].
By leveraging Logto’s direct_sign_in, first_screen, and login_hint parameters, you can easily embed sign-up and sign-in forms on your website, ensuring a secure, friendly user experience while maximizing user conversion.
