Bridge for header-based authentication

The Strivacity Bridge for header-based authentication modernizes your customer identity strategy while maintaining support for legacy applications. This on-premises component enhances sites that utilize header-based authentication with additional authentication and authorization capabilities.

The Bridge functions as a reverse proxy, mediating between the browser and the application’s web server. It applies authentication and authorization policies via HTTP headers, configurable on a per-URL-path basis. For each path, you can specify necessary authentication, methods, and scopes.

Configuration management is centralized through the Strivacity Admin Console, eliminating the need for direct access to the on-premises component to modify policies.


  • Intercept web traffic to enforce authentication and authorization policies for each URL path.
  • Specify required authentication for each URL path.
  • Define supported methods for each path (e.g., GET, POST, DELETE, PUT).
  • Set custom scopes required for accessing resources.
  • Implement custom HTTP security headers.

Header-based authentication and its origins

Header-based authentication is a method widely used in Web Access Management (WAM) where user credentials are passed through HTTP headers during a web session. This approach was particularly prevalent in legacy systems and enterprise environments, where integration with web servers and identity management systems like CA Siteminder allowed for secure and straightforward user access control. By leveraging HTTP headers, applications could authenticate users without direct handling of login credentials, thus enhancing security and simplifying the authentication process. Header-based authentication provides a solid foundation for securing web applications but often requires integration with modern identity solutions to meet current security standards and user experience expectations.

Strivacity’s enhancement with OIDC-based federation

Strivacity modernizes traditional header-based authentication systems OIDC (OpenID Connect)-based federation. By integrating OIDC, Strivacity enables seamless identity verification across different systems and platforms, enhancing both security and user experience.

With the Strivacity bridge component acting as a reverse proxy, it intercepts HTTP traffic and injects additional headers into the HTTP request after performing OIDC-based authentication, thus controling authentication and authorization.This allows organizations to upgrade their legacy systems without extensive modifications. This capability not only extends the life of existing applications but also provides a path towards adopting more secure and flexible identity management practices that support a wide range of authentication mechanisms.

How to set up

On-premises component

The Bridge is containerized for deployment in Kubernetes, Docker, or similar environments. Deploying requires a brand to provide the Bridge access to a REDIS cluster to facilitate on-premises session storage.

The Bridge can either be set up to perform as the reverse proxy, or use a brand's existing reverse proxy.

Strivacity bridge as the reverse proxy

Diagram of Strivacity as the reverse proxy

Strivacity Bridge as the reverse proxy

Strivacity bridge using a brand's existing reverse proxy

Diagram depicting Strivacity Bridge deployed using a brand's own reverse proxy

Bridge deployed using a brand's existing reverse proxy

Your technical account manager will deliver, and can assists and arrange support for, the installation of the on-premises Bridge component. Afterwards brand admins can manage access policies directly from the Strivacity Admin Console.

Configure the sites

Once the on-premises component has been successfully configured, you can now begin setting up authorization scopes and policies via the Strivacity admin console. The process is as follows:

  • Develop an API security policy for each site/domain
  • Set the audience to match the host of the Bridge, e.g., for, use
  • Include any necessary scopes, which may be utilized for authorization later.

Connection configuration

Bridge policies

Next, link the previously developed API security policies to the Bridge client.


Configure authentication and authorization rules in an ordered list, which identifies for a given URL pattern (regex) and HTTP method whether customer authentication is required, and if so, what scopes are necessary.

In the example provided:

  • CSS files are accessible without authentication.
  • JS files are accessible without authentication.
  • Access to paths under /admin/ requires authentication and an admin scope.
  • Access to paths under /support/ requires authentication and a support scope
  • All other paths require authentication.

This ordered list prioritizes matching rules, so a request for /admin/css/main.css would not require authentication because it matches the first rule.


A default rule exists to reject any request that does not match any configured rule.

Upstream URLs

Configure multiple upstream URLs per site. Both HTTP and HTTPS schemes are supported, and a custom port can be specified if necessary.

Security headers

For each request sent to the upstream servers, the Bridge can append custom headers derived from the ID token's claims. This includes claims provided by our dialect or additional values added to the ID token with the Before ID Token Generation hook.