Product Designer
Authentication UX
2024
Three fragmented login systems. One unified authentication layer
A client operating three separate websites had three separate login systems, each with its own registration flow, its own data model, and its own compliance gaps. The existing pop-up authentication was fast but insecure, non-compliant with LGPD and GDPR, and impossible to scale. The project was to design a unified identity layer built on Keycloak, with SSO across all three properties and integration with VTEX.
AU
Australian market, payment norms specific to context
1
Critical moment: checkout is the highest drop-off point in any purchase flow
Shipped
Implemented by client according to spec and timeline
Product Designer
Authentication UX
2024
Three fragmented login systems. One unified authentication layer
A client operating three separate websites had three separate login systems, each with its own registration flow, its own data model, and its own compliance gaps. The existing pop-up authentication was fast but insecure, non-compliant with LGPD and GDPR, and impossible to scale. The project was to design a unified identity layer built on Keycloak, with SSO across all three properties and integration with VTEX.
AU
Australian market, payment norms specific to context
1
Critical moment: checkout is the highest drop-off point in any purchase flow
Shipped
Implemented by client according to spec and timeline
What happens when three products share no infrastructure
The client's business had grown through three separate digital products, each built independently. Each had its own user base, its own login system, and its own account data. For users who interacted with more than one property, that meant three separate accounts, three separate passwords, and three separate registration flows.
The existing authentication was a pop-up login: fast to open, minimal friction, no validation beyond email and password. It worked in the sense that users could register in seconds. It failed on every other dimension that mattered at scale: security, compliance, brand consistency, and the ability to connect user behaviour across the three properties for analytics or personalisation.
The immediate trigger for the project was a compliance review. Brazil's LGPD (Lei Geral de Proteção de Dados) and the EU's GDPR both require explicit data processing consent at registration, documented audit trails, and the ability to fulfill data deletion requests. The existing pop-up system had none of these mechanisms. The risk was legal, not theoretical.
Why Keycloak specifically
Keycloak is an open-source Identity and Access Management platform (now maintained by Red Hat) that supports OpenID Connect, OAuth 2.0, and SAML 2.0. It provides SSO out of the box, has built-in consent management for GDPR/LGPD compliance, and integrates with VTEX through standard OAuth flows. The client needed an IAM system that could serve all three properties with a single user store. Keycloak was the architecturally correct choice. The design challenge was making an enterprise IAM system feel like a consumer product.
What was broken in the existing system
01
Security: no validation on account creation. The pop-up system allowed registration with no email verification, no CAPTCHA, and no duplicate detection.
The result was a user database with a significant proportion of fake or duplicate accounts, which degraded personalisation and inflated user metrics.
02
LGPD and GDPR non-compliance. No explicit consent mechanism at registration. No audit log of data processing events. No self-service data deletion.
Each of these is a mandatory requirement under both frameworks. The exposure was active, not hypothetical.
03
Three separate user stores with no connection. A customer who shopped across two of the three properties had no shared identity. Loyalty data, order history,
and preferences were siloed. The business couldn't offer cross-property personalisation or unified account management.
04
Brand fragmentation at the login step. Each property had styled its pop-up independently. Users who accessed multiple properties encountered different visual
experiences at the authentication moment, with no signal that these were related products from the same company.
05
No scalability path. The pop-up system was built as a standalone module with no interface for third-party integrations. The VTEX e-commerce integration the
business needed required OAuth 2.0, which the existing system couldn't provide.
Mapping the existing flows and the competitive landscape
The research phase had two components: mapping what the existing flows actually looked like for users, and benchmarking competitors who had already implemented Keycloak at scale.
The user flow mapping covered three distinct journeys across each of the three properties: new user registration, returning user login, and social login. Mapping nine flows revealed that the inconsistencies were more significant than assumed. Not just visual inconsistencies, but structural ones: the registration sequence differed by property, the error states were handled differently, and the social login paths had different friction levels depending on which property you were on.
Competitor
Competitor
Keycloak
Dedicated login page
Carrefour
Yes
Yes
Yes
Stix
Yes
Yes
Yes
Santander Esfera
Yes
Partial
Yes
Client (existing)
No
No
No
The benchmark finding was direct: every major competitor in the same segment had already made the transition to Keycloak with dedicated login pages. This meant the client's pop-up system was below the market standard, not at it. Users who had accounts with Carrefour, Stix, or Santander Esfera had already been trained to expect a dedicated authentication page as the signal of a secure system. The client's pop-up was reading as less credible by comparison.
Key insight from the flow mapping
The fastest path through the existing registration flow was 4 steps. The most common path, accounting for field validation errors and the need to re-enter data, was 7 to 9 steps. Users who hit a validation error in the pop-up frequently closed it and tried again from the beginning rather than correcting the specific field. The pop-up's perceived speed advantage over a dedicated page was illusory for the majority of users.
What shaped the design
Keycloak theming via FreeMarker templates: structured customisation within platform parameters
VTEX OAuth 2.0 integration requirements
Three brand identities to accommodate within one shared authentication experience
LGPD consent mechanism must be surfaced at account creation, not buried in terms
Social login: Google and Meta, both requiring specific redirect flow handling
Existing user base: migration path required for accounts already in the legacy system
The most technically specific constraint was Keycloak's theming system. Keycloak allows full HTML/CSS customisation of authentication pages via FreeMarker templates, which gives significant design control but requires understanding which elements are rendered by Keycloak's engine vs. which can be freely styled. The design had to work with this architecture, not around it.
The three-brand constraint was architecturally interesting. Each property had its own visual identity. Keycloak supports realm-level theming, which means each property could have its own styled login page sharing the same underlying Keycloak instance. The design system had to establish shared structural patterns (layout, interaction states, error handling) that could be branded per-property without rebuilding the experience from scratch for each one.
Four decisions that defined the system
Dedicated login page instead of pop-up, with explicit rationale for the client
The pop-up had been the existing pattern and the client had concerns about losing the speed advantage. The design case for the dedicated page was made on three grounds: compliance (LGPD/GDPR consent requirements need a persistent, scrollable page, not a fixed-height overlay), security perception (every competitor in the benchmark used a dedicated page as a trust signal), and actual completion rate (the flow mapping showed the pop-up's speed advantage was marginal in practice once error recovery was included).
The dedicated page also enabled something the pop-up could not: a clear, branded SSO entry point. When a user authenticates once, they're signed in across all three properties. That value proposition requires a moment of explicit recognition, which a pop-up doesn't give the space to communicate.
Shared structural components, per-realm brand application
Three properties, one Keycloak instance, three visual identities. The solution was to define the design system in two layers: structural (layout grid, interaction states, error handling, field anatomy, consent copy placement) and presentational (colour tokens, typography, logo, button style). The structural layer is identical across all three realms. The presentational layer is applied per-realm via Keycloak's theme variables.
This meant the LGPD consent mechanism, the email verification flow, the password reset journey, and the social login states were designed once and worked the same way on all three properties, while each property retained its own visual identity.
Shared across all realms
Layout structure, field order, validation states, error messages, consent copy, social login placement, password requirements display.
Per-realm customisation
Colour tokens, typography, logo, button style, background treatment, imagery.
LGPD consent surfaced inline, not in a terms checkbox
The legally sufficient approach would have been a checkbox at the bottom of the registration form: "I agree to the Terms of Service and Privacy Policy." This satisfies technical compliance but fails the spirit of LGPD, which requires that consent be freely given, specific, informed, and unambiguous.
The design surfaced the data processing consent as a named, labelled step in the registration flow, not a buried checkbox. Users see explicitly what data is being collected, why, and what they're agreeing to, before they complete registration. This is both better compliance practice and better UX: users who understand what they're agreeing to are less likely to dispute it later, and the explicit step signals trustworthiness to users who have been burned by opaque data practices.
Progressive validation with inline feedback, not end-of-form errors
The existing pop-up failed fields only after submission, with a generic error at the top of the form. Given that the flow mapping showed most user friction came from re-entry after errors, the new system validated progressively: fields confirm on blur, the password strength indicator updates in real time, and email format validation fires immediately rather than at submit.
This is particularly important for the email validation step, which Keycloak uses as the primary identifier. Users who enter a mistyped email and complete the full registration flow before discovering the error represent a significant support cost. Catching the format error at the field level eliminates that path.
What the project delivered
Stakeholder approval
The complete design proposal received full sign-off from the client for implementation. The business case, compliance rationale, and technical feasibility were all validated.
LGPD/GDPR compliance path
The consent mechanism and data processing disclosure design resolved the compliance gaps identified in the audit. Legal review confirmed the approach met both framework requirements.
Unified design system for authentication
Structural components designed once, applicable across three branded realms. Reduced implementation work and established consistency across properties for the first time.
VTEX integration spec
OAuth 2.0 flow documented end-to-end, covering the authentication handoff between Keycloak and VTEX for the e-commerce integration the client required.
What I specifically did
Mapped all existing authentication flows across the three properties (registration, login, social login) and identified both visual and structural inconsistencies between them
Ran the competitive benchmark of Carrefour, Stix, and Santander Esfera, establishing that the client's pop-up system was below market standard and building the case for the dedicated page transition
Designed the two-layer system: shared structural components and per-realm brand application, enabling one design to serve three branded properties without rebuilding each
Designed the LGPD/GDPR consent mechanism as an explicit, named step in the registration flow, reviewed against both frameworks for compliance adequacy
Produced the high-fidelity prototype covering the full registration and login flows, including all validation states, error recovery paths, and social login integration
Documented the VTEX OAuth 2.0 integration flow and the Keycloak realm configuration requirements in the engineering handoff spec
Presented the full proposal to stakeholders, securing implementation approval
What this project is about, at a deeper level
Authentication UX is one of the most neglected areas of product design. It sits at the intersection of security engineering, legal compliance, and user experience, which means it gets owned by none of them. Engineers treat it as a configuration task. Legal treats it as a checkbox exercise. Design gets called in when everything else is already decided.
The interesting work in this project was upstream: establishing that the problem wasn't "make the login look better" but "the entire authentication architecture is creating legal, security, and user experience debt simultaneously." Getting that reframe accepted was more consequential than any individual screen decision.
For future projects of this type, I'd instrument the existing flow before starting the redesign. The flow mapping I did was qualitative. Having completion rate data, error type frequency, and drop-off points by device type would have made the case for the dedicated page even stronger and given clearer success criteria for the implementation.
What was broken in the existing system
01
Security: no validation on account creation. The pop-up system allowed registration with no email verification, no CAPTCHA, and no duplicate detection.
The result was a user database with a significant proportion of fake or duplicate accounts, which degraded personalisation and inflated user metrics.
02
LGPD and GDPR non-compliance. No explicit consent mechanism at registration. No audit log of data processing events. No self-service data deletion.
Each of these is a mandatory requirement under both frameworks. The exposure was active, not hypothetical.
03
Three separate user stores with no connection. A customer who shopped across two of the three properties had no shared identity. Loyalty data, order history,
and preferences were siloed. The business couldn't offer cross-property personalisation or unified account management.
04
Brand fragmentation at the login step. Each property had styled its pop-up independently. Users who accessed multiple properties encountered different visual
experiences at the authentication moment, with no signal that these were related products from the same company.
05
No scalability path. The pop-up system was built as a standalone module with no interface for third-party integrations. The VTEX e-commerce integration the
business needed required OAuth 2.0, which the existing system couldn't provide.
Mapping the existing flows and the competitive landscape
The research phase had two components: mapping what the existing flows actually looked like for users, and benchmarking competitors who had already implemented Keycloak at scale.
The user flow mapping covered three distinct journeys across each of the three properties: new user registration, returning user login, and social login. Mapping nine flows revealed that the inconsistencies were more significant than assumed. Not just visual inconsistencies, but structural ones: the registration sequence differed by property, the error states were handled differently, and the social login paths had different friction levels depending on which property you were on.
Competitor
Competitor
Keycloak
Dedicated login page
Carrefour
Yes
Yes
Yes
Stix
Yes
Yes
Yes
Santander Esfera
Yes
Partial
Yes
Client (existing)
No
No
No
The benchmark finding was direct: every major competitor in the same segment had already made the transition to Keycloak with dedicated login pages. This meant the client's pop-up system was below the market standard, not at it. Users who had accounts with Carrefour, Stix, or Santander Esfera had already been trained to expect a dedicated authentication page as the signal of a secure system. The client's pop-up was reading as less credible by comparison.
Key insight from the flow mapping
The fastest path through the existing registration flow was 4 steps. The most common path, accounting for field validation errors and the need to re-enter data, was 7 to 9 steps. Users who hit a validation error in the pop-up frequently closed it and tried again from the beginning rather than correcting the specific field. The pop-up's perceived speed advantage over a dedicated page was illusory for the majority of users.
What shaped the design
Keycloak theming via FreeMarker templates: structured customisation within platform parameters
VTEX OAuth 2.0 integration requirements
Three brand identities to accommodate within one shared authentication experience
LGPD consent mechanism must be surfaced at account creation, not buried in terms
Social login: Google and Meta, both requiring specific redirect flow handling
Existing user base: migration path required for accounts already in the legacy system
The most technically specific constraint was Keycloak's theming system. Keycloak allows full HTML/CSS customisation of authentication pages via FreeMarker templates, which gives significant design control but requires understanding which elements are rendered by Keycloak's engine vs. which can be freely styled. The design had to work with this architecture, not around it.
The three-brand constraint was architecturally interesting. Each property had its own visual identity. Keycloak supports realm-level theming, which means each property could have its own styled login page sharing the same underlying Keycloak instance. The design system had to establish shared structural patterns (layout, interaction states, error handling) that could be branded per-property without rebuilding the experience from scratch for each one.
Four decisions that defined the system
Dedicated login page instead of pop-up, with explicit rationale for the client
The pop-up had been the existing pattern and the client had concerns about losing the speed advantage. The design case for the dedicated page was made on three grounds: compliance (LGPD/GDPR consent requirements need a persistent, scrollable page, not a fixed-height overlay), security perception (every competitor in the benchmark used a dedicated page as a trust signal), and actual completion rate (the flow mapping showed the pop-up's speed advantage was marginal in practice once error recovery was included).
The dedicated page also enabled something the pop-up could not: a clear, branded SSO entry point. When a user authenticates once, they're signed in across all three properties. That value proposition requires a moment of explicit recognition, which a pop-up doesn't give the space to communicate.
Shared structural components, per-realm brand application
Three properties, one Keycloak instance, three visual identities. The solution was to define the design system in two layers: structural (layout grid, interaction states, error handling, field anatomy, consent copy placement) and presentational (colour tokens, typography, logo, button style). The structural layer is identical across all three realms. The presentational layer is applied per-realm via Keycloak's theme variables.
This meant the LGPD consent mechanism, the email verification flow, the password reset journey, and the social login states were designed once and worked the same way on all three properties, while each property retained its own visual identity.
Shared across all realms
Layout structure, field order, validation states, error messages, consent copy, social login placement, password requirements display.
Per-realm customisation
Colour tokens, typography, logo, button style, background treatment, imagery.
LGPD consent surfaced inline, not in a terms checkbox
The legally sufficient approach would have been a checkbox at the bottom of the registration form: "I agree to the Terms of Service and Privacy Policy." This satisfies technical compliance but fails the spirit of LGPD, which requires that consent be freely given, specific, informed, and unambiguous.
The design surfaced the data processing consent as a named, labelled step in the registration flow, not a buried checkbox. Users see explicitly what data is being collected, why, and what they're agreeing to, before they complete registration. This is both better compliance practice and better UX: users who understand what they're agreeing to are less likely to dispute it later, and the explicit step signals trustworthiness to users who have been burned by opaque data practices.
Progressive validation with inline feedback, not end-of-form errors
The existing pop-up failed fields only after submission, with a generic error at the top of the form. Given that the flow mapping showed most user friction came from re-entry after errors, the new system validated progressively: fields confirm on blur, the password strength indicator updates in real time, and email format validation fires immediately rather than at submit.
This is particularly important for the email validation step, which Keycloak uses as the primary identifier. Users who enter a mistyped email and complete the full registration flow before discovering the error represent a significant support cost. Catching the format error at the field level eliminates that path.
What the project delivered
Stakeholder approval
The complete design proposal received full sign-off from the client for implementation. The business case, compliance rationale, and technical feasibility were all validated.
LGPD/GDPR compliance path
The consent mechanism and data processing disclosure design resolved the compliance gaps identified in the audit. Legal review confirmed the approach met both framework requirements.
Unified design system for authentication
Structural components designed once, applicable across three branded realms. Reduced implementation work and established consistency across properties for the first time.
VTEX integration spec
OAuth 2.0 flow documented end-to-end, covering the authentication handoff between Keycloak and VTEX for the e-commerce integration the client required.
What I specifically did
Mapped all existing authentication flows across the three properties (registration, login, social login) and identified both visual and structural inconsistencies between them
Ran the competitive benchmark of Carrefour, Stix, and Santander Esfera, establishing that the client's pop-up system was below market standard and building the case for the dedicated page transition
Designed the two-layer system: shared structural components and per-realm brand application, enabling one design to serve three branded properties without rebuilding each
Designed the LGPD/GDPR consent mechanism as an explicit, named step in the registration flow, reviewed against both frameworks for compliance adequacy
Produced the high-fidelity prototype covering the full registration and login flows, including all validation states, error recovery paths, and social login integration
Documented the VTEX OAuth 2.0 integration flow and the Keycloak realm configuration requirements in the engineering handoff spec
Presented the full proposal to stakeholders, securing implementation approval
What this project is about, at a deeper level
Authentication UX is one of the most neglected areas of product design. It sits at the intersection of security engineering, legal compliance, and user experience, which means it gets owned by none of them. Engineers treat it as a configuration task. Legal treats it as a checkbox exercise. Design gets called in when everything else is already decided.
The interesting work in this project was upstream: establishing that the problem wasn't "make the login look better" but "the entire authentication architecture is creating legal, security, and user experience debt simultaneously." Getting that reframe accepted was more consequential than any individual screen decision.
For future projects of this type, I'd instrument the existing flow before starting the redesign. The flow mapping I did was qualitative. Having completion rate data, error type frequency, and drop-off points by device type would have made the case for the dedicated page even stronger and given clearer success criteria for the implementation.