Zero Trust for WordPress — Cloudflare as the WordPress login

This one wasn't a security scramble — it was a provisioning problem. The client ran an online newspaper on WordPress, and a newsroom is close to the worst case for account management: a stack of custom roles for the different flavors of editor, contributor, and freelancer, and a constant cycle of onboarding and offboarding as people joined and left the masthead. Identity already lived in Cloudflare, but WordPress kept its own separate user table — so every arrival meant creating an account twice, every departure meant remembering to remove one twice, and the two systems drifted the way parallel systems always do.

The goal was IAM alignment — one place to grant access, one place to revoke it the day someone leaves the paper. Since Cloudflare was already the client's source of truth for identity, the right move wasn't adding another security layer in front of WordPress; it was making WordPress consume the identity system that already existed.

The obvious tool — Cloudflare Access in front of wp-admin — protects the URL but leaves WordPress's own accounts untouched: you'd pass the Access check and then still log into WordPress separately. So this became a plugin instead. It wires Cloudflare Zero Trust's OIDC flow into the WordPress login itself: authenticate with Cloudflare, land in WordPress as a real WordPress user.

Provisioning falls out of that for free — which matters most in exactly this kind of high-churn, many-roles shop. On first login the plugin creates the WordPress account automatically, assigns the configured role (custom roles included), and stores the Cloudflare identity in user metadata. It runs in two modes — secondary, where the Cloudflare button sits alongside the normal login, and primary, where native WordPress login is disabled entirely and Cloudflare is the only door.

Secrets handled like secrets. The OIDC client secret is encrypted at rest with AES-256-CBC, or kept out of the database entirely via environment variables. Login attempts are rate-limited, and login pages ship hardened headers.

Saying no to your own feature. The plugin includes experimental SAML support — and its own README tells you not to use it in production, because the implementation doesn't do proper cryptographic signature validation. OIDC is the supported, secure path; the SAML limitation is documented loudly instead of shipped quietly.

Updates without a marketplace. The plugin updates itself from GitHub releases, so client sites stay current without the WordPress plugin directory in the loop.