Logto

repository·master·Indexed 12 days ago

https://github.com/logto-io/logto

An open-source authentication infrastructure for SaaS and AI applications. It provides multi-tenancy, enterprise SSO, and RBAC, simplifying the implementation of OIDC, OAuth 2.1, and SAML. Includes a Management API SDK (@logto/api), an Account Center for user profile and security management, and native social connectors such as Alipay for iOS and Android.

Tokens
257.2K
Snippets
713
Records
1.1K
Agent score
96%

What's inside Logto

  1. Overview of the SAML connector

    master
    The SAML (Security Assertion Markup Language) connector allows Logto to act as a Service Provider (SP), enabling users to sign in to Logto using an external Identity Provider (IdP) such as Okta, OneLogin, or Salesforce. This facilitates federated authentication, allowing users to access Logto resources using their existing enterprise credentials.
  2. Use the OIDC standard connector

    master

    The OIDC connector allows Logto to connect to any social identity provider (IdP) that supports the OpenID Connect protocol. This enables your application to:

    • Add social sign-in buttons to your login page.
    • Link existing user accounts to social identities.
    • Sync user profile information (like names and avatars) from the provider.
    • Access third-party APIs by securely storing tokens in Logto's Secret Vault for automation tasks (e.g., managing Google Calendar events).

    Note: The OIDC connector is a special type of connector in Logto; you can add multiple connectors based on the OIDC protocol.

  3. Use the SMSBao SMS Connector

    master

    The SMSBao SMS Connector is an official Logto connector that integrates with the SMSBao domestic SMS API. It enables end-users to complete verification processes such as login, registration, and password resets via SMS verification codes.

    Prerequisites

    1. SMSBao Account: Register an account at SMSBao official website and complete the necessary account configurations.
    2. SMS Templates: Create and have your SMS templates approved in the SMSBao backend. The template content configured in Logto must match the approved content in SMSBao exactly, using Logto placeholders like {{code}}.

    Limitations

    • Supports domestic SMS only.
    • Does not support balance inquiries, uplink SMS push, international SMS, or voice verification code APIs.
    • SMSBao returns 0 for success; any other return code is treated as a sending error.
  4. What is Machine-to-Machine (M2M) authentication in Logto?

    master

    Machine-to-machine (M2M) authentication is used when an application (rather than a user) needs to communicate directly with resources without UI or user interaction. Common examples include background services that update user data or statistics services that pull order data.

    Logto uses Role-Based Access Control (RBAC). To allow an M2M app to access a resource, you must assign it specific M2M roles. There are two primary use cases:

    1. Accessing the Logto Management API: Requires assigning a role that includes the all permission from the built-in Logto Management API resource.
    2. Accessing your own API resource: Requires assigning roles that include specific permissions defined within your own API resources.
  5. Important requirements for Yunpian SMS templates

    master

    When using the Yunpian SMS connector, adhere to these rules to avoid delivery failures:

    • Template Matching: The template content configured in Logto must be identical to the content approved in the Yunpian console.
    • Variable Syntax:
      • In the Yunpian console, use #code# as the placeholder for the verification code.
      • In the Logto configuration, use {{code}} as the placeholder for the verification code.
    • Signatures: Yunpian automatically adds the default signature based on your API KEY. Do not include the signature manually in the template content you provide to Logto.
    • Testing: Always perform a test before moving to production to ensure the configuration is correct.
  6. Rotate private signing keys with a grace period

    master

    To ensure a smooth transition when rotating private signing keys and prevent downtime or authentication failures for clients with cached JWKS, you can use a grace period.

    During the grace period, the new signing key is marked as Next while the existing key remains Current. Once the period ends, the new key becomes Current and the old one becomes Previous.

    You can configure this via the PRIVATE_KEY_ROTATION_GRACE_PERIOD environment variable or the --gracePeriod CLI option.

    logto rotate-signing-keys --gracePeriod <duration>
  7. Convention for localized strings using msg()

    master

    To maintain consistent translations, follow this convention when using the msg() function:

    • Always provide a human-readable id.
    • Always provide a desc (description) to provide context for translators or LLMs.

    Avoid using msg() with only a string literal.

    // ✅ Good
    msg('Not set', {
      id: 'general.fallback-title',
      desc: 'A fallback title when the title or heading of a component is not provided.',
    })
    
    // ❌ Bad
    msg('Not set')
  8. Understand .NET Core authentication URI terminology

    master

    When integrating Logto with .NET Core authentication middleware, it is important to distinguish between the different URI terms used by .NET Core and Logto to avoid configuration errors:

    Logto Concept.NET Core TermDescription
    Logto redirect URICallbackPathThe URI that Logto redirects the user back to after a successful sign-in.
    Logto post sign-out redirect URISignedOutCallbackPathThe URI that Logto redirects the user to after they have signed out.
    Application redirect URIRedirectUriThe final URI the user is redirected to after the Logto middleware has completed its necessary actions.

    Sign-in Flow Sequence

    1. The user starts the Sign-in path in your application.
    2. The application redirects the user to Logto.
    3. Logto redirects the user back to your application's CallbackPath.
    4. The .NET Core middleware processes the callback and finally redirects the user to the RedirectUri.