Workday SSO with MojoAuth
Connect Workday to MojoAuth as your SAML 2.0 Identity Provider (IdP) so employees can reach Workday through your existing sign-in flow instead of a separate Workday username/password. Workday acts as the Service Provider (SP).
How it works
- SP-initiated: the user starts at your Workday tenant's login URL, which redirects to MojoAuth.
- IdP-initiated: the user starts from a MojoAuth launcher (or the Test SSO button) and posts straight into Workday's ACS URL.
- Workday does not support Just-in-Time provisioning over SAML — the worker must already exist as a Workday Account before their first SSO login; the assertion's NameID is only used to match that existing account, never to create one.
Workday's SAML configuration is tenant-wide and can lock out every user — including admins — if it's misconfigured. Always make these changes in a sandbox/implementation (impl) tenant first, and keep a non-SSO administrator path available (see Step 5 and Troubleshooting) before you touch the production tenant.
Prerequisites
- A MojoAuth project (test or live) with Developers access to create Applications.
- Workday Security Administrator access, specifically domain security for Tenant Setup - Security and Authentication Policy.
- SAML SSO is available on standard Workday tenants (no separate add-on), but changing it requires the security group permissions above — request them from your Workday partner/HRIS admin if the tasks below aren't visible.
- Know which Workday environment/host you're configuring (implementation vs. production use different hostnames — see Step 2).
Step 1 — Create the MojoAuth SAML connection
Create a connection
In the MojoAuth dashboard: Developers → Applications → New Application → SAML 2.0 SSO. Enter a connection name (e.g. Workday) and click Create connection. MojoAuth creates a draft connection and auto-issues its signing certificate.
See SAML SSO Connections for the full concept if you haven't created one before.
Copy the IdP values
The connection page shows the IdP values you'll paste into Workday:
| Value | URL |
|---|---|
| IdP metadata URL (Entity ID / Issuer) | {BASE}/saml/{projectId}/sps/{spId}/metadata |
| IdP SSO URL (IdP SSO Service URL) | {BASE}/saml/{projectId}/sps/{spId}/sso |
| IdP SLO URL (logout) | {BASE}/saml/{projectId}/sps/{spId}/slo |
| IdP signing certificate | Download .crt / Copy PEM button on the connection page |
Workday needs the certificate as a PEM-encoded X.509 certificate. Use the Copy PEM button on the connection page — you'll paste this text into a Workday certificate object in Step 2.
Step 2 — Configure Workday
Create a certificate object from the MojoAuth PEM
Workday requires the IdP's signing certificate to exist as a certificate object before you can reference it in the SAML setup. Search for and run Create Trusted Identity Provider Certificate (or Manage Certificates, depending on your tenant's Workday release), then:
- Paste the full MojoAuth PEM (including the
-----BEGIN CERTIFICATE-----/-----END CERTIFICATE-----lines) into the certificate text field. - Give it a recognizable Certificate Name, e.g.
MojoAuth SAML Signing Cert. - Save. Workday validates and stores it as a certificate object you can pick by name later.
Register MojoAuth as a SAML Identity Provider
Search for the task Edit Tenant Setup - Security (on some tenants this is exposed as Register SAML Identity Providers / Edit SAML Identity Providers directly). Open the SAML Setup section and click the + icon to add a new SAML Identity Provider row, then fill in:
| Workday field | Value |
|---|---|
| Identity Provider Name | e.g. MojoAuth |
| Issuer | the MojoAuth IdP metadata URL — {BASE}/saml/{projectId}/sps/{spId}/metadata |
| x509 Certificate | select the certificate object you created above (MojoAuth SAML Signing Cert) |
| Enable SP Initiated SAML Authentication | checked |
| IdP SSO Service URL | {BASE}/saml/{projectId}/sps/{spId}/sso |
Save the SAML Setup section.
The Issuer field must exactly match the string Workday will see in the assertion's
<Issuer> element. Use the MojoAuth metadata URL verbatim — no trailing slash, no extra query
string.
Point an Authentication Policy at MojoAuth
A registered IdP alone doesn't redirect anyone. Search for Maintain Authentication Policies, edit
the relevant policy rule (e.g. the rule covering your web/browser sign-in for the population you're
rolling out), and set its Authentication Type to the SAML Identity Provider you just registered
(MojoAuth). Keep a separate rule — scoped to a small admin/break-glass group — set to Workday's
native Password authentication type (see Step 5 and Troubleshooting).
Note the SP values Workday expects
Workday doesn't generate new SP metadata for you to copy — it uses fixed, tenant-specific values based on your tenant name and hosting environment:
| Workday value | Typical format |
|---|---|
| SP Entity ID / Audience | https://impl.workday.com/<tenant> (implementation) or http://www.workday.com/<tenant> (production) |
| ACS URL | https://<host>.workday.com/<tenant>/login-saml2.htmld |
<tenant> is your Workday tenant name (visible in your Workday URL), and <host> is your data-center
hostname (e.g. wd2, wd3, wd5, or impl for implementation/sandbox tenants). Confirm the exact
strings with your Workday partner or from an existing SP metadata export if you're unsure — they must
match byte-for-byte on the MojoAuth side.
Step 3 — Give the SP details back to MojoAuth
Back on the MojoAuth connection page, complete the other half of the handshake using the values from Step 2:
- Manual configuration — enter the SP Entity ID / Audience and ACS URL exactly as shown above, then click Save. (Workday does not publish a standard SP metadata document to import, so manual entry is the normal path here.)
Implementation (impl) and production Workday tenants use different Entity IDs and ACS hosts.
A connection configured for impl.workday.com will fail audience validation if pointed at your
production tenant, and vice versa — keep separate MojoAuth connections per environment.
Step 4 — NameID and attribute mapping
Workday matches the SAML assertion's NameID against an existing Workday Account — there is no attribute-based JIT provisioning, so this match must succeed on every login.
| MojoAuth setting | Value |
|---|---|
| NameID format | emailAddress or unspecified, matching how your tenant's Workday Accounts are named |
| NameID source | email (if Workday Accounts use work email) or identifier (if Workday Accounts use employee ID) |
Check which identifier your tenant actually uses as the Workday Account preferred name/username — this is set per worker under Maintain Workday Account for a Person — before you pick the source on the MojoAuth connection. If the NameID MojoAuth sends doesn't exactly match that value, the user's Workday Account can't be resolved and login fails even though the SAML response itself was valid.
Workday doesn't require additional custom SAML attributes for basic SSO — the NameID match is the only mandatory piece.
Step 5 — Test
Keep a fallback path open first
Before enabling the authentication policy rule tenant-wide, confirm you (and at least one other admin)
can still sign in without SSO. Workday tenants support a bypass such as appending ?redirect=n to your
Workday sign-in URL, or using the specific non-SSO login path your tenant documents (sometimes exposed
as a /login.flex-style URL) — confirm the exact bypass with your Workday partner and record it
somewhere outside Workday itself.
Test in the sandbox tenant
- SP-initiated: open your implementation tenant's Workday login URL. It should redirect to
MojoAuth's hosted login, then post back to
.../login-saml2.htmldand land you in Workday. - IdP-initiated: click Test SSO on the MojoAuth connection page. This posts an unsolicited assertion straight to the Workday ACS URL and should land you in the Workday home page.
- Success looks like: no Workday SAML error banner, and the signed-in user's Workday Account is the one you expected (check the profile menu in the top right).
Roll out to production
Only after the sandbox test succeeds, repeat Steps 1–4 for your production tenant using a separate MojoAuth connection with the production Entity ID/ACS URL, and widen the Authentication Policy rule from a pilot group to the full population.
Troubleshooting
Certificate errors when adding the SAML Identity Provider Workday can only reference a certificate that already exists as a certificate object. If the x509 Certificate field is empty or rejects your paste, go back to Create Trusted Identity Provider Certificate and re-create the object from a clean copy of the MojoAuth PEM (no extra whitespace or line breaks removed). If MojoAuth rotates its signing certificate, you must create a new certificate object and re-select it in SAML Setup — the old object isn't updated automatically.
"Invalid audience" / assertion rejected
The SP Entity ID / Audience on the MojoAuth connection doesn't match what Workday expects for that
tenant and environment (https://impl.workday.com/<tenant> vs. http://www.workday.com/<tenant>).
Double-check the tenant name and environment, and confirm there's no trailing slash or www.
mismatch.
User authenticates but Workday shows "no matching account" / login failure after redirect The NameID MojoAuth sent doesn't match any Workday Account's username. Confirm what identifier your tenant's Workday Accounts actually use (email vs. employee ID vs. something else) via Maintain Workday Account for a Person, then update the MojoAuth connection's NameID source to send that same value.
Login redirects to the wrong host, or ACS URL mismatch error
Workday's ACS URL and SP Entity ID both encode the data-center host (wd2, wd3, wd5, impl, …).
If you copied values from the wrong environment (e.g. used a production host string on the impl
tenant's connection, or vice versa), Workday will reject the response. Re-confirm the exact host and
tenant name for the specific tenant you're configuring, and keep impl and production as separate
MojoAuth connections.
Everyone (including admins) is locked out after enabling the Authentication Policy rule
This is why a fallback path matters. Use the non-SSO bypass URL you confirmed in Step 5 (e.g.
?redirect=n appended to the tenant login URL, or your tenant's documented bypass) to sign in with a
native Workday password, then either fix the SAML/Authentication Policy configuration or revert the
policy rule back to Password while you troubleshoot. Keeping a small admin population permanently
on a Password-only Authentication Policy rule (rather than routing 100% of users through the SAML
rule) avoids this scenario entirely.
SP-initiated login works but IdP-initiated (Test SSO) fails, or vice versa Confirm Enable SP Initiated SAML Authentication is checked in Workday's SAML Setup if you need SP-initiated flows to work; IdP-initiated posts don't depend on that flag. If only IdP-initiated fails, re-check that the Issuer registered in Workday matches the MojoAuth metadata URL exactly, since unsolicited responses are validated the same way as SP-initiated ones.
Next steps
- SAML SSO Connections — connection concepts, attribute mapping, NameID formats, signing options.
- Managing Applications — edit, disable, or delete this connection.
- Integration Guides overview — more provider guides.