Architecture (B2C)

Understanding your application is key to leveraging Login 3.0 effectively. From experience, our most successful customers start with a visualization of their proposed — or in many cases existing — architecture and use this as a basis for reference as they progress. Understanding where your application fits within your organization is also important. Login 3.0 accounts and configurations form the basis for structuring your assets. You may need to integrate with Single Sign-On (SSO), centralized user profile management, or consolidated billing depending on your organization's requirements.

Best Practice

If you have multiple applications and need to leverage SSO, refer to our "How to Implement Single Sign-On" guidance before continuing. Spending time upfront on the architectural landscape pays dividends in the long run. Consider the following while designing your architecture:

• What should the URL look like when Login 3.0 presents a web page to a user?

• How can Login 3.0 be structured to support your Software Development Life Cycle (SDLC)?

• How can you ensure that your Login 3.0 configurations are appropriately aligned with your organizational requirements?

• What needs to be considered if there are other projects in your organization integrating with Login 3.0? Particularly projects targeting specific domains of users (e.g., customer applications versus internal employee tools).

Organizations often serve multiple domains of users — customers, employees, and affiliates are the most common, with typically little to no crossover. Partitioning within a domain (e.g., separating customer groups using different products) may also be necessary. Login 3.0 provides mechanisms to segregate your users and related configurations. Provisioning and configuring these appropriately ensures better scalability and manageability.

Best Practice

Consider all existing and future projects when designing your Login 3.0 architecture. Additionally, align with your established SDLC processes and procedures. Refer to our SDLC support guidance to structure Login 3.0 configurations effectively.

For customer-facing applications, OpenID Connect (OIDC) is the most frequently used protocol. OIDC relies on web-based workflows with browser URLs presented to the user. Client-facing URLs in Login 3.0 can be customized to reflect your branding, enhancing user confidence and experience. Using custom domains is recommended to maintain consistent corporate identity and address potential user confidence concerns early on.

Tenant Provision

Login 3.0 configurations start with an initial setup for your application. While there isn’t a centralized dashboard or configuration API in Login 3.0, all configurations must be requested and handled by the UPBOND team. Proper configuration ensures alignment with your organization’s requirements.

Naming conventions are important; configuration names cannot be changed or reused once deleted. Ensure you finalize naming conventions before setup.

Consider the following when setting up Login 3.0 for production:

• Determine isolation levels for different user domains.

• Evaluate branding requirements to ensure configurations align with your corporate identity.

• Plan for growth, ensuring scalability of configurations.

Custom Domains

When setting up Login 3.0, URLs for accessing endpoints will typically follow a standard structure. Custom domains (e.g., login.mycompany.com) are highly recommended for:

• Supporting branding requirements.

• Enhancing security by reducing phishing risks.

Using custom domains also ensures user confidence by presenting URLs that align with your organization’s identity. Early implementation of custom domains during development ensures consistency across environments.

Best Practice

Create a custom domain for each Login 3.0 environment, including development, to ensure seamless testing and deployment. A centralized domain strategy for authentication across multiple products or service brands provides a consistent user experience and simplifies management.

SDLC Support

Aligning Login 3.0 configurations with your SDLC ensures better integration and testing. Here is a recommended layout for environments:

Environment	Configuration Name	Description
Development	company-dev	Shared environment for development work
QA/Testing	company-qa	Environment for formal testing of changes
Production	company-prod	Production environment

In some cases, creating additional sandbox environments (e.g., company-sandbox1) for testing deployment scripts or new features without affecting development is recommended.