Okta Access Gateway vs SSOGEN: What Each Product Documents

Okta Access Gateway vs SSOGEN is a question of where the pieces live: Okta describes a virtual appliance that works with an Okta org, while SSOGEN is a single gateway program, an agent for Apache and Oracle HTTP Server, and an identity provider. The table sets out what each documents.

Request a Quote

Okta Access Gateway vs SSOGEN compares two ways to put modern sign-in in front of on-premises web apps that cannot do it on their own. Okta Access Gateway and the SSOGEN Gateway both sit between people and those apps.

SSOGEN gives you one gateway program, a Web Agent inside Apache or Oracle HTTP Server, and a complete identity provider.

The table lines up each capability, row by row, and each Okta statement carries its source and the date we read it.

This page does not rank the products and says nothing about pricing or quality. To plan a move, read the Okta Access Gateway alternative page. It covers the order of work.

Capability table

Last compared 2026-10-09. Vendors change their products. “Not described on the pages read” means only that. It does not mean the capability is missing.

Capability	Okta Access Gateway (own documentation, read 2026-10-09)	SSOGEN (own documentation)
What it is	A virtual appliance that protects on-premises apps that do not support federation (Introduction to Access Gateway).	Gateway App Proxy, a reverse proxy, and the Web Agent, a module inside Apache or Oracle HTTP Server.
How it is delivered	A virtual appliance downloaded from the Admin Console of the Okta org and deployed in a virtual environment (same page).	One program, shipped as a container image, Helm chart, RPM or DEB.
App types	Header, SAML, custom web, Kerberos and other apps (same page).	Apps that read identity headers, Kerberos apps and form-login apps through the App Proxy; Oracle application headers through the Web Agent.
Identity to the app	HTTP headers and Kerberos tokens, plus URL-based authentication (same page).	Gateway sends a fixed set of identity headers: user name, email, display name, groups, sign-in strength, application and route. A browser cannot supply its own copy. The Web Agent passes the user name the way Oracle applications read it, or unchanged for other applications.
Kerberos	Listed as a supported app type (same page).	App Proxy requests a Windows ticket for the person with constrained delegation and protocol transition. Runs on the Enterprise Linux RPM or the container image with the Kerberos helper, with an AES keytab.
Form login	Not described on the pages read.	The gateway fills in the login page; each person can use a saved password that SSOGEN stores encrypted and never displays.
Policy	Granular policies based on group membership, IP address location and other factors (same page).	A sign-in policy per application, optionally per hostname, with network-zone conditions (for example, deny or require a second factor when not on a corporate network) and step-up rules.
Identity provider	The Okta org manages apps, users, single sign-on and MFA (same page).	SSOGEN is a complete identity provider, and it also accepts Okta, Entra ID or any SAML or OpenID Connect provider upstream. The Gateway checks that the person is signed in to SSOGEN and that SSOGEN allows them in. The Web Agent also has standalone SAML and OpenID Connect modes for other standards-based providers, which need a license key from SSOGEN.
Non-web applications	Okta states that Access Gateway communicates only with web-based apps (same page).	Secure remote access offers browser SSH, RDP and VNC.
Hostnames	Not described on the pages read.	Routes use exact hostnames, each with its own certificate, and the gateway speaks HTTP/1.1 to browsers.
Operating it	Not described on the pages read beyond the appliance model above.	You enroll the gateway once, group gateways that share configuration and publish signed configuration. Signed configuration that fails verification is refused and the previous revision stays active.
Web server agent	Not described on the pages read.	Web Agent for Apache and Oracle HTTP Server, signing in through SSOGEN or, in standalone mode, through another SAML or OpenID Connect provider.

Two ways to put the check in front of an app

The two products split the job differently. The table shows where each part sits.

	Okta Access Gateway (read 2026-10-09)	SSOGEN
