How to Authenticate Users at the Edge

When you run web applications at the edge, user authentication becomes a first-class concern. You typically have multiple applications, multiple sites, and multiple user roles – and where common cloud identity providers require continuous connectivity that edge environments cannot always guarantee …

In this post, I’ll show how user authentication can be implemented in a way that works reliably at the edge.

Diagram showing a user accessing an edge web application, highlighting the challenge of authenticating users in edge environments.

The authentication challenge at the edge

Consider a customer running several applications across many edge sites. These applications are accessed by different user types on the local network – for example, customers and service technicians.

Not every user should have access to every application or every site. In practice, this means the user base is partitioned per site, not global.

A straightforward solution is to manage users in a local database per site. But at scale, hundreds or thousands of locations, this quickly turns into an operational nightmare.

A common alternative is Keycloak, which provides both a user database and acts as an OIDC provider for applications. While powerful, this still leaves you with the problem of managing users in each Keycloak instance deployed at the edge.

There is a better way.

Distributed users with Strongbox

Strongbox, the security subsystem of the Avassa Edge Platform, includes a built-in user database.

This database is typically used to authenticate users logging into the Control Tower, but it also supports controlled user distribution. For each user, you explicitly define which edge sites the user is propagated to, ensuring that the relevant user database is available locally at the edge even when no cloud connection is present.

In addition, users can be associated with one or more named policies. These policies become the foundation for fine-grained authorization at the edge.

Keycloak integration with Strongbox

Avassa provides a Keycloak integration that allows Keycloak to delegate user authentication to Strongbox at the edge.

Instead of validating credentials against its own local user store, Keycloak queries Strongbox:

  1. The user authenticates via Keycloak.
  2. Keycloak forwards the authentication request to Strongbox through the Edge Enforcer.
  3. Strongbox validates the user and returns the set of policies associated with that user.
  4. Keycloak maps these policies to groups and OIDC claims.
  5. Applications use these claims to enforce authorization.
Diagram illustrating the authentication flow at the edge using Keycloak and Edge Enforcer to manage user access for edge web applications.

From the user’s perspective, the flow is standard OIDC: the browser is redirected to Keycloak for login. Behind the scenes, authentication and policy resolution happen locally at the edge, without relying on per-site user databases.

Conclusion

By combining Strongbox’s distributed user model with Keycloak’s OIDC capabilities, you get centralized user management with localized enforcement.

Users are defined once, selectively distributed to the right edge sites, and consistently authorized using standard OIDC claims, all without operating and maintaining identity databases at every location.

That’s authentication at the edge, done right.