External-only single data center architecture

The external Access Gateway in a one data center architecture representing the components required for protecting web resources using Access Gateway. It extends the single Access Gateway instance architecture by introducing an Access Gateway cluster. In this architecture, a set of applications, referred to as protected web resources, are served to requesting clients using an Access Gateway cluster.

This architecture is designed to meet the following requirements:

  • Secure access to a set of applications - Accessed from the external internet, but housed within an internal network.
  • Provide fault tolerance - Providing additional instances of Access Gateway, as cluster workers, such that if one is unavailable the cluster continues to perform normally.
  • Manage capacity - Providing additional instances of Access Gateway to handle expected load.

Benefits and drawbacks

Benefits Drawbacks
  • Relatively simple installation
  • Provides basic fault tolerance and capacity support
  • Can be expanded with additional workers as required to add additional capacity
  • Load balanced
  • Single data center
  • Pre Access Gateway DMZ based load balancer must support session affinity (sticky sessions)




Component Description
External internet Web clients

Traditional client browser accessing Access Gateway using known as [appN|consumer-app1].example.com URLs.

URLs not shown
URL representing one of the applications an external web client would enter to access one of the applications secured by Access Gateway. Typically all URLs of this nature are served by, and resolve to, the Access Gateway instance.
Okta org

Your Okta org, providing identity services.

Okta org Universal Directory

Okta universal directory, housed within an Okta org, containing users outside other LDAP/AD implementations. Typically these include other customer accounts, partner accounts and more.


External internet to DMZ

Traditional firewall between the external internet and the DMZ hosting Access Gateway.
DMZ Pre Access Gateway load balancer Load balancer for the DMZ based Access Gateway cluster.
Positioned between outside clients and the external use Access Gateway cluster.
Access Gateway Access Gateway cluster, located in the DMZ is used to provide access to applications used by external internet clients.
Typically hosted in a virtual environment such as Amazon Web Services, MS Azure, Oracle OCI or something similar. See Manage Access Gateway deployment.


DMZ to internal firewall

Traditional firewall between DMZ and the internal network.
Internal network Access Gateway admin Access Gateway admin node, in any of the data centers handling configuration, configuration backups, log forwarding and similar activities.
Accessed by administrators within the internal network.
Pre internal Access Gateway load balancer

Load balancer for the DMZ based cluster.
Positioned between internal clients and the internal use cluster.
See Load balancing.

Protected applications
URLs not shown
The set of protected web resources, accessed using the protd-N.internal-example.com URLs. These are the traditional or historic applications which Access Gateway interacts with using the Protected Web Resource field within each application definition.

Other considerations

DNS is typically split between external and internal domains. All external URLs, such as [appN|consumer-app1].example.com, would be served externally and point to the Access Gateway instance. Internal URLs, used by Access Gateway such as [protd-N|consumer-app1].internal-example.com, would be served by internal DNS.

Most architectures forward log events to an external syslog component. Okta strongly recommends that a logging server be configured for all Access Gateway environments. See Configure log forwarders.

Not shown in this architecture are the data centers housing architecture components.
The following is a possible high level breakdowns of where different components are housed.
ComponentData center
External Access Gateway cluster.
Pre external Access Gateway load balancer
Virtual data center 1
Likely AWS, OCI or MSAzure based
Post external Access Gateway load balancePhysical data center 1
Likely co-located with the internal use applications
Pre internal Access Gateway load balancerLikely virtual data center 2
Possibly co-located with either internal applications or internal Access Gateway
Internal Access Gateway clusterVirtual data center 2 (Possibly AWS etc, also possibly VMWare)
External use applications
Internal use applications
Physical data center 1
Internal proxy serverPossibly in Virtual data center 2, likely co-located with other internal servers.

Related topics

Common Access Gateway flows

DNS use

High availability

About Access Gateway prerequisites