diff --git a/docs/end-user-flows/authentication-parameters/README.mdx b/docs/end-user-flows/authentication-parameters/README.mdx index 26ea7b8c031..abca3e87261 100644 --- a/docs/end-user-flows/authentication-parameters/README.mdx +++ b/docs/end-user-flows/authentication-parameters/README.mdx @@ -17,39 +17,63 @@ This is particularly useful when you want to enforce specific sign-in flows for ### Direct sign-up for new users \{#direct-sign-up-for-new-users} - For a targeted registration campaign, you may want to direct new users straight to the sign-up page, bypassing the default sign-in form, to ensure a seamless onboarding experience. +For a targeted registration campaign, you may want to direct new users straight to the sign-up page, bypassing the default sign-in form, to ensure a seamless onboarding experience. - **Use**: [First screen](/end-user-flows/authentication-parameters/first-screen) parameter → `first_screen=register` +**Use**: [First screen](/end-user-flows/authentication-parameters/first-screen) parameter → `first_screen=register` -### Email prefilled sign-up from a subscription link \{#email-prefilled-sign-up-from-a-subscription-link} +### Email prefilled sign-up from homepage \{#email-prefilled-sign-up-from-homepage} - If you're collecting email addresses through a self-hosted subscription form, these parameters allow you to redirect the new subscribers to the sign-up page with email field pre-populated, making it easy for them to complete the registration process. +You often see an email sign-up input field prominently displayed on the homepage hero section, encouraging quick user registration. After users enter their email and click the "Start now" button, these parameters allow you to redirect them to the sign-up page with the email field pre-populated, streamlining the registration process. - **Use**: [First screen](/end-user-flows/authentication-parameters/first-screen) parameter → `first_screen=identifier:sign_up&identifier=email&login_hint=foo@gmail.com` +This approach is also useful for subscription forms or other email collection scenarios where you want to reduce friction in the sign-up flow. + +**Use**: [First screen](/end-user-flows/authentication-parameters/first-screen) parameter → `first_screen=identifier:sign_up&identifier=email&login_hint=foo@gmail.com` + +Embedded email sign-up field on homepage ### Direct password reset link \{#direct-password-reset-link} - For new users who need to set up their new password, send them a direct link and redirect them to the password reset page with the email field prefilled. +For new users who need to set up their new password, send them a direct link and redirect them to the password reset page with the email field prefilled. - **Use**: [First screen](/end-user-flows/authentication-parameters/first-screen) parameter → `first_screen=reset_password` +**Use**: [First screen](/end-user-flows/authentication-parameters/first-screen) parameter → `first_screen=reset_password` ### Instant social login \{#instant-social-login} - If you provide social media sign-in buttons directly on your site, you can use these parameters to skip the default sign-in form and let users authenticate directly with their chosen social provider. +If you provide social media sign-in buttons directly on your site, you can use these parameters to skip the default sign-in form and let users authenticate directly with their chosen social provider. - **Use**: [Direct sign-in](/end-user-flows/authentication-parameters/direct-sign-in#social-sign-in) parameter → `direct_sign_in=social:google` +**Use**: [Direct sign-in](/end-user-flows/authentication-parameters/direct-sign-in#social-sign-in) parameter → `direct_sign_in=social:google` ### Direct SSO sign-in for enterprise customers \{#direct-sso-sign-in-for-enterprise-customers} - For products serving multiple enterprise clients, these parameters allow you to display a dedicated SSO button that signs in users with their specific SSO provider, skipping the universal sign-in form and providing a seamless experience for each organization. +For products serving multiple enterprise clients, these parameters allow you to display a dedicated SSO button that signs in users with their specific SSO provider, skipping the universal sign-in form and providing a seamless experience for each organization. + +**Use**: [Direct sign-in](/end-user-flows/authentication-parameters/direct-sign-in#enterprise-sso) parameter → `direct_sign_in=sso:1234567890` + +### Embedded sign-up form on website or in a dialog - **Use**: [Direct sign-in](/end-user-flows/authentication-parameters/direct-sign-in#enterprise-sso) parameter → `direct_sign_in=sso:1234567890` +For a seamless user experience, you can embed a complete authentication form directly on your website or in a modal dialog, naturally guiding users to sign up or sign in at the right moment. + +- When users click on a social sign-in button (e.g., "Continue with Google"), use the [direct sign-in](/end-user-flows/authentication-parameters/direct-sign-in) parameter to immediately redirect them to the social provider. +- When users enter their email and click the sign-up button, use the [first screen](/end-user-flows/authentication-parameters/first-screen) parameter to redirect them to the sign-up page with the email pre-populated. + +By combining the authentication parameters mentioned above, you can maintain your website's context and branding while leveraging Logto's secure authentication infrastructure, creating a smooth and professional user experience. + +Embedded sign-up form on website or in a dialog ### Custom sign-in methods displayed for different sites \{#custom-sign-in-methods-displayed-for-different-sites} - If you product serves both internal teams and consumers, or different organizations, you can tailor the sign-in experience accordingly. For example: - For internal tools, show only email/username and password sign-in. - For consumer-facing pages, offer all available sign-in options, including Google login. +If your product serves both internal teams and consumers, or different organizations, you can tailor the sign-in experience accordingly. For example: + +- For internal tools, show only email/username and password sign-in. +- For consumer-facing pages, offer all available sign-in options, including Google login. - **Use**: Different [first screen](/end-user-flows/authentication-parameters/first-screen) or [direct sign-in](/end-user-flows/authentication-parameters/direct-sign-in) settings based on website type. +**Use**: Different [first screen](/end-user-flows/authentication-parameters/first-screen) or [direct sign-in](/end-user-flows/authentication-parameters/direct-sign-in) settings based on website type. Continue reading to learn more about the authentication parameters to customize the [first screen](/end-user-flows/authentication-parameters/first-screen) or enable a [direct sign-in](/end-user-flows/authentication-parameters/direct-sign-in) experience for your users. diff --git a/docs/end-user-flows/one-time-token.mdx b/docs/end-user-flows/one-time-token.mdx index fb3298759a4..98a7e65f003 100644 --- a/docs/end-user-flows/one-time-token.mdx +++ b/docs/end-user-flows/one-time-token.mdx @@ -4,10 +4,6 @@ sidebar_position: 5 # Magic link (One-time token) -import Availability from '@components/Availability'; - - - Similar to one-time password (OTP), a one-time token is another passwordless authentication method that can be used to verify a user's identity. The token is valid for a limited period of time, and associated with an email address of the end user. @@ -17,6 +13,26 @@ In such cases, the application can send a "magic link" to your email. And you wi Application developers can use the one-time token to compose a magic link, and send it to the end user's email address. +## Use cases + +Logto supports the following scenarios with magic links: + +- **Invitation-only registration**: For internal tools or AI products in testing phase, you can disable public registration and invite specific users via magic links. +- **Organization member invitation**: For SaaS products, use magic links to invite new members to join an organization, streamlining the onboarding process. +- **Sign-in / Sign-up**: Send a magic link for passwordless sign-in or sign-up via email. + +For example, when you've disabled public registration, you can send a magic link with a one-time token (e.g., `https://yourapp.com/landing-page?type=registrationInvitation&token=YHwbXSXxQfL02IoxFqr1hGvkB13uTqcd&email=user@example.com`) to the user's email to invite them to complete account creation. You can customize the email template in your own email delivery service, such as: + +An email template for invitation only registration + +Currently not supported: + +- Password reset with magic link. +- Using phone number or username as the identifier. + ## One-time token flow \{#one-time-token-flow} Here is the sequence diagram of the authentication flow using one-time token: diff --git a/docs/integrate-logto/README.mdx b/docs/integrate-logto/README.mdx index c90cd012c3c..c4b17ade804 100644 --- a/docs/integrate-logto/README.mdx +++ b/docs/integrate-logto/README.mdx @@ -18,6 +18,8 @@ Start your integration by selecting the solution that best matches your needs: Whether you're building user-facing applications (like web, mobile, or desktop apps) or machine-to-machine (M2M) applications for service-to-service communication, you can quickly implement comprehensive [authentication](/end-user-flows) and [user management](/user-management) features by integrating Logto. +Built on OIDC standards, Logto enables **Omni sign-in** across all your applications. When you integrate multiple applications with Logto, they share the same identity system and authentication methods. This means users can sign in once and seamlessly access all your connected applications with a unified authentication experience. + Find integration guides for your preferred framework or programming language: -## Add OIDC/OAuth apps \{#add-oidc-oauth-apps} +## Add third-party OIDC/OAuth apps \{#add-third-party-oidc-oauth-apps} When you want to enable third-party applications to authenticate with your Logto identity system, you can configure Logto as an [Identity Provider (IdP)](https://auth.wiki/identity-provider). -Logto can be used as an IdP through standard protocols like OAuth, OIDC, and external services can implement "Sign in with Logto" just like "Sign in with Google", allowing their users to authenticate using your Logto user system. +Logto can be used as an IdP through standard protocols like OAuth and OIDC, and external services can implement "Sign in with Logto" just like "Sign in with Google", allowing their users to authenticate using your Logto user system. + +Unlike first-party applications, third-party apps can only request limited permissions. During the authentication flow, users will see a **consent screen** where they can review and approve what data and permissions the third-party app is requesting before granting access. -By creating third-party applications in Logto, you establish secure connections between your identity system and external services. +By creating third-party applications in Logto, you establish secure connections between your identity system and external services while giving your users control over their data sharing.