WordPress SSO with Amazon Cognito and Gatey | Social & Enterprise Login Guide

Learn how to add Single Sign-On (SSO) to WordPress using Amazon Cognito and the Gatey plugin. Step-by-step setup for social logins (Google, Apple, Facebook, Amazon) and enterprise IdPs (OIDC, SAML), plus IAM integration for AWS APIs.

Introduction

Single Sign-On has become a baseline expectation for both end-users and enterprises. Visitors don’t want to create yet another username and password — they expect to log in with Google or Apple in one click. At the same time, companies require secure integrations with their existing identity providers like Azure AD or Okta.

For WordPress, this balance is tricky: the native login system was never designed for modern OAuth/OIDC or SAML flows, and static exports break the default authentication completely.

By combining Amazon Cognito (as the identity hub) with Gatey (as the WordPress integration layer), you can offer seamless social logins for individuals and enterprise SSO for organizations — all while keeping your site secure, scalable, and even compatible with static hosting.

What you’ll learn

How to configure Cognito User Pools, App Clients, and the Hosted UI (domain, callbacks, scopes).
How to connect Social IdPs (Google, Facebook, Apple, Amazon) and Enterprise IdPs (OIDC/SAML).
How to map attributes for clean WordPress profiles and role mapping.
How to wire everything into WordPress with Gatey (User Pools, General, Social & Custom Providers).
(Optional) How to enable IAM so Cognito users can call AWS-hosted APIs from the browser.

Pre-requisites

Gatey plugin available in WordPress.
• If not installed: Plugins → Add New → Gatey → Install and activate.
• If already installed: continue with WP Admin → Gatey → Settings and complete the configuration below.
AWS Cognito access to a User Pool you can use (existing or new) and permission to edit App Clients, Identity Providers, and Domain settings.

Why SSO for WordPress

Frictionless onboarding — one-click sign-up with existing Google/Apple accounts.
Enterprise compliance — hook up Azure AD, Okta, Ping, Auth0 via SAML or OIDC.
Centralized identity — Cognito holds users and policies (incl. MFA/conditional access).
Static-friendly — Gatey talks to Cognito in the browser, no PHP callback, works after static export.

Step-by-Step: Setup Guide

Step 1: Choose or create a Cognito User Pool & App Client

You can use an existing User Pool or create a new one. In both cases you need an App client with the Hosted UI enabled and the right OAuth settings.

If you already have a User Pool: verify that it has an App Client for this website. If the existing client uses a client secret, create a new client without a secret for front-end only (static-friendly) flows.
If you don’t have one yet: create a User Pool, then add an App Client.

Important – No client secret!

Pick an App Client type that does not issue a client secret (so the flow works without a backend and remains static-export friendly). In the Cognito wizard, choose the SPA or Mobile application template. If your current client has a secret, create a parallel client without one and use that in WordPress.

