Skip to content
Scenario

Keep sign-in local when connectivity matters.

Own the identity services your local applications depend on. Configure an on-premises deployment so its sign-in path can operate without public internet access.

← All scenarios and guides

Illustrative business situation

Sign-in is needed when the internet is unavailable

An operational site uses internal applications throughout the working day. Its team wants people to sign in using locally available identity services, even when the public internet connection is interrupted.

A hypothetical example to explain the approach.

What your team gains

Keep the sign-in path local
Run ProAuth and the identity dependencies required for these applications on site.
Use the accounts that fit
Configure local user stores, a reachable local OIDC provider, or both in one deployment.
Keep a familiar integration
Applications use the same ProAuth protocols and APIs as connected environments.

One local environment, one local sign-in path

Local applications and APIs
OIDC / OAuth
One deployment on your Kubernetes infrastructure

Runtime configuration · APIs · Customisable sign-in

Identity sources can be combined

  • Local accountsProAuth user stores
  • Local enterprise directoryReachable local OIDC provider

Also local: databases, shared services, administration and recovery

Every service required for sign-in, administration and recovery must be locally reachable. A local OIDC provider is optional. No connection to a cloud deployment is required.

Keep local sign-in locally available

For applications that must authenticate during an internet outage, deploy the required identity services and dependencies locally. Use local ProAuth accounts or a reachable local identity provider, with locally available recovery and administration processes.

On-premises Active Directory integration separates sign-in from provisioning: OIDC federation can use ADFS, while the ProAuth Directory Sync component sends directory changes to ProAuth's SCIM endpoint. SCIM requires Enterprise entitlement.

This makes local authentication an explicit architectural choice. Continuity of the complete operational application also depends on its other services.

One deployment, configured for local work

A single ProAuth deployment can serve multiple local applications and combine user stores with reachable local identity providers. Separate installations are an option when isolation or connectivity boundaries require them, not a requirement for combining identity sources.

Custom authentication views can adapt the presentation to different interfaces. Validate the browsers, authenticators and integration available on the devices your users actually use.

Operate for continuity

Configure and validate availability, capacity, backup and recovery for the local deployment. Product updates must be tested with the complete application and deployed according to the release requirements.

Local identity removes the public internet from the configured sign-in path. Availability of the wider application also depends on its other services and the local infrastructure.

The next step

Evaluate the approach in your project.

Trace the complete sign-in and recovery path with public internet access removed. Check every required service, identity source and administrative process.

Discuss your offline requirements