Where users and sign-in are managed	An Okta org that manages users, single sign-on and MFA.	SSOGEN, a complete identity provider.
Where the check runs	A virtual appliance you download from that org and deploy in a virtual environment. In Okta’s description, the org manages and the appliance protects the on-premises apps.	The App Proxy checks that the person is signed in to SSOGEN and allowed in. Only then does it forward the request.
Inside the web server	Not described on the pages read.	If the app sits behind Apache or Oracle HTTP Server, the Web Agent does the same check inside the web server, with no extra hop. After sign-in it sets the user name and other identity values as request headers and Apache environment variables. The app reads those.

Source: Introduction to Access Gateway, read 2026-10-09.

Kerberos on both. Both products list Kerberos.
SSOGEN packages. The Kerberos helper ships on the Enterprise Linux RPM and the container image, so choose one of those for Kerberos routes.
Other packages. On other packages, a Kerberos route answers “unavailable”.
Setup steps. setspn, ktpass and PowerShell are in the Kerberos and form sign-in guide.
Form login. SSOGEN also signs people in to apps that only have a login page. The Okta pages we read do not mention it.

The identity provider question

The two answer this differently.

Okta’s model. Okta describes Access Gateway as working with the Okta org.
SSOGEN’s model. The SSOGEN Gateway signs people in through SSOGEN, and SSOGEN takes Okta as an upstream provider.
Who checks what. Okta checks the password and second factor, and SSOGEN applies its own policy at the Gateway.
No SSOGEN session. In standalone mode, the Web Agent signs people in against another provider with no SSOGEN session at all, as in Oracle EBS with Okta.
Wider picture. See single sign-on software.

Where Okta Access Gateway fits

Okta company-wide. Okta is your identity provider and stays that way, so policies and MFA come from the same org your admins already use.
Policy in one console. You want policies based on group membership, IP address and other factors, managed in the Okta Admin Console with every other app.
Virtual appliance. You prefer a virtual appliance to a program you install yourself.
Okta as the one place. Your Okta admins and Okta policies govern on-premises app access.

When SSOGEN fits

One vendor. You are changing identity providers and want the proxy and the provider from one vendor.
Check inside the web server. Your Oracle EBS, PeopleSoft or JD Edwards app sits behind Apache or Oracle HTTP Server.
More in one gateway. Browser-based remote access to servers, an Outbound Connector for networks that accept no inbound connection, and a Directory Connector.
Your packaging. You want a container, Helm chart, RPM or DEB, not a virtual appliance.

SSOGEN has run in production since 2016, and Microsoft lists it in the Microsoft Entra gallery.

For the exact capabilities, read what the gateway does. To compare approaches, see identity-aware proxy.

Questions people ask

Is SSOGEN a virtual appliance?

No. It is one program you install as a container, Helm chart, RPM or DEB.

Can SSOGEN protect apps without a proxy?

Yes, on Apache and Oracle HTTP Server, with the Web Agent.

Does SSOGEN cover Kerberos apps?

Yes, through the App Proxy. The requirements are in the table.

Which is cheaper?

This page makes no pricing claims.

About this comparison. SSOGEN Corporation prepared this page from Okta, Inc.’s public documentation and web pages, last read on 2026-10-09.

We took care to be accurate, but products, plans and prices change, and we may have misread or missed something, so some statements may be wrong or out of date. This page is for general information only and comes without any warranty.

SSOGEN is not responsible for errors, omissions or decisions made from it. Check the vendor’s own pages and test the products yourself before you decide. If you see a mistake, tell us and we will correct it.

Okta, Okta Access Gateway, Oracle, Oracle HTTP Server, Oracle E-Business Suite, PeopleSoft, JD Edwards, Apache, Windows, Kerberos, Helm and Enterprise Linux are names or trademarks of their respective owners. SSOGEN is an Oracle partner, but Oracle has not reviewed or endorsed this page.

Except for Oracle, the owners named are not affiliated with, endorsed by or sponsored by SSOGEN.

Sources, all read 2026-10-09: Introduction to Access Gateway.