Skip to content

Control of your identity infrastructure

Own Your Identity Platform

Connect employees, partners and customers to your applications. Run OpenID Connect and OAuth on your infrastructure, with control over your identity data.

Discuss your requirements

Self-hosted · OpenID Connect & OAuth · Supported by 4tecture

ProAuth AdminTenant · Identity relationships
ProAuth Admin: Alpine Services tenant with local accounts and an OpenID Connect identity provider.
Real ProAuth UI · Product preview · Fictional example data

Different environments. Your identity platform.

For internal systems, software products and digital services, keep identity aligned with the way your organisation operates.

Explore all scenarios and adoption guides

Configuration becomes product experience

One tenant. Multiple identity sources.

A tenant supports multiple configured identity sources. This visual shows two examples—local accounts and corporate identity—as sign-in choices in the fictional Customer Portal application.

One tenant. Multiple identity sources.A: Alpine account in Admin matches Continue with Alpine account. B: Alpine corporate identity matches Continue with Alpine corporate identity. The enlarged Name column comes from the configuration shown above.Configuration / Tenant relationshipsDetail: Name column from the same captureSample app / Customer PortalAABB
Configuration / Tenant relationships
Tenant relationships in ProAuth Admin, open large view
Detail: Name column from the same capture
Alpine account · Alpine corporate identity
Sample app / Customer Portal
Continue with Alpine account · Continue with Alpine corporate identity

A Alpine account

Local sign-in with ProAuth-managed identities.

B Alpine corporate identity

Corporate sign-in with the configured upstream identity provider.

Real ProAuth interfaces · Product preview · Fictional example data. A/B matches the displayed entries; these lines do not represent network traffic.

One identity platform for the applications you rely on.

Connect internal systems, workforce applications and customer-facing services through OpenID Connect and OAuth. ProAuth can use its own user stores or federate sign-in to existing providers such as Microsoft Entra ID.

ProAuth: distinct identity relationshipsApplications connect to ProAuth via OIDC/OAuth. ProAuth can be a client of upstream OIDC providers or authenticate local accounts. Management and persistence are separate relationships.PROAUTH / LOGICAL SERVICE SCOPEApplications / clientsOIDC / OAuth 2.0ProAuthOpenID Provider / Authorization ServerWith upstream providers:Relying party / clientUpstream IdPsMicrosoft Entra ID /other OpenID ProvidersOperations / administrationProAuth-managed user storesLocal identitiesUser-store databasesSQL Server / Azure SQLor PostgreSQLOIDC / OAuth 2.0OIDC federationAdmin UI / Management APILocal account authenticationPersistence

Application integration and federation

ProAuth: distinct identity relationshipsApplications connect to ProAuth via OIDC/OAuth. ProAuth can be a client of upstream OIDC providers or authenticate local accounts. Management and persistence are separate relationships.Applications / clientsOIDC / OAuth 2.0ProAuthOpenID Provider /Authorization ServerWith upstream providers:Relying party / clientUpstream IdPsMicrosoft Entra ID /other OpenID ProvidersOIDC / OAuth 2.0OIDC federation

The same ProAuth platform: management and local accounts

ProAuth: distinct identity relationshipsApplications connect to ProAuth via OIDC/OAuth. ProAuth can be a client of upstream OIDC providers or authenticate local accounts. Management and persistence are separate relationships.PROAUTH / SCOPEOperations / administrationTenants, clients andidentity sourcesProAuthOpenID Provider /Authorization ServerWith upstream providers:Relying party / clientProAuth-managed user storesLocal identitiesUser-store databasesSQL Server / Azure SQLor PostgreSQLAdmin UI / Management APILocal accountsPersistence
Architecture overview, not a request sequence. ProAuth acts as the identity provider for your applications and as an OIDC client of external providers. Applications and APIs remain responsible for token validation and application permissions. The enclosure denotes the logical service, not a network boundary. SCIM provisioning is a separate relationship and is not shown here.
Review protocols and integration

Sovereignty means keeping your choices.

Decide where the platform runs, retain control of its data and choose how it is operated. ProAuth gives those decisions a concrete technical foundation.

Choose where it runs

  • On premises
  • Private cloud
  • Public cloud
One ProAuth platform.Consistent container and Kubernetes tooling. Your operating model.

Deployment choices for the same ProAuth platform, with your choice of infrastructure provider.

Choose where identity runs

Deploy ProAuth on your own infrastructure, in a private cloud or with your chosen public-cloud provider. Container delivery and Kubernetes tooling support a consistent deployment approach across those environments.

Review deployment requirements

Take your platform and data with you

Keep control of ProAuth configuration, user-store databases and encryption keys. When you change hosting providers, these form the basis of a planned platform move, with documented backup and recovery procedures.

See how platform data is preserved

Know who supports the product

4tecture develops ProAuth and provides product support. Basic support covers product defects; escalation packs and Enterprise support plans add configuration and integration assistance.

See support scope and response times

Technical depth. Clear edition boundaries.

Explore all capabilities
Standards / protocols
  • OpenID Connect 1.0
  • OAuth 2.0
  • FAPI 2.0
  • FIDO2 / WebAuthn

FAPI 2.0 Security Profile: opt-in.

Identity sources / federation

ProAuth user stores · Microsoft Entra ID · Upstream OIDC providers

Local accounts and federated sign-in behind one standards-based application integration.

Configuration / operations

Admin UI · Management API · Kubernetes

Manage supported tenant, directory, policy and client settings at runtime, without redeploying ProAuth.

API security

FAPI 2.0 · DPoP · mTLS

For advanced API requirements, FAPI 2.0 is opt-in. DPoP and mTLS token binding require the corresponding client and API integration.

Explore security controls
Enterprise / provisioning

Customer-specific login views · Claims Rule Engine · Audit trails · SCIM

These capabilities require Enterprise. SCIM provisioning is separate from authentication.

Compare ProAuth editions

Plan the licence budget

Starter and Business are annual subscriptions. Enterprise also offers perpetual licensing. Infrastructure, implementation and operation have their own costs.

See licence prices and terms

What integration can look like

ProAuth customer projects inform these implementation patterns. Explore how teams make identity part of their product and operating model.

Meet 4tecture, the team behind ProAuth

Your platform. Clear responsibilities.

Read the installation guide

  1. Map your environment

    Identify representative applications, identity sources, claims and migration constraints, including existing credentials and MFA.

  2. Validate a working integration

    Configure a tenant, connect an application and verify sign-in, permissions, recovery and the edition capabilities you need.

  3. Prepare to operate and evolve

    Clarify monitoring, backups, upgrades and operating responsibilities, including endpoints, keys, dependencies and licence scope for future hosting changes.

Managed operation is agreed separately.

Let’s plan your identity platform.

Tell us about your applications, identity sources and infrastructure plans. We can assess deployment options, editions and a suitable evaluation with you.

Discuss your requirementsExplore the technical documentation

Image detail