An OIDC single sign-on gate for the WordPress backend, demonstrated end to end.
Step 1 plays Viscomp: one stateless HTTP request to the EverPress Auth
Server's provisioning API (server-to-server, static bearer token) registers
this site's domain for a customer and answers with the OIDC client credentials — repeating
the request returns the same credentials, so the routine can run on every DFS, DEMO, or
Go-to-Live action. Step 2 hands that response to
wp ep-auth provision, which arms the plugin: password login
for backend roles goes off, SSO takes over. Every button on this page executes the real
API call or CLI command.
An HTTP API request is sent from Viscomp to the EP Auth Server so that the server recognizes the new or existing WordPress site and authorizes the customer based on their CAS ID. In the process, the Auth Server creates an OIDC client and returns the credentials and other information in the response.
This demo automatically fills in the form below based on the response.
Note: A customer may have multiple grants for OIDC clients (DFS/DEMO/LIVE). However, the routine must be executed for each environment. Thus, when a web designer performs a "Create Test" action, the API is called and WP-CLI is applied to the DFS instance. The same process applies to the Demo environment and the transition to Live. While technically this only needs to be done once per environment, past experience has shown that domains can change at any time; therefore, it is best to repeat this routine for every DFS, DEMO, and "Go to Live" action. If an OIDC client for the specific domain already exists, the same credentials will be returned (idempotent).
Viscomp does not need to persistently store any data for this entire process. The systems at Viscomp just need to know the WP site's domain and the customer's CAS ID; it then executes an HTTP request (to the Auth Server) and passes the response to WP-CLI (as arguments).
Once the server has created the OIDC client, the only remaining step is to activate the WordPress plugin—EverPress Auth. This is done using WP-CLI. The site is then ready, allowing all staff members to log in as administrators and our client to log in using their customer access credentials.
Form below prefilled with the credentials returned in step 1.
# ready — buttons run real API calls to the EP Auth Server and WP-CLI commands to the EP Auth Client.