OAuth grant: Authorization code grant.
Callback URLs: your WP route (e.g. https://<site>/sign-in).
Sign-out URLs: same hostname and path family.
Scopes: openid (required), plus email, profile. If you plan to call AWS APIs later, also include aws.cognito.signin.user.admin.

Tip: Keep a notepad of your User pool ID, App client ID, Region, and Hosted UI domain — you’ll paste them into Gatey.

Docs: App client & IdP settings

Step 2: Assign (or verify) a Hosted UI domain

Every WordPress site that uses the Hosted UI needs a domain on the pool. If your pool already has one, reuse it. Otherwise, add a new AWS-managed subdomain or a custom domain via CloudFront + ACM.

Docs: Add a domain to your user pool

Step 3: Add or enable Social identity providers

In Authentication → Social and external providers either enable existing providers on your App Client or add the missing ones by supplying their credentials and scopes.

Provider	Credentials	Scopes	Typical mapping
Google	OAuth Client ID + Secret	`openid email profile`	`email → email`, `family_name → family_name`, `given_name → given_name`, `sub → username`
Facebook	App ID + Secret	`email public_profile`	`email → email`, `last_name → family_name`, `first_name → given_name`, `id → username`
Apple	Services ID, Key, Team ID	`openid email name`	Map `email`; consider Apple private-relay emails in your UX.
Amazon	Login with Amazon Security Profile	`profile` (+ `email` if desired)	`email → email`, `name → given/family` where available

Tip: After (re)enabling a provider, test via Hosted UI and inspect ID token claims. Confirm email, given_name, family_name before moving to WordPress.

Docs: Google • Facebook • Apple • Login with Amazon

Step 4: Connect an Enterprise IdP (OIDC / SAML) or reuse your existing one

For B2B logins connect (or verify) the customer’s IdP (Okta, Azure AD, Ping, Auth0…). With OIDC set Issuer, Client ID/Secret, scopes; with SAML upload metadata.xml. Ensure attribute mapping for email, given_name, family_name and a stable identifier (sub or NameID).

Docs: OIDC • SAML

Quick Setup Links — Top IdPs

Most used providers with direct links to their OAuth2 / SAML setup docs.

Provider	Console	Docs
Login with Amazon	Login with Amazon → Security Profile → Web Settings	Login with Amazon
Google	Google Cloud Console → APIs & Services → Credentials	OpenID Connect
Apple	Apple Developer → Certificates, Identifiers & Profiles → Identifiers	Sign in with Apple
Facebook (Meta)	Meta for Developers → App Dashboard → Facebook Login	Facebook Login (Web)
Microsoft Entra ID	Azure Portal → Entra ID → App registrations	Register an application (OIDC) / SAML SSO
Okta	Okta Admin → Applications → Create App Integration	OIDC / SAML
Auth0	Auth0 Dashboard → Applications	Social / OIDC / SAML
Keycloak	Keycloak Admin → Clients / Identity Providers	OIDC clients / SAML clients

More OIDC / SAML Identity Providers

Additional enterprise & developer IdPs you can connect via OIDC or SAML. (The Top 8 above are not repeated here.)

Enterprise & Workforce

Provider	Console	OIDC / OAuth2 docs	SAML docs
Azure AD B2C	Azure Portal → Azure AD B2C → App registrations	Register apps	SAML app (B2C)
OneLogin	OneLogin Admin → Applications	OpenID Connect	SAML
Ping Identity	PingOne / PingFederate	PingOne OIDC	PingFederate SAML
GitLab (as IdP)	GitLab Admin → Applications → OIDC Provider	OIDC provider	—
Salesforce	Setup → App Manager → New Connected App	Connected App (OAuth)	SAML SSO
IBM Security Verify	Verify Admin → Applications	OpenID Connect	SAML (Docs hub)
Oracle Identity Cloud	Oracle Cloud → Identity → Applications	OIDC (Auth Code)	SAML SSO
JumpCloud	Admin Portal → SSO Applications	OIDC SSO	SAML SSO
ADFS	AD FS Management → Relying Party Trusts	—	Create relying party trust
Google Workspace (as SAML IdP)	Admin Console → Apps → Web & mobile apps	—	Custom SAML app

Developer & Community

Provider	Console	OIDC / OAuth2 docs	SAML docs
GitHub	Developer settings → OAuth Apps	Creating an OAuth App	—
LinkedIn	Developer Portal → Your App → Auth	OAuth 2.0	—
X (Twitter)	X Developer Portal → App → User auth	OAuth 2.0 (Auth Code)	—
Reddit	reddit.com/prefs/apps	OAuth 2.0	—
Spotify	Developer Dashboard → Your Apps	Authorization Code flow	—
Slack	Slack API → Your App → Authentication	Sign in with Slack	—

Tip — scopes & redirects

Keep scopes minimal and consistent across Cognito and the IdP:

openid email profile

Redirect URIs must match exactly (scheme, host, path).

Step 5: Wire Cognito to WordPress using Gatey

At this point you need to configure WordPress with Gatey. If Gatey is not yet installed: install it from the WP plugin repository (Plugins → Add New → Gatey → Install) and activate. If Gatey is already installed: go to WP Admin → Gatey → Settings and complete the configuration below.

5.1 Paste your pool settings

In Gatey → Settings → User Pools, fill in:

User Pool ID, App Client ID, Region
OAuth Domain (Hosted UI domain)
OAuth scopes (e.g. openid email profile and optionally aws.cognito.signin.user.admin)
(Optional) Identity Pool ID for IAM-based API calls

5.2 Configure general login options

In Gatey → Settings → General, set:

Login mechanisms: Username / Email / Phone — match your Cognito pool.
Sign-up attributes: e.g. given_name, family_name, email.
Sign In Page (usually /sign-in).
Enable built-in Social Providers for visible buttons.

5.3 Add Custom Providers (enterprise buttons)

If you configured an enterprise IdP (e.g. Auth0) in Cognito, mirror it under Gatey → Settings → Custom Providers. Give it a provider name, a public title, and an icon (base64 SVG is supported). Gatey will render the button on your sign-in screen.

Tip: Whether you just installed Gatey or it was already active, the final step is the same: finish filling these settings so WordPress can talk to Cognito.

Step 6: (Optional) Replace `/wp-login.php` with Cognito

Open Gatey → Settings → WordPress Login to replace the native login screen and map Cognito groups to WordPress roles.

Don’t lock yourself out: create a Cognito group for admins, add yourself to it, then map that group → Administrator before enabling the replacement.

Step 7: (Optional) Call AWS APIs with IAM credentials

If your site should call AWS-hosted APIs (e.g. the Static WordPress Site Guardian that issues/revokes CloudFront signed cookies):

Include aws.cognito.signin.user.admin among your OAuth scopes (in Gatey → User Pools too).
Create an Identity Pool with an authenticated role that can call your APIs.

Example IAM policy (authenticated role)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["cognito-identity:GetCredentialsForIdentity"],
      "Resource": ["*"]
    },
    {
      "Action": ["execute-api:Invoke"],
      "Resource": ["arn:aws:execute-api:*:637423296378:*"],
      "Effect": "Allow"
    }
  ]
}

