DEV Community

Cover image for WordPress (WP) and Okta Single Sign-On
Itse Isaac Azi
Itse Isaac Azi

Posted on Edited on

WordPress (WP) and Okta Single Sign-On

#security #wordpress #opensource #tutorial

Prerequisite

  1. Okta Account
  2. WordPress website

WordPress does not independently authenticate users when Okta and WordPress use Single Sign-On (SSO). Instead, it uses Okta to verify a user's identity.

Consider it like this:
The program that the user wants to use is called WordPress.

The trusted identity provider (IdP) that confirms the identity of the user is Okta.

SAML 2.0 is the protocol that securely sends the authentication result from Okta to WordPress.

Before SSO

Without SSO, the login flow looks like this:

              The user
                │
        WordPress Login Page
                │
        Username + Password
                │
    WordPress checks credentials.
                │
            Database
                │
           Login Success
Enter fullscreen mode Exit fullscreen mode

Problems with this approach include:

  1. Users must remember separate passwords.
  2. Passwords are stored and managed by WordPress.
  3. MFA may not be consistently enforced.
  4. User accounts have to be managed separately in WordPress.

After SSO

With Okta SSO:



           User
            │
            ▼
     WordPress Website
            │
            ▼
     "Login with Okta"
            │
            ▼
           Okta
            │
    Username + Password
            │
            ▼
      MFA Challenge
            │
            ▼
     Identity Verified
            │
            ▼
     SAML Response Sent
            │
            ▼
         WordPress
            │
            ▼
       User Logged In
Enter fullscreen mode Exit fullscreen mode

Observe that the password is never checked by WordPress. It just acknowledges Okta's reliable response.

The Components
1. User

The employee, administrator, editor, or customer trying to log in.
Example:

John
Enter fullscreen mode Exit fullscreen mode

John wants to access:

https://company.com/wp-admin
Enter fullscreen mode Exit fullscreen mode

2. WordPress (Service Provider)

In SAML, WordPress acts as the Service Provider (SP).

Its job is to:

  1. Request authentication.
  2. Trust Okta's response.
  3. Create a local session.
  4. Assign the appropriate WordPress role.

WordPress does not verify the password.

3. Okta (Identity Provider)

Okta is the Identity Provider (IdP).
It:

  1. Stores user identities.
  2. Verifies passwords.
  3. Enforces MFA.
  4. Applies sign-in policies.
  5. Sends a signed SAML response back to WordPress.

4. SAML
SAML (Security Assertion Markup Language) is an XML-based standard for exchanging authentication information.

WordPress sends a request like

Please authenticate this user.
Enter fullscreen mode Exit fullscreen mode

Okta replies:

Enter fullscreen mode Exit fullscreen mode

The response is digitally signed so WordPress can verify it hasn't been altered.

A Real Login Walkthrough

Suppose:
WordPress site:

https://company.com
Enter fullscreen mode Exit fullscreen mode

Okta organisation:

https://company.okta.com
Enter fullscreen mode Exit fullscreen mode

The login sequence is

Step 1

John opens:

https://company.com/wp-admin
Enter fullscreen mode Exit fullscreen mode

WordPress sees no active session.

Step 2

Instead of showing the standard login form, WordPress redirects John to Okta.

company.okta.com
Enter fullscreen mode Exit fullscreen mode

Step 3

Okta displays its login page.

Email:

Password
Enter fullscreen mode Exit fullscreen mode

Step 4

Okta prompts for MFA if required.
For example:

Approve on Okta Verify
Enter fullscreen mode Exit fullscreen mode

or

Enter 6-digit code
Enter fullscreen mode Exit fullscreen mode

Step 5

Okta verifies:

  1. Password
  2. MFA
  3. Device policies
  4. Location policies
  5. Time-based policies If everything meets policy, authentication succeeds.

Step 6
Okta generates a SAML assertion.
This contains information such as:

NameID

john@company.com
Enter fullscreen mode Exit fullscreen mode 
First Name

John
Enter fullscreen mode Exit fullscreen mode 
Last Name

Smith
Enter fullscreen mode Exit fullscreen mode 
Department

IT
Enter fullscreen mode Exit fullscreen mode 
Groups

Administrators
Enter fullscreen mode Exit fullscreen mode

The assertion is digitally signed with Okta's private key.

Step 7
WordPress validates:

  1. The signature.
  2. The certificate.
  3. The issuer.
  4. The audience.
  5. The assertion's expiration time.

If all checks pass, WordPress trusts the response.

Step 8

WordPress creates a local session and, if configured, maps the user to a role.

What Happens the First Time a User Logs In?

If Just-In-Time (JIT) provisioning is enabled:

  1. The user authenticates with Okta.
  2. WordPress doesn't find a matching account.
  3. WordPress automatically creates the account.
  4. The user is logged in.

This avoids manually creating WordPress accounts.

What Happens on Later Logins?

WordPress finds the existing account by email or another mapped identifier and signs the user in immediately after Okta authenticates them.

Why This Is More Secure

Instead of storing passwords in WordPress:

100 Passwords

↓

WordPress Database
Enter fullscreen mode Exit fullscreen mode

You centralise authentication in Okta:

100 Users

↓

Okta

↓

WordPress trusts Okta
Enter fullscreen mode Exit fullscreen mode

Benefits include:

  1. One password per user across applications.
  2. Centralised MFA enforcement.
  3. Faster onboarding and offboarding.
  4. Centralised audit logs.
  5. Reduced password reuse.
  6. Consistent access policies.

Common Security Policies You Can Enforce in Okta
Examples include:

  1. Require MFA for WordPress administrators.
  2. Block sign-ins from countries your organisation doesn't operate in.
  3. Require managed or compliant devices.
  4. Deny access from anonymous proxies or VPNs (if licensed features are available).
  5. Block legacy authentication methods.
  6. Set session timeout and re-authentication requirements.

These policies are enforced before WordPress grants access.

Top comments (0)