Sign In

Gatey + enterprise federation

Connect WordPress to Existing SAML and OIDC Identity Providers Without Building Separate Login Flows

When an organization already has an identity provider, WordPress should not need a separate custom login system for every provider. Amazon Cognito can act as the federation hub while Gatey brings the resulting sign-in experience into WordPress.

Short answer Configure the existing SAML or OIDC identity provider in Amazon Cognito, then expose it through Gatey on the WordPress frontend. Cognito handles federation and returns the identity context used by the site and protected APIs.

The federation problem

One WordPress site may need to work with several existing identity systems

Enterprise projects often arrive with identity decisions already made. The WordPress integration should fit that environment instead of creating another parallel account system.

Duplication

Separate login flows create separate lifecycle problems

Building a custom WordPress flow for each IdP can duplicate callback handling, user attributes, error states, and account-support logic that already belongs in the identity layer.

Static delivery

Server-side WordPress SSO assumptions do not fit every frontend

If the public site is statically exported, login should not depend on a PHP callback or a WordPress session that only exists on the origin server.

Authorization

SSO authentication still needs a backend authorization model

A successful enterprise sign-in proves identity, but APIs and protected resources still need explicit token, group, scope, or IAM-based authorization rules.

Architecture choice Use Cognito as the federation hub, Gatey as the frontend WordPress integration, and keep backend authorization separate from visual login state.

Federation path

Existing IdP → Cognito → WordPress frontend

Gatey can expose identity providers configured in Cognito, including custom SAML or OIDC providers on supported plans, alongside Cognito-native and social authentication.

Existing enterprise IdP
      |  SAML or OIDC
      v
Amazon Cognito User Pool
      |  federation / account flow / tokens
      v
Gatey Authenticator in visitor browser
      |
      +--> dynamic WordPress frontend
      +--> statically exported WordPress frontend
      +--> protected APIs using validated identity

Identity boundary Cognito can centralize federation, but each backend still needs to enforce authorization. A frontend SSO button or logged-in state is not a substitute for API-side access control.

Implementation

Connect the existing identity provider once, then reuse the Cognito identity path

Keep provider configuration in Cognito and the frontend experience in WordPress.

  1. Configure the provider in Cognito — Add the required SAML or OIDC provider, attribute mappings, domains, callback URLs, and logout URLs to the User Pool configuration.
  2. Configure Gatey — Connect Gatey to the User Pool and enable the required provider buttons or authentication experience in the WordPress frontend.
  3. Test the real frontend domains — Verify sign-in, sign-out, error handling, and redirects on production, staging, and static-export domains rather than testing only on the WordPress origin.
  4. Authorize downstream APIs — Validate Cognito JWT or IAM identity on protected endpoints and map groups or claims only where the application needs them.

When Cognito-centered SSO fits

Good fit

Use this pattern when WordPress must join an existing identity environment

  • The organization already has SAML or OIDC identity providers that frontend users should use.
  • The same identity should work across WordPress, a static frontend, and protected AWS-backed APIs.
  • You want Cognito to centralize federation instead of building separate provider logic inside WordPress.

A simpler SSO plugin may fit

Use a WordPress-native SSO approach when

  • Only wp-admin or one dynamic WordPress site needs SSO.
  • There are no static frontend, API, Cognito, or cross-application identity requirements.
  • The team does not want Cognito to act as the identity broker.

Buyer questions

WordPress SAML and OIDC through Cognito FAQ

Can WordPress use an existing SAML identity provider through Amazon Cognito?

Yes. Configure the SAML provider in Cognito and use Gatey to expose the resulting frontend authentication experience in WordPress.

Can I connect an OIDC identity provider too?

Yes. Gatey can expose custom OIDC providers configured in Cognito on the applicable plan, alongside supported social providers.

Will enterprise SSO still work after static export?

Yes, when the authentication flow is configured for the exported domain. Gatey runs the frontend flow in the browser against Cognito rather than requiring WordPress PHP to maintain the public session.

Does SSO automatically protect my APIs?

No. SSO authenticates the user. Protected APIs still need to validate the Cognito token or IAM identity and enforce the appropriate authorization rules.

WP Suite Gatey

Connect WordPress to your existing identity providers through Cognito

Use one Cognito-centered federation path for frontend WordPress login, static delivery, and protected APIs.

Explore Gatey
Compare SSO approaches