Trusted relationships (assume via Cognito Identity)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Federated": "cognito-identity.amazonaws.com" },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "cognito-identity.amazonaws.com:aud": "us-west-1:ed28c718-ef84-4600-af7c-520ebaec46ba"
        },
        "ForAnyValue:StringLike": {
          "cognito-identity.amazonaws.com:amr": "authenticated"
        }
      }
    }
  ]
}

Pro Tips & Common Mistakes

Pro Tips

Test every IdP through the Hosted UI and inspect the ID token claims before touching WP.
Plan for IAM early: add aws.cognito.signin.user.admin to scopes and set up an Identity Pool.
For Apple: expect private-relay emails; let users change their e-mail in Edit Profile.
Use Gatey’s CSS variables (e.g. --gatey-account-group-admin) to show/hide admin UI parts.

Common Mistakes

Client secret present on your App Client → breaks backend-less/static flows. Use SPA/Mobile client (no secret).
Missing openid → login fails.
Mismatched callback domain/path → state/nonce errors.
No email mapping → incomplete profiles in WP.
Replacing /wp-login.php before mapping your admin group → potential lock-out.

Pre-publish checklist

Hosted UI domain active; callback & sign-out URLs correct.
App Client has no client secret (use SPA/Mobile template).
Each IdP tested; ID tokens include email, given_name, family_name.
Gatey → User Pools filled (Pool ID, App Client ID, Region, Domain, Scopes).
Gatey → General set (login mechanisms, sign-up attributes, Sign-in page).
(Optional) Identity Pool + IAM permissions if calling AWS APIs.
Group→Role mapping in Gatey before replacing /wp-login.php.

Key Takeaways

Cognito centralizes both social and enterprise identities behind a secure Hosted UI.
Use an App Client without a client secret (SPA/Mobile) to keep flows backend-less and static-friendly.
Gatey turns Cognito into a polished WordPress experience — no PHP callbacks, no secrets in WP, 22 languages.
With IAM + Identity Pools your logged-in users can call AWS APIs directly from the browser.

AWS Docs quick links: App client · Domain · Google · Facebook · Apple · Amazon · OIDC · SAML

Topics: Amazon Cognito, Gatey, IAM, OIDC, Plugins, SAML, Social Login, SSO, WordPress Authentication

Introduction

Why SSO for WordPress

Step-by-Step: Setup Guide

Step 1: Choose or create a Cognito User Pool & App Client

Important – No client secret!

Step 2: Assign (or verify) a Hosted UI domain

Step 3: Add or enable Social identity providers

Step 4: Connect an Enterprise IdP (OIDC / SAML) or reuse your existing one

Quick Setup Links — Top IdPs

More OIDC / SAML Identity Providers

Tip — scopes & redirects

Step 5: Wire Cognito to WordPress using Gatey

5.1 Paste your pool settings

5.2 Configure general login options

5.3 Add Custom Providers (enterprise buttons)

Step 6: (Optional) Replace `/wp-login.php` with Cognito

Step 7: (Optional) Call AWS APIs with IAM credentials

Pro Tips & Common Mistakes

Pro Tips

Common Mistakes

Pre-publish checklist

Key Takeaways

Navigation

Follow Us:

WordPress SSO with Amazon Cognito and Gatey | Social & Enterprise Login Guide