English
  • embedded login
  • direct sign-in
  • first screen
  • sign-in experience
  • authentication parameters

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.

Ran
Ran
Product & Design

Redirect vs. Non-redirect vs. Embedded sign-in

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.

Use cases for embedded sign-in

Here are a few examples to illustrate how embedded sign-in can be securely implemented:

Case 1: Embed email sign-up field on homepage

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.

Examples:

  • Stripe: “Start now with an email address”

Stripe embedded login.png

Coinbase embedded login.png

Case 2: Embed all sign-up options beside content

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.

Medium embedded login.png

  • X (Twitter): Prompts users to sign up to access personalized timelines and features.

Twitter embedded login.png

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.

How to embed sign-up options on your website?

Use Logto’s authentication parameters direct_sign_in , first_screen , and login_hint to implement embedded sign-up or sign-in. Here are two best practices:

Authentication parameters for embedded login.png

Direct sign-in

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)

Learn more in the Direct sign-in section of Logto Docs.

First screen

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.

Learn more in the First screen section of Logto Docs.

Logto login first screen.png

Login hint

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].

For more details, refer to the Authentication Request of OIDC specs.

Conclusion

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.

Try Logto Cloud for free