Skip to main content

External Auth Embedding

Integration model for external users authentication​

Introduction​

This integration model is useful when a customer has a central authentication system and wants that system to remain the source of truth, allowing users to access their publica.la account using their existing credentials. The integration consists of a UI where users provide their credentials and a server side component that communicates with the external system, validates the account and proceeds by authenticating the user into publica.la. The UI can be set up to match the look and feel of the customer, thus providing a seamless user experience.

The technical difference between this integration model and others, such as Auth Token, is that in this one the authentication flow is initiated by the user from inside a publica.la hosted UI. And, additionally, this one can be embedded into our mobile apps.

General considerations​

  • These integrations are tailored to each customer, requiring collaborative effort.
  • Authentication is initially performed per user login. External system failures may disrupt this process.
  • A unique identifier is required for linking users across platforms.

Technical Requirements​

  1. External system integration:

    a. API documentation:

    • The URL of the external server to which the user must be authenticated.
    • Data necessary to authenticate the user, usually a combination of email/username and password.
    • publica.la side data validations, if necessary we can pre validate the user information before hitting the external API. This can be useful in case all usernames or emails follow specific criteria, like a company domain or prefix.

    b. Successful responses must include a unique user identifier that will be used to link it in our platform.

    c. Unsuccessful responses:

    • Possible error codes and their responses: Set of possible response codes and their customized responses for the user.
    • Data response format: Specification of the format and structure in which the server expects to receive the information.

  2. Optional:

    • Additional information available to the user prior to login, such as Terms and Conditions, FAQ, etc.
    • Password reset URL, in case there is an address to which we should direct the user so they can reset their password.

  3. Design

    • Provide the design and all necessary resources (images, colors, styles, fonts) to implement the login UI.