SOAP Web Service Call With OAuth Bearer Token Returns Invalid Username or Password
What it means
A SOAP request authenticated with an OAuth 2.0 Bearer access token instead of WS-Security username and password fails with the generic WS-Security fault "invalid username or password". This happens when the request still carries a wsse:Security block built for Basic-style credentials, or the Bearer token is not placed where Workday's SOAP endpoint expects it for OAuth.
Troubleshooting
- Confirm the API client actually has SOAP/Web Services access enabled and its integration system security group grants the same domain security the working WS-Security credentials had.
- Remove any wsse:Security username/password block from the SOAP envelope entirely when authenticating via OAuth; Workday's SOAP endpoint expects the Bearer token in the HTTP Authorization header (Authorization: Bearer <token>), not inside the SOAP body alongside WS-Security elements.
- Verify the refresh token exchange actually produces a valid, non-expired access token by testing the same token against a REST endpoint first, to isolate whether the problem is the token or how it is attached to the SOAP call.
- Check the API client's granted scope includes the functional area being called, since a valid but under-scoped token can also present as an authentication-style fault.
Strip the wsse:Security block from the SOAP request and instead set the HTTP Authorization header to "Bearer <access_token>" for the same call.
Standardize each integration on either pure WS-Security (username/password or x.509) or pure OAuth Bearer-header auth, and never mix a wsse:Security credentials block with an OAuth access token in the same request, since Workday's SOAP endpoint will not reconcile the two.